2010-01-07 21:05:25 +00:00
|
|
|
/* multiboot2.h - Multiboot 2 header file. */
|
|
|
|
/* Copyright (C) 1999,2003,2007,2008,2009,2010 Free Software Foundation, Inc.
|
2007-07-25 00:44:03 +00:00
|
|
|
*
|
2010-01-07 21:05:25 +00:00
|
|
|
* Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
|
|
* of this software and associated documentation files (the "Software"), to
|
|
|
|
* deal in the Software without restriction, including without limitation the
|
|
|
|
* rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
|
|
|
|
* sell copies of the Software, and to permit persons to whom the Software is
|
|
|
|
* furnished to do so, subject to the following conditions:
|
2007-07-25 00:44:03 +00:00
|
|
|
*
|
2010-01-07 21:05:25 +00:00
|
|
|
* The above copyright notice and this permission notice shall be included in
|
|
|
|
* all copies or substantial portions of the Software.
|
2007-07-25 00:44:03 +00:00
|
|
|
*
|
2010-01-07 21:05:25 +00:00
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
|
|
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL ANY
|
|
|
|
* DEVELOPER OR DISTRIBUTOR BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
|
|
|
|
* WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR
|
|
|
|
* IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
|
2007-07-25 00:44:03 +00:00
|
|
|
*/
|
|
|
|
|
2010-01-07 21:05:25 +00:00
|
|
|
#ifndef MULTIBOOT_HEADER
|
|
|
|
#define MULTIBOOT_HEADER 1
|
2007-07-25 00:44:03 +00:00
|
|
|
|
|
|
|
/* How many bytes from the start of the file we search for the header. */
|
2010-03-08 14:40:57 +00:00
|
|
|
#define MULTIBOOT_SEARCH 32768
|
|
|
|
#define MULTIBOOT_HEADER_ALIGN 8
|
2007-07-25 00:44:03 +00:00
|
|
|
|
|
|
|
/* The magic field should contain this. */
|
2010-01-07 21:05:25 +00:00
|
|
|
#define MULTIBOOT2_HEADER_MAGIC 0xe85250d6
|
2007-07-25 00:44:03 +00:00
|
|
|
|
2010-01-07 21:05:25 +00:00
|
|
|
/* This should be in %eax. */
|
|
|
|
#define MULTIBOOT2_BOOTLOADER_MAGIC 0x36d76289
|
2007-07-25 00:44:03 +00:00
|
|
|
|
|
|
|
/* Alignment of multiboot modules. */
|
2010-01-07 21:05:25 +00:00
|
|
|
#define MULTIBOOT_MOD_ALIGN 0x00001000
|
2007-07-25 00:44:03 +00:00
|
|
|
|
2010-01-07 21:05:25 +00:00
|
|
|
/* Alignment of the multiboot info structure. */
|
2010-03-28 12:19:41 +00:00
|
|
|
#define MULTIBOOT_INFO_ALIGN 0x00000008
|
2007-07-25 00:44:03 +00:00
|
|
|
|
2010-01-07 21:05:25 +00:00
|
|
|
/* Flags set in the 'flags' member of the multiboot header. */
|
2007-07-25 00:44:03 +00:00
|
|
|
|
2010-03-07 13:59:15 +00:00
|
|
|
#define MULTIBOOT_TAG_ALIGN 8
|
2010-01-16 15:25:43 +00:00
|
|
|
#define MULTIBOOT_TAG_TYPE_END 0
|
|
|
|
#define MULTIBOOT_TAG_TYPE_CMDLINE 1
|
|
|
|
#define MULTIBOOT_TAG_TYPE_BOOT_LOADER_NAME 2
|
|
|
|
#define MULTIBOOT_TAG_TYPE_MODULE 3
|
|
|
|
#define MULTIBOOT_TAG_TYPE_BASIC_MEMINFO 4
|
|
|
|
#define MULTIBOOT_TAG_TYPE_BOOTDEV 5
|
|
|
|
#define MULTIBOOT_TAG_TYPE_MMAP 6
|
|
|
|
#define MULTIBOOT_TAG_TYPE_VBE 7
|
|
|
|
#define MULTIBOOT_TAG_TYPE_FRAMEBUFFER 8
|
2010-03-10 10:40:20 +00:00
|
|
|
#define MULTIBOOT_TAG_TYPE_ELF_SECTIONS 9
|
|
|
|
#define MULTIBOOT_TAG_TYPE_APM 10
|
2010-09-21 00:06:14 +00:00
|
|
|
#define MULTIBOOT_TAG_TYPE_EFI32 11
|
|
|
|
#define MULTIBOOT_TAG_TYPE_EFI64 12
|
|
|
|
#define MULTIBOOT_TAG_TYPE_SMBIOS 13
|
|
|
|
#define MULTIBOOT_TAG_TYPE_ACPI_OLD 14
|
|
|
|
#define MULTIBOOT_TAG_TYPE_ACPI_NEW 15
|
|
|
|
#define MULTIBOOT_TAG_TYPE_NETWORK 16
|
2013-10-28 14:37:00 +00:00
|
|
|
#define MULTIBOOT_TAG_TYPE_EFI_MMAP 17
|
2013-12-13 11:56:14 +00:00
|
|
|
#define MULTIBOOT_TAG_TYPE_EFI_BS 18
|
2014-11-19 23:09:54 +00:00
|
|
|
#define MULTIBOOT_TAG_TYPE_EFI32_IH 19
|
|
|
|
#define MULTIBOOT_TAG_TYPE_EFI64_IH 20
|
multiboot2: Add support for relocatable images
Currently multiboot2 protocol loads image exactly at address specified in
ELF or multiboot2 header. This solution works quite well on legacy BIOS
platforms. It is possible because memory regions are placed at predictable
addresses (though I was not able to find any spec which says that it is
strong requirement, so, it looks that it is just a goodwill of hardware
designers). However, EFI platforms are more volatile. Even if required
memory regions live at specific addresses then they are sometimes simply
not free (e.g. used by boot/runtime services on Dell PowerEdge R820 and
OVMF). This means that you are not able to just set up final image
destination on build time. You have to provide method to relocate image
contents to real load address which is usually different than load address
specified in ELF and multiboot2 headers.
This patch provides all needed machinery to do self relocation in image code.
First of all GRUB2 reads min_addr (min. load addr), max_addr (max. load addr),
align (required image alignment), preference (it says which memory regions are
preferred by image, e.g. none, low, high) from multiboot_header_tag_relocatable
header tag contained in binary (at this stage load addresses from multiboot2
and/or ELF headers are ignored). Later loader tries to fulfill request (not only
that one) and if it succeeds then it informs image about real load address via
multiboot_tag_load_base_addr tag. At this stage GRUB2 role is finished. Starting
from now executable must cope with relocations itself using whole static and
dynamic knowledge provided by boot loader.
This patch does not provide functionality which could do relocations using
ELF relocation data. However, I was asked by Konrad Rzeszutek Wilk and Vladimir
'phcoder' Serbinenko to investigate that thing. It looks that relevant machinery
could be added to existing code (including this patch) without huge effort.
Additionally, ELF relocation could live in parallel with self relocation provided
by this patch. However, during research I realized that first of all we should
establish the details how ELF relocatable image should look like and how it should
be build. At least to build proper test/example files.
So, this patch just provides support for self relocatable images. If ELF file
with relocs is loaded then GRUB2 complains loudly and ignores it. Support for
such files will be added later.
This patch was tested with Xen image which uses that functionality. However, this Xen
feature is still under development and new patchset will be released in about 2-3 weeks.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2015-07-17 19:02:09 +00:00
|
|
|
#define MULTIBOOT_TAG_TYPE_LOAD_BASE_ADDR 21
|
2010-01-07 21:05:25 +00:00
|
|
|
|
2010-03-08 14:40:57 +00:00
|
|
|
#define MULTIBOOT_HEADER_TAG_END 0
|
|
|
|
#define MULTIBOOT_HEADER_TAG_INFORMATION_REQUEST 1
|
|
|
|
#define MULTIBOOT_HEADER_TAG_ADDRESS 2
|
|
|
|
#define MULTIBOOT_HEADER_TAG_ENTRY_ADDRESS 3
|
|
|
|
#define MULTIBOOT_HEADER_TAG_CONSOLE_FLAGS 4
|
|
|
|
#define MULTIBOOT_HEADER_TAG_FRAMEBUFFER 5
|
|
|
|
#define MULTIBOOT_HEADER_TAG_MODULE_ALIGN 6
|
2013-12-13 11:56:14 +00:00
|
|
|
#define MULTIBOOT_HEADER_TAG_EFI_BS 7
|
2015-07-17 17:43:42 +00:00
|
|
|
#define MULTIBOOT_HEADER_TAG_ENTRY_ADDRESS_EFI64 9
|
multiboot2: Add support for relocatable images
Currently multiboot2 protocol loads image exactly at address specified in
ELF or multiboot2 header. This solution works quite well on legacy BIOS
platforms. It is possible because memory regions are placed at predictable
addresses (though I was not able to find any spec which says that it is
strong requirement, so, it looks that it is just a goodwill of hardware
designers). However, EFI platforms are more volatile. Even if required
memory regions live at specific addresses then they are sometimes simply
not free (e.g. used by boot/runtime services on Dell PowerEdge R820 and
OVMF). This means that you are not able to just set up final image
destination on build time. You have to provide method to relocate image
contents to real load address which is usually different than load address
specified in ELF and multiboot2 headers.
This patch provides all needed machinery to do self relocation in image code.
First of all GRUB2 reads min_addr (min. load addr), max_addr (max. load addr),
align (required image alignment), preference (it says which memory regions are
preferred by image, e.g. none, low, high) from multiboot_header_tag_relocatable
header tag contained in binary (at this stage load addresses from multiboot2
and/or ELF headers are ignored). Later loader tries to fulfill request (not only
that one) and if it succeeds then it informs image about real load address via
multiboot_tag_load_base_addr tag. At this stage GRUB2 role is finished. Starting
from now executable must cope with relocations itself using whole static and
dynamic knowledge provided by boot loader.
This patch does not provide functionality which could do relocations using
ELF relocation data. However, I was asked by Konrad Rzeszutek Wilk and Vladimir
'phcoder' Serbinenko to investigate that thing. It looks that relevant machinery
could be added to existing code (including this patch) without huge effort.
Additionally, ELF relocation could live in parallel with self relocation provided
by this patch. However, during research I realized that first of all we should
establish the details how ELF relocatable image should look like and how it should
be build. At least to build proper test/example files.
So, this patch just provides support for self relocatable images. If ELF file
with relocs is loaded then GRUB2 complains loudly and ignores it. Support for
such files will be added later.
This patch was tested with Xen image which uses that functionality. However, this Xen
feature is still under development and new patchset will be released in about 2-3 weeks.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2015-07-17 19:02:09 +00:00
|
|
|
#define MULTIBOOT_HEADER_TAG_RELOCATABLE 10
|
2010-03-08 14:40:57 +00:00
|
|
|
|
2017-08-14 10:51:26 +00:00
|
|
|
#define MULTIBOOT2_ARCHITECTURE_I386 0
|
|
|
|
#define MULTIBOOT2_ARCHITECTURE_MIPS32 4
|
2010-03-08 14:40:57 +00:00
|
|
|
#define MULTIBOOT_HEADER_TAG_OPTIONAL 1
|
|
|
|
|
multiboot2: Add support for relocatable images
Currently multiboot2 protocol loads image exactly at address specified in
ELF or multiboot2 header. This solution works quite well on legacy BIOS
platforms. It is possible because memory regions are placed at predictable
addresses (though I was not able to find any spec which says that it is
strong requirement, so, it looks that it is just a goodwill of hardware
designers). However, EFI platforms are more volatile. Even if required
memory regions live at specific addresses then they are sometimes simply
not free (e.g. used by boot/runtime services on Dell PowerEdge R820 and
OVMF). This means that you are not able to just set up final image
destination on build time. You have to provide method to relocate image
contents to real load address which is usually different than load address
specified in ELF and multiboot2 headers.
This patch provides all needed machinery to do self relocation in image code.
First of all GRUB2 reads min_addr (min. load addr), max_addr (max. load addr),
align (required image alignment), preference (it says which memory regions are
preferred by image, e.g. none, low, high) from multiboot_header_tag_relocatable
header tag contained in binary (at this stage load addresses from multiboot2
and/or ELF headers are ignored). Later loader tries to fulfill request (not only
that one) and if it succeeds then it informs image about real load address via
multiboot_tag_load_base_addr tag. At this stage GRUB2 role is finished. Starting
from now executable must cope with relocations itself using whole static and
dynamic knowledge provided by boot loader.
This patch does not provide functionality which could do relocations using
ELF relocation data. However, I was asked by Konrad Rzeszutek Wilk and Vladimir
'phcoder' Serbinenko to investigate that thing. It looks that relevant machinery
could be added to existing code (including this patch) without huge effort.
Additionally, ELF relocation could live in parallel with self relocation provided
by this patch. However, during research I realized that first of all we should
establish the details how ELF relocatable image should look like and how it should
be build. At least to build proper test/example files.
So, this patch just provides support for self relocatable images. If ELF file
with relocs is loaded then GRUB2 complains loudly and ignores it. Support for
such files will be added later.
This patch was tested with Xen image which uses that functionality. However, this Xen
feature is still under development and new patchset will be released in about 2-3 weeks.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2015-07-17 19:02:09 +00:00
|
|
|
#define MULTIBOOT_LOAD_PREFERENCE_NONE 0
|
|
|
|
#define MULTIBOOT_LOAD_PREFERENCE_LOW 1
|
|
|
|
#define MULTIBOOT_LOAD_PREFERENCE_HIGH 2
|
|
|
|
|
2010-03-10 10:40:20 +00:00
|
|
|
#define MULTIBOOT_CONSOLE_FLAGS_CONSOLE_REQUIRED 1
|
|
|
|
#define MULTIBOOT_CONSOLE_FLAGS_EGA_TEXT_SUPPORTED 2
|
|
|
|
|
2010-01-07 21:05:25 +00:00
|
|
|
#ifndef ASM_FILE
|
|
|
|
|
2010-01-14 14:54:14 +00:00
|
|
|
typedef unsigned char multiboot_uint8_t;
|
2010-01-07 21:05:25 +00:00
|
|
|
typedef unsigned short multiboot_uint16_t;
|
|
|
|
typedef unsigned int multiboot_uint32_t;
|
|
|
|
typedef unsigned long long multiboot_uint64_t;
|
|
|
|
|
|
|
|
struct multiboot_header
|
2007-07-25 00:44:03 +00:00
|
|
|
{
|
2010-01-07 21:05:25 +00:00
|
|
|
/* Must be MULTIBOOT_MAGIC - see above. */
|
|
|
|
multiboot_uint32_t magic;
|
|
|
|
|
2010-03-08 14:40:57 +00:00
|
|
|
/* ISA */
|
|
|
|
multiboot_uint32_t architecture;
|
|
|
|
|
|
|
|
/* Total header length. */
|
|
|
|
multiboot_uint32_t header_length;
|
2010-01-07 21:05:25 +00:00
|
|
|
|
|
|
|
/* The above fields plus this one must equal 0 mod 2^32. */
|
|
|
|
multiboot_uint32_t checksum;
|
2010-03-08 14:40:57 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
struct multiboot_header_tag
|
|
|
|
{
|
2010-03-27 20:50:57 +00:00
|
|
|
multiboot_uint16_t type;
|
|
|
|
multiboot_uint16_t flags;
|
2010-03-08 14:40:57 +00:00
|
|
|
multiboot_uint32_t size;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct multiboot_header_tag_information_request
|
|
|
|
{
|
2010-03-27 20:50:57 +00:00
|
|
|
multiboot_uint16_t type;
|
|
|
|
multiboot_uint16_t flags;
|
2010-03-08 14:40:57 +00:00
|
|
|
multiboot_uint32_t size;
|
|
|
|
multiboot_uint32_t requests[0];
|
|
|
|
};
|
2010-01-07 21:05:25 +00:00
|
|
|
|
2010-03-08 14:40:57 +00:00
|
|
|
struct multiboot_header_tag_address
|
|
|
|
{
|
2010-03-27 20:50:57 +00:00
|
|
|
multiboot_uint16_t type;
|
|
|
|
multiboot_uint16_t flags;
|
2010-03-08 14:40:57 +00:00
|
|
|
multiboot_uint32_t size;
|
2010-01-07 21:05:25 +00:00
|
|
|
multiboot_uint32_t header_addr;
|
|
|
|
multiboot_uint32_t load_addr;
|
|
|
|
multiboot_uint32_t load_end_addr;
|
|
|
|
multiboot_uint32_t bss_end_addr;
|
2010-03-08 14:40:57 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
struct multiboot_header_tag_entry_address
|
|
|
|
{
|
2010-03-27 20:50:57 +00:00
|
|
|
multiboot_uint16_t type;
|
|
|
|
multiboot_uint16_t flags;
|
2010-03-08 14:40:57 +00:00
|
|
|
multiboot_uint32_t size;
|
2010-01-07 21:05:25 +00:00
|
|
|
multiboot_uint32_t entry_addr;
|
2010-03-08 14:40:57 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
struct multiboot_header_tag_console_flags
|
|
|
|
{
|
2010-03-27 20:50:57 +00:00
|
|
|
multiboot_uint16_t type;
|
|
|
|
multiboot_uint16_t flags;
|
2010-03-08 14:40:57 +00:00
|
|
|
multiboot_uint32_t size;
|
|
|
|
multiboot_uint32_t console_flags;
|
|
|
|
};
|
2010-01-07 21:05:25 +00:00
|
|
|
|
2010-03-08 14:40:57 +00:00
|
|
|
struct multiboot_header_tag_framebuffer
|
|
|
|
{
|
2010-03-27 20:50:57 +00:00
|
|
|
multiboot_uint16_t type;
|
|
|
|
multiboot_uint16_t flags;
|
2010-03-08 14:40:57 +00:00
|
|
|
multiboot_uint32_t size;
|
|
|
|
multiboot_uint32_t width;
|
|
|
|
multiboot_uint32_t height;
|
|
|
|
multiboot_uint32_t depth;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct multiboot_header_tag_module_align
|
|
|
|
{
|
2010-03-27 20:50:57 +00:00
|
|
|
multiboot_uint16_t type;
|
|
|
|
multiboot_uint16_t flags;
|
2010-03-08 14:40:57 +00:00
|
|
|
multiboot_uint32_t size;
|
2007-07-25 00:44:03 +00:00
|
|
|
};
|
|
|
|
|
multiboot2: Add support for relocatable images
Currently multiboot2 protocol loads image exactly at address specified in
ELF or multiboot2 header. This solution works quite well on legacy BIOS
platforms. It is possible because memory regions are placed at predictable
addresses (though I was not able to find any spec which says that it is
strong requirement, so, it looks that it is just a goodwill of hardware
designers). However, EFI platforms are more volatile. Even if required
memory regions live at specific addresses then they are sometimes simply
not free (e.g. used by boot/runtime services on Dell PowerEdge R820 and
OVMF). This means that you are not able to just set up final image
destination on build time. You have to provide method to relocate image
contents to real load address which is usually different than load address
specified in ELF and multiboot2 headers.
This patch provides all needed machinery to do self relocation in image code.
First of all GRUB2 reads min_addr (min. load addr), max_addr (max. load addr),
align (required image alignment), preference (it says which memory regions are
preferred by image, e.g. none, low, high) from multiboot_header_tag_relocatable
header tag contained in binary (at this stage load addresses from multiboot2
and/or ELF headers are ignored). Later loader tries to fulfill request (not only
that one) and if it succeeds then it informs image about real load address via
multiboot_tag_load_base_addr tag. At this stage GRUB2 role is finished. Starting
from now executable must cope with relocations itself using whole static and
dynamic knowledge provided by boot loader.
This patch does not provide functionality which could do relocations using
ELF relocation data. However, I was asked by Konrad Rzeszutek Wilk and Vladimir
'phcoder' Serbinenko to investigate that thing. It looks that relevant machinery
could be added to existing code (including this patch) without huge effort.
Additionally, ELF relocation could live in parallel with self relocation provided
by this patch. However, during research I realized that first of all we should
establish the details how ELF relocatable image should look like and how it should
be build. At least to build proper test/example files.
So, this patch just provides support for self relocatable images. If ELF file
with relocs is loaded then GRUB2 complains loudly and ignores it. Support for
such files will be added later.
This patch was tested with Xen image which uses that functionality. However, this Xen
feature is still under development and new patchset will be released in about 2-3 weeks.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2015-07-17 19:02:09 +00:00
|
|
|
struct multiboot_header_tag_relocatable
|
|
|
|
{
|
|
|
|
multiboot_uint16_t type;
|
|
|
|
multiboot_uint16_t flags;
|
|
|
|
multiboot_uint32_t size;
|
|
|
|
multiboot_uint32_t min_addr;
|
|
|
|
multiboot_uint32_t max_addr;
|
|
|
|
multiboot_uint32_t align;
|
|
|
|
multiboot_uint32_t preference;
|
|
|
|
};
|
|
|
|
|
2010-01-16 15:25:43 +00:00
|
|
|
struct multiboot_color
|
|
|
|
{
|
|
|
|
multiboot_uint8_t red;
|
|
|
|
multiboot_uint8_t green;
|
|
|
|
multiboot_uint8_t blue;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct multiboot_mmap_entry
|
|
|
|
{
|
|
|
|
multiboot_uint64_t addr;
|
|
|
|
multiboot_uint64_t len;
|
|
|
|
#define MULTIBOOT_MEMORY_AVAILABLE 1
|
|
|
|
#define MULTIBOOT_MEMORY_RESERVED 2
|
2010-03-07 12:01:43 +00:00
|
|
|
#define MULTIBOOT_MEMORY_ACPI_RECLAIMABLE 3
|
|
|
|
#define MULTIBOOT_MEMORY_NVS 4
|
2010-09-21 00:06:14 +00:00
|
|
|
#define MULTIBOOT_MEMORY_BADRAM 5
|
2010-01-16 15:25:43 +00:00
|
|
|
multiboot_uint32_t type;
|
2010-03-07 13:59:15 +00:00
|
|
|
multiboot_uint32_t zero;
|
2016-03-10 20:16:10 +00:00
|
|
|
};
|
2010-01-16 15:25:43 +00:00
|
|
|
typedef struct multiboot_mmap_entry multiboot_memory_map_t;
|
|
|
|
|
|
|
|
struct multiboot_tag
|
2007-07-25 00:44:03 +00:00
|
|
|
{
|
2010-01-16 15:25:43 +00:00
|
|
|
multiboot_uint32_t type;
|
|
|
|
multiboot_uint32_t size;
|
2007-07-25 00:44:03 +00:00
|
|
|
};
|
|
|
|
|
2010-01-16 15:25:43 +00:00
|
|
|
struct multiboot_tag_string
|
2007-07-25 00:44:03 +00:00
|
|
|
{
|
2010-01-16 15:25:43 +00:00
|
|
|
multiboot_uint32_t type;
|
2010-01-07 21:05:25 +00:00
|
|
|
multiboot_uint32_t size;
|
2010-01-16 15:25:43 +00:00
|
|
|
char string[0];
|
2007-07-25 00:44:03 +00:00
|
|
|
};
|
|
|
|
|
2010-01-16 15:25:43 +00:00
|
|
|
struct multiboot_tag_module
|
2007-07-25 00:44:03 +00:00
|
|
|
{
|
2010-01-16 15:25:43 +00:00
|
|
|
multiboot_uint32_t type;
|
|
|
|
multiboot_uint32_t size;
|
|
|
|
multiboot_uint32_t mod_start;
|
|
|
|
multiboot_uint32_t mod_end;
|
|
|
|
char cmdline[0];
|
|
|
|
};
|
2010-01-07 21:05:25 +00:00
|
|
|
|
2010-01-16 15:25:43 +00:00
|
|
|
struct multiboot_tag_basic_meminfo
|
|
|
|
{
|
|
|
|
multiboot_uint32_t type;
|
|
|
|
multiboot_uint32_t size;
|
2010-01-07 21:05:25 +00:00
|
|
|
multiboot_uint32_t mem_lower;
|
|
|
|
multiboot_uint32_t mem_upper;
|
2010-01-16 15:25:43 +00:00
|
|
|
};
|
2010-01-07 21:05:25 +00:00
|
|
|
|
2010-01-16 15:25:43 +00:00
|
|
|
struct multiboot_tag_bootdev
|
|
|
|
{
|
|
|
|
multiboot_uint32_t type;
|
|
|
|
multiboot_uint32_t size;
|
|
|
|
multiboot_uint32_t biosdev;
|
|
|
|
multiboot_uint32_t slice;
|
|
|
|
multiboot_uint32_t part;
|
|
|
|
};
|
2010-01-07 21:05:25 +00:00
|
|
|
|
2010-01-16 15:25:43 +00:00
|
|
|
struct multiboot_tag_mmap
|
|
|
|
{
|
|
|
|
multiboot_uint32_t type;
|
|
|
|
multiboot_uint32_t size;
|
2010-03-07 13:59:15 +00:00
|
|
|
multiboot_uint32_t entry_size;
|
|
|
|
multiboot_uint32_t entry_version;
|
2010-01-16 15:25:43 +00:00
|
|
|
struct multiboot_mmap_entry entries[0];
|
|
|
|
};
|
2010-01-07 21:05:25 +00:00
|
|
|
|
2010-01-16 15:25:43 +00:00
|
|
|
struct multiboot_vbe_info_block
|
|
|
|
{
|
|
|
|
multiboot_uint8_t external_specification[512];
|
|
|
|
};
|
2010-01-07 21:05:25 +00:00
|
|
|
|
2010-01-16 15:25:43 +00:00
|
|
|
struct multiboot_vbe_mode_info_block
|
|
|
|
{
|
|
|
|
multiboot_uint8_t external_specification[256];
|
|
|
|
};
|
2010-01-07 21:05:25 +00:00
|
|
|
|
2010-01-16 15:25:43 +00:00
|
|
|
struct multiboot_tag_vbe
|
|
|
|
{
|
|
|
|
multiboot_uint32_t type;
|
|
|
|
multiboot_uint32_t size;
|
2010-01-07 21:05:25 +00:00
|
|
|
|
|
|
|
multiboot_uint16_t vbe_mode;
|
|
|
|
multiboot_uint16_t vbe_interface_seg;
|
|
|
|
multiboot_uint16_t vbe_interface_off;
|
|
|
|
multiboot_uint16_t vbe_interface_len;
|
2010-01-14 14:54:14 +00:00
|
|
|
|
2010-01-16 15:25:43 +00:00
|
|
|
struct multiboot_vbe_info_block vbe_control_info;
|
|
|
|
struct multiboot_vbe_mode_info_block vbe_mode_info;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct multiboot_tag_framebuffer_common
|
|
|
|
{
|
|
|
|
multiboot_uint32_t type;
|
|
|
|
multiboot_uint32_t size;
|
|
|
|
|
2010-01-14 14:54:14 +00:00
|
|
|
multiboot_uint64_t framebuffer_addr;
|
|
|
|
multiboot_uint32_t framebuffer_pitch;
|
|
|
|
multiboot_uint32_t framebuffer_width;
|
|
|
|
multiboot_uint32_t framebuffer_height;
|
|
|
|
multiboot_uint8_t framebuffer_bpp;
|
2010-01-15 14:46:59 +00:00
|
|
|
#define MULTIBOOT_FRAMEBUFFER_TYPE_INDEXED 0
|
|
|
|
#define MULTIBOOT_FRAMEBUFFER_TYPE_RGB 1
|
|
|
|
#define MULTIBOOT_FRAMEBUFFER_TYPE_EGA_TEXT 2
|
2010-01-14 14:54:14 +00:00
|
|
|
multiboot_uint8_t framebuffer_type;
|
2010-03-07 13:59:15 +00:00
|
|
|
multiboot_uint16_t reserved;
|
2010-01-16 15:25:43 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
struct multiboot_tag_framebuffer
|
|
|
|
{
|
|
|
|
struct multiboot_tag_framebuffer_common common;
|
|
|
|
|
2010-01-14 14:54:14 +00:00
|
|
|
union
|
|
|
|
{
|
|
|
|
struct
|
|
|
|
{
|
|
|
|
multiboot_uint16_t framebuffer_palette_num_colors;
|
2010-01-16 15:25:43 +00:00
|
|
|
struct multiboot_color framebuffer_palette[0];
|
2010-01-14 14:54:14 +00:00
|
|
|
};
|
|
|
|
struct
|
|
|
|
{
|
|
|
|
multiboot_uint8_t framebuffer_red_field_position;
|
|
|
|
multiboot_uint8_t framebuffer_red_mask_size;
|
|
|
|
multiboot_uint8_t framebuffer_green_field_position;
|
|
|
|
multiboot_uint8_t framebuffer_green_mask_size;
|
|
|
|
multiboot_uint8_t framebuffer_blue_field_position;
|
|
|
|
multiboot_uint8_t framebuffer_blue_mask_size;
|
|
|
|
};
|
|
|
|
};
|
2007-07-25 00:44:03 +00:00
|
|
|
};
|
|
|
|
|
2010-03-07 13:59:15 +00:00
|
|
|
struct multiboot_tag_elf_sections
|
|
|
|
{
|
|
|
|
multiboot_uint32_t type;
|
|
|
|
multiboot_uint32_t size;
|
|
|
|
multiboot_uint32_t num;
|
|
|
|
multiboot_uint32_t entsize;
|
|
|
|
multiboot_uint32_t shndx;
|
|
|
|
char sections[0];
|
|
|
|
};
|
|
|
|
|
|
|
|
struct multiboot_tag_apm
|
|
|
|
{
|
|
|
|
multiboot_uint32_t type;
|
|
|
|
multiboot_uint32_t size;
|
|
|
|
multiboot_uint16_t version;
|
|
|
|
multiboot_uint16_t cseg;
|
|
|
|
multiboot_uint32_t offset;
|
|
|
|
multiboot_uint16_t cseg_16;
|
|
|
|
multiboot_uint16_t dseg;
|
|
|
|
multiboot_uint16_t flags;
|
|
|
|
multiboot_uint16_t cseg_len;
|
|
|
|
multiboot_uint16_t cseg_16_len;
|
|
|
|
multiboot_uint16_t dseg_len;
|
|
|
|
};
|
|
|
|
|
2010-09-21 00:06:14 +00:00
|
|
|
struct multiboot_tag_efi32
|
|
|
|
{
|
|
|
|
multiboot_uint32_t type;
|
|
|
|
multiboot_uint32_t size;
|
|
|
|
multiboot_uint32_t pointer;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct multiboot_tag_efi64
|
|
|
|
{
|
|
|
|
multiboot_uint32_t type;
|
|
|
|
multiboot_uint32_t size;
|
|
|
|
multiboot_uint64_t pointer;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct multiboot_tag_smbios
|
|
|
|
{
|
|
|
|
multiboot_uint32_t type;
|
|
|
|
multiboot_uint32_t size;
|
|
|
|
multiboot_uint8_t major;
|
|
|
|
multiboot_uint8_t minor;
|
|
|
|
multiboot_uint8_t reserved[6];
|
|
|
|
multiboot_uint8_t tables[0];
|
|
|
|
};
|
|
|
|
|
|
|
|
struct multiboot_tag_old_acpi
|
|
|
|
{
|
|
|
|
multiboot_uint32_t type;
|
|
|
|
multiboot_uint32_t size;
|
|
|
|
multiboot_uint8_t rsdp[0];
|
|
|
|
};
|
|
|
|
|
|
|
|
struct multiboot_tag_new_acpi
|
|
|
|
{
|
|
|
|
multiboot_uint32_t type;
|
|
|
|
multiboot_uint32_t size;
|
|
|
|
multiboot_uint8_t rsdp[0];
|
|
|
|
};
|
|
|
|
|
|
|
|
struct multiboot_tag_network
|
|
|
|
{
|
|
|
|
multiboot_uint32_t type;
|
|
|
|
multiboot_uint32_t size;
|
|
|
|
multiboot_uint8_t dhcpack[0];
|
|
|
|
};
|
|
|
|
|
2013-10-28 14:37:00 +00:00
|
|
|
struct multiboot_tag_efi_mmap
|
|
|
|
{
|
|
|
|
multiboot_uint32_t type;
|
|
|
|
multiboot_uint32_t size;
|
|
|
|
multiboot_uint32_t descr_size;
|
|
|
|
multiboot_uint32_t descr_vers;
|
|
|
|
multiboot_uint8_t efi_mmap[0];
|
|
|
|
};
|
|
|
|
|
2014-11-19 23:09:54 +00:00
|
|
|
struct multiboot_tag_efi32_ih
|
|
|
|
{
|
|
|
|
multiboot_uint32_t type;
|
|
|
|
multiboot_uint32_t size;
|
|
|
|
multiboot_uint32_t pointer;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct multiboot_tag_efi64_ih
|
|
|
|
{
|
|
|
|
multiboot_uint32_t type;
|
|
|
|
multiboot_uint32_t size;
|
|
|
|
multiboot_uint64_t pointer;
|
|
|
|
};
|
|
|
|
|
multiboot2: Add support for relocatable images
Currently multiboot2 protocol loads image exactly at address specified in
ELF or multiboot2 header. This solution works quite well on legacy BIOS
platforms. It is possible because memory regions are placed at predictable
addresses (though I was not able to find any spec which says that it is
strong requirement, so, it looks that it is just a goodwill of hardware
designers). However, EFI platforms are more volatile. Even if required
memory regions live at specific addresses then they are sometimes simply
not free (e.g. used by boot/runtime services on Dell PowerEdge R820 and
OVMF). This means that you are not able to just set up final image
destination on build time. You have to provide method to relocate image
contents to real load address which is usually different than load address
specified in ELF and multiboot2 headers.
This patch provides all needed machinery to do self relocation in image code.
First of all GRUB2 reads min_addr (min. load addr), max_addr (max. load addr),
align (required image alignment), preference (it says which memory regions are
preferred by image, e.g. none, low, high) from multiboot_header_tag_relocatable
header tag contained in binary (at this stage load addresses from multiboot2
and/or ELF headers are ignored). Later loader tries to fulfill request (not only
that one) and if it succeeds then it informs image about real load address via
multiboot_tag_load_base_addr tag. At this stage GRUB2 role is finished. Starting
from now executable must cope with relocations itself using whole static and
dynamic knowledge provided by boot loader.
This patch does not provide functionality which could do relocations using
ELF relocation data. However, I was asked by Konrad Rzeszutek Wilk and Vladimir
'phcoder' Serbinenko to investigate that thing. It looks that relevant machinery
could be added to existing code (including this patch) without huge effort.
Additionally, ELF relocation could live in parallel with self relocation provided
by this patch. However, during research I realized that first of all we should
establish the details how ELF relocatable image should look like and how it should
be build. At least to build proper test/example files.
So, this patch just provides support for self relocatable images. If ELF file
with relocs is loaded then GRUB2 complains loudly and ignores it. Support for
such files will be added later.
This patch was tested with Xen image which uses that functionality. However, this Xen
feature is still under development and new patchset will be released in about 2-3 weeks.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2015-07-17 19:02:09 +00:00
|
|
|
struct multiboot_tag_load_base_addr
|
|
|
|
{
|
|
|
|
multiboot_uint32_t type;
|
|
|
|
multiboot_uint32_t size;
|
|
|
|
multiboot_uint32_t load_base_addr;
|
|
|
|
};
|
|
|
|
|
2007-07-25 00:44:03 +00:00
|
|
|
#endif /* ! ASM_FILE */
|
|
|
|
|
2010-01-07 21:05:25 +00:00
|
|
|
#endif /* ! MULTIBOOT_HEADER */
|