diff options
| -rw-r--r-- | Documentation/x86/boot.rst (renamed from Documentation/x86/boot.txt) | 528 | ||||
| -rw-r--r-- | Documentation/x86/index.rst | 2 |
2 files changed, 327 insertions, 203 deletions
diff --git a/Documentation/x86/boot.txt b/Documentation/x86/boot.rst index 223e484a1304..08a2f100c0e6 100644 --- a/Documentation/x86/boot.txt +++ b/Documentation/x86/boot.rst @@ -1,5 +1,8 @@ - THE LINUX/x86 BOOT PROTOCOL - --------------------------- +.. SPDX-License-Identifier: GPL-2.0 + +=========================== +The Linux/x86 Boot Protocol +=========================== On the x86 platform, the Linux kernel uses a rather complicated boot convention. This has evolved partially due to historical aspects, as @@ -10,88 +13,91 @@ real-mode DOS as a mainstream operating system. Currently, the following versions of the Linux/x86 boot protocol exist. -Old kernels: zImage/Image support only. Some very early kernels +============= ============================================================ +Old kernels zImage/Image support only. Some very early kernels may not even support a command line. -Protocol 2.00: (Kernel 1.3.73) Added bzImage and initrd support, as +Protocol 2.00 (Kernel 1.3.73) Added bzImage and initrd support, as well as a formalized way to communicate between the boot loader and the kernel. setup.S made relocatable, although the traditional setup area still assumed writable. -Protocol 2.01: (Kernel 1.3.76) Added a heap overrun warning. +Protocol 2.01 (Kernel 1.3.76) Added a heap overrun warning. -Protocol 2.02: (Kernel 2.4.0-test3-pre3) New command line protocol. +Protocol 2.02 (Kernel 2.4.0-test3-pre3) New command line protocol. Lower the conventional memory ceiling. No overwrite of the traditional setup area, thus making booting safe for systems which use the EBDA from SMM or 32-bit BIOS entry points. zImage deprecated but still supported. -Protocol 2.03: (Kernel 2.4.18-pre1) Explicitly makes the highest possible +Protocol 2.03 (Kernel 2.4.18-pre1) Explicitly makes the highest possible initrd address available to the bootloader. -Protocol 2.04: (Kernel 2.6.14) Extend the syssize field to four bytes. +Protocol 2.04 (Kernel 2.6.14) Extend the syssize field to four bytes. -Protocol 2.05: (Kernel 2.6.20) Make protected mode kernel relocatable. +Protocol 2.05 (Kernel 2.6.20) Make protected mode kernel relocatable. Introduce relocatable_kernel and kernel_alignment fields. -Protocol 2.06: (Kernel 2.6.22) Added a field that contains the size of +Protocol 2.06 (Kernel 2.6.22) Added a field that contains the size of the boot command line. -Protocol 2.07: (Kernel 2.6.24) Added paravirtualised boot protocol. +Protocol 2.07 (Kernel 2.6.24) Added paravirtualised boot protocol. Introduced hardware_subarch and hardware_subarch_data and KEEP_SEGMENTS flag in load_flags. -Protocol 2.08: (Kernel 2.6.26) Added crc32 checksum and ELF format +Protocol 2.08 (Kernel 2.6.26) Added crc32 checksum and ELF format payload. Introduced payload_offset and payload_length fields to aid in locating the payload. -Protocol 2.09: (Kernel 2.6.26) Added a field of 64-bit physical +Protocol 2.09 (Kernel 2.6.26) Added a field of 64-bit physical pointer to single linked list of struct setup_data. -Protocol 2.10: (Kernel 2.6.31) Added a protocol for relaxed alignment +Protocol 2.10 (Kernel 2.6.31) Added a protocol for relaxed alignment beyond the kernel_alignment added, new init_size and pref_address fields. Added extended boot loader IDs. -Protocol 2.11: (Kernel 3.6) Added a field for offset of EFI handover +Protocol 2.11 (Kernel 3.6) Added a field for offset of EFI handover protocol entry point. -Protocol 2.12: (Kernel 3.8) Added the xloadflags field and extension fields +Protocol 2.12 (Kernel 3.8) Added the xloadflags field and extension fields to struct boot_params for loading bzImage and ramdisk above 4G in 64bit. -Protocol 2.13: (Kernel 3.14) Support 32- and 64-bit flags being set in +Protocol 2.13 (Kernel 3.14) Support 32- and 64-bit flags being set in xloadflags to support booting a 64-bit kernel from 32-bit EFI +============= ============================================================ -**** MEMORY LAYOUT -The traditional memory map for the kernel loader, used for Image or -zImage kernels, typically looks like: - - | | -0A0000 +------------------------+ - | Reserved for BIOS | Do not use. Reserved for BIOS EBDA. -09A000 +------------------------+ - | Command line | - | Stack/heap | For use by the kernel real-mode code. -098000 +------------------------+ - | Kernel setup | The kernel real-mode code. -090200 +------------------------+ - | Kernel boot sector | The kernel legacy boot sector. -090000 +------------------------+ - | Protected-mode kernel | The bulk of the kernel image. -010000 +------------------------+ - | Boot loader | <- Boot sector entry point 0000:7C00 -001000 +------------------------+ - | Reserved for MBR/BIOS | -000800 +------------------------+ - | Typically used by MBR | -000600 +------------------------+ - | BIOS use only | -000000 +------------------------+ +Memory Layout +============= +The traditional memory map for the kernel loader, used for Image or +zImage kernels, typically looks like:: + + | | + 0A0000 +------------------------+ + | Reserved for BIOS | Do not use. Reserved for BIOS EBDA. + 09A000 +------------------------+ + | Command line | + | Stack/heap | For use by the kernel real-mode code. + 098000 +------------------------+ + | Kernel setup | The kernel real-mode code. + 090200 +------------------------+ + | Kernel boot sector | The kernel legacy boot sector. + 090000 +------------------------+ + | Protected-mode kernel | The bulk of the kernel image. + 010000 +------------------------+ + | Boot loader | <- Boot sector entry point 0000:7C00 + 001000 +------------------------+ + | Reserved for MBR/BIOS | + 000800 +------------------------+ + | Typically used by MBR | + 000600 +------------------------+ + | BIOS use only | + 000000 +------------------------+ When using bzImage, the protected-mode kernel was relocated to 0x100000 ("high memory"), and the kernel real-mode block (boot sector, @@ -116,36 +122,36 @@ zImage or old bzImage kernels, which need data written into the above the 0x9A000 point; too many BIOSes will break above that point. For a modern bzImage kernel with boot protocol version >= 2.02, a -memory layout like the following is suggested: - - ~ ~ - | Protected-mode kernel | -100000 +------------------------+ - | I/O memory hole | -0A0000 +------------------------+ - | Reserved for BIOS | Leave as much as possible unused - ~ ~ - | Command line | (Can also be below the X+10000 mark) -X+10000 +------------------------+ - | Stack/heap | For use by the kernel real-mode code. -X+08000 +------------------------+ - | Kernel setup | The kernel real-mode code. - | Kernel boot sector | The kernel legacy boot sector. -X +------------------------+ - | Boot loader | <- Boot sector entry point 0000:7C00 -001000 +------------------------+ - | Reserved for MBR/BIOS | -000800 +------------------------+ - | Typically used by MBR | -000600 +------------------------+ - | BIOS use only | -000000 +------------------------+ - -... where the address X is as low as the design of the boot loader -permits. - - -**** THE REAL-MODE KERNEL HEADER +memory layout like the following is suggested:: + + ~ ~ + | Protected-mode kernel | + 100000 +------------------------+ + | I/O memory hole | + 0A0000 +------------------------+ + | Reserved for BIOS | Leave as much as possible unused + ~ ~ + | Command line | (Can also be below the X+10000 mark) + X+10000 +------------------------+ + | Stack/heap | For use by the kernel real-mode code. + X+08000 +------------------------+ + | Kernel setup | The kernel real-mode code. + | Kernel boot sector | The kernel legacy boot sector. + X +------------------------+ + | Boot loader | <- Boot sector entry point 0000:7C00 + 001000 +------------------------+ + | Reserved for MBR/BIOS | + 000800 +------------------------+ + | Typically used by MBR | + 000600 +------------------------+ + | BIOS use only | + 000000 +------------------------+ + + ... where the address X is as low as the design of the boot loader permits. + + +The Real-Mode Kernel Header +=========================== In the following text, and anywhere in the kernel boot sequence, "a sector" refers to 512 bytes. It is independent of the actual sector @@ -159,61 +165,63 @@ sectors (1K) and then examine the bootup sector size. The header looks like: -Offset Proto Name Meaning -/Size - -01F1/1 ALL(1 setup_sects The size of the setup in sectors -01F2/2 ALL root_flags If set, the root is mounted readonly -01F4/4 2.04+(2 syssize The size of the 32-bit code in 16-byte paras -01F8/2 ALL ram_size DO NOT USE - for bootsect.S use only -01FA/2 ALL vid_mode Video mode control -01FC/2 ALL root_dev Default root device number -01FE/2 ALL boot_flag 0xAA55 magic number -0200/2 2.00+ jump Jump instruction -0202/4 2.00+ header Magic signature "HdrS" -0206/2 2.00+ version Boot protocol version supported -0208/4 2.00+ realmode_swtch Boot loader hook (see below) -020C/2 2.00+ start_sys_seg The load-low segment (0x1000) (obsolete) -020E/2 2.00+ kernel_version Pointer to kernel version string -0210/1 2.00+ type_of_loader Boot loader identifier -0211/1 2.00+ loadflags Boot protocol option flags -0212/2 2.00+ setup_move_size Move to high memory size (used with hooks) -0214/4 2.00+ code32_start Boot loader hook (see below) -0218/4 2.00+ ramdisk_image initrd load address (set by boot loader) -021C/4 2.00+ ramdisk_size initrd size (set by boot loader) -0220/4 2.00+ bootsect_kludge DO NOT USE - for bootsect.S use only -0224/2 2.01+ heap_end_ptr Free memory after setup end -0226/1 2.02+(3 ext_loader_ver Extended boot loader version -0227/1 2.02+(3 ext_loader_type Extended boot loader ID -0228/4 2.02+ cmd_line_ptr 32-bit pointer to the kernel command line -022C/4 2.03+ initrd_addr_max Highest legal initrd address -0230/4 2.05+ kernel_alignment Physical addr alignment required for kernel -0234/1 2.05+ relocatable_kernel Whether kernel is relocatable or not -0235/1 2.10+ min_alignment Minimum alignment, as a power of two -0236/2 2.12+ xloadflags Boot protocol option flags -0238/4 2.06+ cmdline_size Maximum size of the kernel command line -023C/4 2.07+ hardware_subarch Hardware subarchitecture -0240/8 2.07+ hardware_subarch_data Subarchitecture-specific data -0248/4 2.08+ payload_offset Offset of kernel payload -024C/4 2.08+ payload_length Length of kernel payload -0250/8 2.09+ setup_data 64-bit physical pointer to linked list - of struct setup_data -0258/8 2.10+ pref_address Preferred loading address -0260/4 2.10+ init_size Linear memory required during initialization -0264/4 2.11+ handover_offset Offset of handover entry point - -(1) For backwards compatibility, if the setup_sects field contains 0, the - real value is 4. - -(2) For boot protocol prior to 2.04, the upper two bytes of the syssize - field are unusable, which means the size of a bzImage kernel - cannot be determined. - -(3) Ignored, but safe to set, for boot protocols 2.02-2.09. +=========== ======== ===================== ============================================ +Offset/Size Proto Name Meaning +=========== ======== ===================== ============================================ +01F1/1 ALL(1) setup_sects The size of the setup in sectors +01F2/2 ALL root_flags If set, the root is mounted readonly +01F4/4 2.04+(2) syssize The size of the 32-bit code in 16-byte paras +01F8/2 ALL ram_size DO NOT USE - for bootsect.S use only +01FA/2 ALL vid_mode Video mode control +01FC/2 ALL root_dev Default root device number +01FE/2 ALL boot_flag 0xAA55 magic number +0200/2 2.00+ jump Jump instruction +0202/4 2.00+ header Magic signature "HdrS" +0206/2 2.00+ version Boot protocol version supported +0208/4 2.00+ realmode_swtch Boot loader hook (see below) +020C/2 2.00+ start_sys_seg The load-low segment (0x1000) (obsolete) +020E/2 2.00+ kernel_version Pointer to kernel version string +0210/1 2.00+ type_of_loader Boot loader identifier +0211/1 2.00+ loadflags Boot protocol option flags +0212/2 2.00+ setup_move_size Move to high memory size (used with hooks) +0214/4 2.00+ code32_start Boot loader hook (see below) +0218/4 2.00+ ramdisk_image initrd load address (set by boot loader) +021C/4 2.00+ ramdisk_size initrd size (set by boot loader) +0220/4 2.00+ bootsect_kludge DO NOT USE - for bootsect.S use only +0224/2 2.01+ heap_end_ptr Free memory after setup end +0226/1 2.02+(3) ext_loader_ver Extended boot loader version +0227/1 2.02+(3) ext_loader_type Extended boot loader ID +0228/4 2.02+ cmd_line_ptr 32-bit pointer to the kernel command line +022C/4 2.03+ initrd_addr_max Highest legal initrd address +0230/4 2.05+ kernel_alignment Physical addr alignment required for kernel +0234/1 2.05+ relocatable_kernel Whether kernel is relocatable or not +0235/1 2.10+ min_alignment Minimum alignment, as a power of two +0236/2 2.12+ xloadflags Boot protocol option flags +0238/4 2.06+ cmdline_size Maximum size of the kernel command line +023C/4 2.07+ hardware_subarch Hardware subarchitecture +0240/8 2.07+ hardware_subarch_data Subarchitecture-specific data +0248/4 2.08+ payload_offset Offset of kernel payload +024C/4 2.08+ payload_length Length of kernel payload +0250/8 2.09+ setup_data 64-bit physical pointer to linked list + of struct setup_data +0258/8 2.10+ pref_address Preferred loading address +0260/4 2.10+ init_size Linear memory required during initialization +0264/4 2.11+ handover_offset Offset of handover entry point +=========== ======== ===================== ============================================ + +.. note:: + (1) For backwards compatibility, if the setup_sects field contains 0, the + real value is 4. + + (2) For boot protocol prior to 2.04, the upper two bytes of the syssize + field are unusable, which means the size of a bzImage kernel + cannot be determined. + + (3) Ignored, but safe to set, for boot protocols 2.02-2.09. If the "HdrS" (0x53726448) magic number is not found at offset 0x202, the boot protocol version is "old". Loading an old kernel, the -following parameters should be assumed: +following parameters should be assumed:: Image type = zImage initrd not supported @@ -225,7 +233,8 @@ setting fields in the header, you must make sure only to set fields supported by the protocol version in use. -**** DETAILS OF HEADER FIELDS +Details of Harder Fileds +======================== For each field, some are information from the kernel to the bootloader ("read"), some are expected to be filled out by the bootloader @@ -239,106 +248,132 @@ boot loaders can ignore those fields. The byte order of all fields is littleendian (this is x86, after all.) +============ =========== Field name: setup_sects Type: read Offset/size: 0x1f1/1 Protocol: ALL +============ =========== The size of the setup code in 512-byte sectors. If this field is 0, the real value is 4. The real-mode code consists of the boot sector (always one 512-byte sector) plus the setup code. -Field name: root_flags -Type: modify (optional) -Offset/size: 0x1f2/2 -Protocol: ALL +============ ================= +Field name: root_flags +Type: modify (optional) +Offset/size: 0x1f2/2 +Protocol: ALL +============ ================= If this field is nonzero, the root defaults to readonly. The use of this field is deprecated; use the "ro" or "rw" options on the command line instead. +============ =============================================== Field name: syssize Type: read Offset/size: 0x1f4/4 (protocol 2.04+) 0x1f4/2 (protocol ALL) Protocol: 2.04+ +============ =============================================== The size of the protected-mode code in units of 16-byte paragraphs. For protocol versions older than 2.04 this field is only two bytes wide, and therefore cannot be trusted for the size of a kernel if the LOAD_HIGH flag is set. +============ =============== Field name: ram_size Type: kernel internal Offset/size: 0x1f8/2 Protocol: ALL +============ =============== This field is obsolete. +============ =================== Field name: vid_mode Type: modify (obligatory) Offset/size: 0x1fa/2 +============ =================== Please see the section on SPECIAL COMMAND LINE OPTIONS. +============ ================= Field name: root_dev Type: modify (optional) Offset/size: 0x1fc/2 Protocol: ALL +============ ================= The default root device device number. The use of this field is deprecated, use the "root=" option on the command line instead. +============ ========= Field name: boot_flag Type: read Offset/size: 0x1fe/2 Protocol: ALL +============ ========= Contains 0xAA55. This is the closest thing old Linux kernels have to a magic number. +============ ======= Field name: jump Type: read Offset/size: 0x200/2 Protocol: 2.00+ +============ ======= Contains an x86 jump instruction, 0xEB followed by a signed offset relative to byte 0x202. This can be used to determine the size of the header. +============ ======= Field name: header Type: read Offset/size: 0x202/4 Protocol: 2.00+ +============ ======= Contains the magic number "HdrS" (0x53726448). +============ ======= Field name: version Type: read Offset/size: 0x206/2 Protocol: 2.00+ +============ ======= Contains the boot protocol version, in (major << 8)+minor format, e.g. 0x0204 for version 2.04, and 0x0a11 for a hypothetical version 10.17. +============ ================= Field name: realmode_swtch Type: modify (optional) Offset/size: 0x208/4 Protocol: 2.00+ +============ ================= Boot loader hook (see ADVANCED BOOT LOADER HOOKS below.) +============ ============= Field name: start_sys_seg Type: read Offset/size: 0x20c/2 Protocol: 2.00+ +============ ============= The load low segment (0x1000). Obsolete. +============ ============== Field name: kernel_version Type: read Offset/size: 0x20e/2 Protocol: 2.00+ +============ ============== If set to a nonzero value, contains a pointer to a NUL-terminated human-readable kernel version number string, less 0x200. This can @@ -348,17 +383,19 @@ Protocol: 2.00+ For example, if this value is set to 0x1c00, the kernel version number string can be found at offset 0x1e00 in the kernel file. This is a valid value if and only if the "setup_sects" field - contains the value 15 or higher, as: + contains the value 15 or higher, as:: 0x1c00 < 15*0x200 (= 0x1e00) but 0x1c00 >= 14*0x200 (= 0x1c00) - 0x1c00 >> 9 = 14, so the minimum value for setup_secs is 15. + 0x1c00 >> 9 = 14, So the minimum value for setup_secs is 15. +============ ================== Field name: type_of_loader Type: write (obligatory) Offset/size: 0x210/1 Protocol: 2.00+ +============ ================== If your boot loader has an assigned id (see table below), enter 0xTV here, where T is an identifier for the boot loader and V is @@ -369,17 +406,20 @@ Protocol: 2.00+ Similarly, the ext_loader_ver field can be used to provide more than four bits for the bootloader version. - For example, for T = 0x15, V = 0x234, write: + For example, for T = 0x15, V = 0x234, write:: - type_of_loader <- 0xE4 - ext_loader_type <- 0x05 - ext_loader_ver <- 0x23 + type_of_loader <- 0xE4 + ext_loader_type <- 0x05 + ext_loader_ver <- 0x23 Assigned boot loader ids (hexadecimal): - 0 LILO (0x00 reserved for pre-2.00 bootloader) + == ======================================= + 0 LILO + (0x00 reserved for pre-2.00 bootloader) 1 Loadlin - 2 bootsect-loader (0x20, all other values reserved) + 2 bootsect-loader + (0x20, all other values reserved) 3 Syslinux 4 Etherboot/gPXE/iPXE 5 ELILO @@ -390,55 +430,70 @@ Protocol: 2.00+ B Qemu C Arcturus Networks uCbootloader D kexec-tools - E Extended (see ext_loader_type) - F Special (0xFF = undefined) - 10 Reserved - 11 Minimal Linux Bootloader <http://sebastian-plotz.blogspot.de> - 12 OVMF UEFI virtualization stack + E Extended (see ext_loader_type) + F Special (0xFF = undefined) + 10 Reserved + 11 Minimal Linux Bootloader + <http://sebastian-plotz.blogspot.de> + 12 OVMF UEFI virtualization stack + == ======================================= - Please contact <hpa@zytor.com> if you need a bootloader ID - value assigned. + Please contact <hpa@zytor.com> if you need a bootloader ID value assigned. +============ =================== Field name: loadflags Type: modify (obligatory) Offset/size: 0x211/1 Protocol: 2.00+ +============ =================== This field is a bitmask. Bit 0 (read): LOADED_HIGH + - If 0, the protected-mode code is loaded at 0x10000. - If 1, the protected-mode code is loaded at 0x100000. Bit 1 (kernel internal): KASLR_FLAG + - Used internally by the compressed kernel to communicate KASLR status to kernel proper. - If 1, KASLR enabled. - If 0, KASLR disabled. + + - If 1, KASLR enabled. + - If 0, KASLR disabled. Bit 5 (write): QUIET_FLAG + - If 0, print early messages. - If 1, suppress early messages. + This requests to the kernel (decompressor and early kernel) to not write early messages that require accessing the display hardware directly. Bit 6 (write): KEEP_SEGMENTS + Protocol: 2.07+ + - If 0, reload the segment registers in the 32bit entry point. - If 1, do not reload the segment registers in the 32bit entry point. + Assume that %cs %ds %ss %es are all set to flat segments with a base of 0 (or the equivalent for their environment). Bit 7 (write): CAN_USE_HEAP + Set this bit to 1 to indicate that the value entered in the heap_end_ptr is valid. If this field is clear, some setup code functionality will be disabled. + +============ =================== Field name: setup_move_size Type: modify (obligatory) Offset/size: 0x212/2 Protocol: 2.00-2.01 +============ =================== When using protocol 2.00 or 2.01, if the real mode kernel is not loaded at 0x90000, it gets moved there later in the loading @@ -447,14 +502,16 @@ Protocol: 2.00-2.01 itself. The unit is bytes starting with the beginning of the boot sector. - + This field is can be ignored when the protocol is 2.02 or higher, or if the real-mode code is loaded at 0x90000. +============ ======================== Field name: code32_start Type: modify (optional, reloc) Offset/size: 0x214/4 Protocol: 2.00+ +============ ======================== The address to jump to in protected mode. This defaults to the load address of the kernel, and can be used by the boot loader to @@ -462,47 +519,57 @@ Protocol: 2.00+ This field can be modified for two purposes: - 1. as a boot loader hook (see ADVANCED BOOT LOADER HOOKS below.) + 1. as a boot loader hook (see Advanced Boot Loader Hooks below.) - 2. if a bootloader which does not install a hook loads a - relocatable kernel at a nonstandard address it will have to modify - this field to point to the load address. + 2. if a bootloader which does not install a hook loads a + relocatable kernel at a nonstandard address it will have to modify + this field to point to the load address. +============ ================== Field name: ramdisk_image Type: write (obligatory) Offset/size: 0x218/4 Protocol: 2.00+ +============ ================== The 32-bit linear address of the initial ramdisk or ramfs. Leave at zero if there is no initial ramdisk/ramfs. +============ ================== Field name: ramdisk_size Type: write (obligatory) Offset/size: 0x21c/4 Protocol: 2.00+ +============ ================== Size of the initial ramdisk or ramfs. Leave at zero if there is no initial ramdisk/ramfs. +============ =============== Field name: bootsect_kludge Type: kernel internal Offset/size: 0x220/4 Protocol: 2.00+ +============ =============== This field is obsolete. +============ ================== Field name: heap_end_ptr Type: write (obligatory) Offset/size: 0x224/2 Protocol: 2.01+ +============ ================== Set this field to the offset (from the beginning of the real-mode code) of the end of the setup stack/heap, minus 0x0200. +============ ================ Field name: ext_loader_ver Type: write (optional) Offset/size: 0x226/1 Protocol: 2.02+ +============ ================ This field is used as an extension of the version number in the type_of_loader field. The total version number is considered to be @@ -514,10 +581,12 @@ Protocol: 2.02+ Kernels prior to 2.6.31 did not recognize this field, but it is safe to write for protocol version 2.02 or higher. +============ ===================================================== Field name: ext_loader_type Type: write (obligatory if (type_of_loader & 0xf0) == 0xe0) Offset/size: 0x227/1 Protocol: 2.02+ +============ ===================================================== This field is used as an extension of the type number in type_of_loader field. If the type in type_of_loader is 0xE, then @@ -528,10 +597,12 @@ Protocol: 2.02+ Kernels prior to 2.6.31 did not recognize this field, but it is safe to write for protocol version 2.02 or higher. +============ ================== Field name: cmd_line_ptr Type: write (obligatory) Offset/size: 0x228/4 Protocol: 2.02+ +============ ================== Set this field to the linear address of the kernel command line. The kernel command line can be located anywhere between the end of @@ -544,10 +615,12 @@ Protocol: 2.02+ zero, the kernel will assume that your boot loader does not support the 2.02+ protocol. +============ =============== Field name: initrd_addr_max Type: read Offset/size: 0x22c/4 Protocol: 2.03+ +============ =============== The maximum address that may be occupied by the initial ramdisk/ramfs contents. For boot protocols 2.02 or earlier, this @@ -556,10 +629,12 @@ Protocol: 2.03+ your ramdisk is exactly 131072 bytes long and this field is 0x37FFFFFF, you can start your ramdisk at 0x37FE0000.) +============ ============================ Field name: kernel_alignment Type: read/modify (reloc) Offset/size: 0x230/4 Protocol: 2.05+ (read), 2.10+ (modify) +============ ============================ Alignment unit required by the kernel (if relocatable_kernel is true.) A relocatable kernel that is loaded at an alignment @@ -571,25 +646,29 @@ Protocol: 2.05+ (read), 2.10+ (modify) loader to modify this field to permit a lesser alignment. See the min_alignment and pref_address field below. +============ ================== Field name: relocatable_kernel Type: read (reloc) Offset/size: 0x234/1 Protocol: 2.05+ +============ ================== If this field is nonzero, the protected-mode part of the kernel can be loaded at any address that satisfies the kernel_alignment field. After loading, the boot loader must set the code32_start field to point to the loaded code, or to a boot loader hook. +============ ============= Field name: min_alignment Type: read (reloc) Offset/size: 0x235/1 Protocol: 2.10+ +============ ============= This field, if nonzero, indicates as a power of two the minimum alignment required, as opposed to preferred, by the kernel to boot. If a boot loader makes use of this field, it should update the - kernel_alignment field with the alignment unit desired; typically: + kernel_alignment field with the alignment unit desired; typically:: kernel_alignment = 1 << min_alignment @@ -597,44 +676,56 @@ Protocol: 2.10+ misaligned kernel. Therefore, a loader should typically try each power-of-two alignment from kernel_alignment down to this alignment. -Field name: xloadflags -Type: read -Offset/size: 0x236/2 -Protocol: 2.12+ +============ ========== +Field name: xloadflags +Type: read +Offset/size: 0x236/2 +Protocol: 2.12+ +============ ========== This field is a bitmask. Bit 0 (read): XLF_KERNEL_64 + - If 1, this kernel has the legacy 64-bit entry point at 0x200. Bit 1 (read): XLF_CAN_BE_LOADED_ABOVE_4G + - If 1, kernel/boot_params/cmdline/ramdisk can be above 4G. Bit 2 (read): XLF_EFI_HANDOVER_32 + - If 1, the kernel supports the 32-bit EFI handoff entry point given at handover_offset. Bit 3 (read): XLF_EFI_HANDOVER_64 + - If 1, the kernel supports the 64-bit EFI handoff entry point given at handover_offset + 0x200. Bit 4 (read): XLF_EFI_KEXEC + - If 1, the kernel supports kexec EFI boot with EFI runtime support. + +============ ============ Field name: cmdline_size Type: read Offset/size: 0x238/4 Protocol: 2.06+ +============ ============ The maximum size of the command line without the terminating zero. This means that the command line can contain at most cmdline_size characters. With protocol version 2.05 and earlier, the maximum size was 255. +============ ==================================== Field name: hardware_subarch Type: write (optional, defaults to x86/PC) Offset/size: 0x23c/4 Protocol: 2.07+ +============ ==================================== In a paravirtualized environment the hardware low level architectural pieces such as interrupt handling, page table handling, and @@ -643,25 +734,31 @@ Protocol: 2.07+ This field allows the bootloader to inform the kernel we are in one one of those environments. + ========== ============================== 0x00000000 The default x86/PC environment 0x00000001 lguest 0x00000002 Xen 0x00000003 Moorestown MID 0x00000004 CE4100 TV Platform + ========== ============================== +============ ========================= Field name: hardware_subarch_data Type: write (subarch-dependent) Offset/size: 0x240/8 Protocol: 2.07+ +============ ========================= A pointer to data that is specific to hardware subarch This field is currently unused for the default x86/PC environment, do not modify. +============ ============== Field name: payload_offset Type: read Offset/size: 0x248/4 Protocol: 2.08+ +============ ============== If non-zero then this field contains the offset from the beginning of the protected-mode code to the payload. @@ -674,29 +771,33 @@ Protocol: 2.08+ 02 21). The uncompressed payload is currently always ELF (magic number 7F 45 4C 46). +============ ============== Field name: payload_length Type: read Offset/size: 0x24c/4 Protocol: 2.08+ +============ ============== The length of the payload. +============ =============== Field name: setup_data Type: write (special) Offset/size: 0x250/8 Protocol: 2.09+ +============ =============== The 64-bit physical pointer to NULL terminated single linked list of struct setup_data. This is used to define a more extensible boot parameters passing mechanism. The definition of struct setup_data is - as follow: + as follow:: - struct setup_data { - u64 next; - u32 type; - u32 len; - u8 data[0]; - }; + struct setup_data { + u64 next; + u32 type; + u32 len; + u8 data[0]; + }; Where, the next is a 64-bit physical pointer to the next node of linked list, the next field of the last node is 0; the type is used @@ -708,10 +809,12 @@ Protocol: 2.09+ sure to consider the case where the linked list already contains entries. +============ ============ Field name: pref_address Type: read (reloc) Offset/size: 0x258/8 Protocol: 2.10+ +============ ============ This field, if nonzero, represents a preferred load address for the kernel. A relocating bootloader should attempt to load at this @@ -720,9 +823,11 @@ Protocol: 2.10+ A non-relocatable kernel will unconditionally move itself and to run at this address. +============ ======= Field name: init_size Type: read Offset/size: 0x260/4 +============ ======= This field indicates the amount of linear contiguous memory starting at the kernel runtime start address that the kernel needs before it @@ -731,16 +836,18 @@ Offset/size: 0x260/4 be used by a relocating boot loader to help select a safe load address for the kernel. - The kernel runtime start address is determined by the following algorithm: + The kernel runtime start address is determined by the following algorithm:: - if (relocatable_kernel) + if (relocatable_kernel) runtime_start = align_up(load_address, kernel_alignment) - else + else runtime_start = pref_address +============ =============== Field name: handover_offset Type: read Offset/size: 0x264/4 +============ =============== This field is the offset from the beginning of the kernel image to the EFI handover protocol entry point. Boot loaders using the EFI @@ -749,7 +856,8 @@ Offset/size: 0x264/4 See EFI HANDOVER PROTOCOL below for more details. -**** THE IMAGE CHECKSUM +The Image Checksum +================== From boot protocol version 2.08 onwards the CRC-32 is calculated over the entire file using the characteristic polynomial 0x04C11DB7 and an @@ -758,7 +866,8 @@ file; therefore the CRC of the file up to the limit specified in the syssize field of the header is always 0. -**** THE KERNEL COMMAND LINE +The Kernel Command Line +======================= The kernel command line has become an important way for the boot loader to communicate with the kernel. Some of its options are also @@ -778,19 +887,20 @@ heap and 0xA0000. If the protocol version is *not* 2.02 or higher, the kernel command line is entered using the following protocol: - At offset 0x0020 (word), "cmd_line_magic", enter the magic - number 0xA33F. + - At offset 0x0020 (word), "cmd_line_magic", enter the magic + number 0xA33F. + + - At offset 0x0022 (word), "cmd_line_offset", enter the offset + of the kernel command line (relative to the start of the + real-mode kernel). - At offset 0x0022 (word), "cmd_line_offset", enter the offset - of the kernel command line (relative to the start of the - real-mode kernel). - - The kernel command line *must* be within the memory region - covered by setup_move_size, so you may need to adjust this - field. + - The kernel command line *must* be within the memory region + covered by setup_move_size, so you may need to adjust this + field. -**** MEMORY LAYOUT OF THE REAL-MODE CODE +Memory Layout of The Real-Mode Code +=================================== The real-mode code requires a stack/heap to be set up, as well as memory allocated for the kernel command line. This needs to be done @@ -806,10 +916,11 @@ segment has to be used: - When loading a zImage kernel ((loadflags & 0x01) == 0). - When loading a 2.01 or earlier boot protocol kernel. - -> For the 2.00 and 2.01 boot protocols, the real-mode code - can be loaded at another address, but it is internally - relocated to 0x90000. For the "old" protocol, the - real-mode code must be loaded at 0x90000. +.. note:: + For the 2.00 and 2.01 boot protocols, the real-mode code + can be loaded at another address, but it is internally + relocated to 0x90000. For the "old" protocol, the + real-mode code must be loaded at 0x90000. When loading at 0x90000, avoid using memory above 0x9a000. @@ -822,24 +933,29 @@ The kernel command line should not be located below the real-mode code, nor should it be located in high memory. -**** SAMPLE BOOT CONFIGURATION +Sample Boot Configuartion +========================= As a sample configuration, assume the following layout of the real -mode segment: +mode segment. When loading below 0x90000, use the entire segment: + ============= =================== 0x0000-0x7fff Real mode kernel 0x8000-0xdfff Stack and heap 0xe000-0xffff Kernel command line + ============= =================== When loading at 0x90000 OR the protocol version is 2.01 or earlier: + ============= =================== 0x0000-0x7fff Real mode kernel 0x8000-0x97ff Stack and heap 0x9800-0x9fff Kernel command line + ============= =================== -Such a boot loader should enter the following fields in the header: +Such a boot loader should enter the following fields in the header:: unsigned long base_ptr; /* base address for real-mode segment */ @@ -898,7 +1014,8 @@ Such a boot loader should enter the following fields in the header: } -**** LOADING THE REST OF THE KERNEL +Loading The Rest of The Kernel +============================== The 32-bit (non-real-mode) kernel starts at offset (setup_sects+1)*512 in the kernel file (again, if setup_sects == 0 the real value is 4.) @@ -906,7 +1023,7 @@ It should be loaded at address 0x10000 for Image/zImage kernels and 0x100000 for bzImage kernels. The kernel is a bzImage kernel if the protocol >= 2.00 and the 0x01 -bit (LOAD_HIGH) in the loadflags field is set: +bit (LOAD_HIGH) in the loadflags field is set:: is_bzImage = (protocol >= 0x0200) && (loadflags & 0x01); load_address = is_bzImage ? 0x100000 : 0x10000; @@ -916,8 +1033,8 @@ the entire 0x10000-0x90000 range of memory. This means it is pretty much a requirement for these kernels to load the real-mode part at 0x90000. bzImage kernels allow much more flexibility. - -**** SPECIAL COMMAND LINE OPTIONS +Special Command Line Options +============================ If the command line provided by the boot loader is entered by the user, the user may expect the following command line options to work. @@ -966,7 +1083,8 @@ or configuration-specified command line. Otherwise, "init=/bin/sh" gets confused by the "auto" option. -**** RUNNING THE KERNEL +Running the Kernel +================== The kernel is started by jumping to the kernel entry point, which is located at *segment* offset 0x20 from the start of the real mode @@ -980,7 +1098,7 @@ interrupts should be disabled. Furthermore, to guard against bugs in the kernel, it is recommended that the boot loader sets fs = gs = ds = es = ss. -In our example from above, we would do: +In our example from above, we would do:: /* Note: in the case of the "old" kernel protocol, base_ptr must be == 0x90000 at this point; see the previous sample code */ @@ -1003,7 +1121,8 @@ switched off, especially if the loaded kernel has the floppy driver as a demand-loaded module! -**** ADVANCED BOOT LOADER HOOKS +Advanced Boot Loader Hooks +========================== If the boot loader runs in a particularly hostile environment (such as LOADLIN, which runs under DOS) it may be impossible to follow the @@ -1032,7 +1151,8 @@ IMPORTANT: All the hooks are required to preserve %esp, %ebp, %esi and (relocated, if appropriate.) -**** 32-bit BOOT PROTOCOL +32-bit Boot Protocol +==================== For machine with some new BIOS other than legacy BIOS, such as EFI, LinuxBIOS, etc, and kexec, the 16-bit real mode setup code in kernel @@ -1045,7 +1165,7 @@ traditionally known as "zero page"). The memory for struct boot_params should be allocated and initialized to all zero. Then the setup header from offset 0x01f1 of kernel image on should be loaded into struct boot_params and examined. The end of setup header can be calculated as -follow: +follow:: 0x0202 + byte value at offset 0x0201 @@ -1069,7 +1189,8 @@ must have read/write permission; CS must be __BOOT_CS and DS, ES, SS must be __BOOT_DS; interrupt must be disabled; %esi must hold the base address of the struct boot_params; %ebp, %edi and %ebx must be zero. -**** 64-bit BOOT PROTOCOL +64-bit Boot Protocol +==================== For machine with 64bit cpus and 64bit kernel, we could use 64bit bootloader and we need a 64-bit boot protocol. @@ -1080,7 +1201,7 @@ traditionally known as "zero page"). The memory for struct boot_params could be allocated anywhere (even above 4G) and initialized to all zero. Then, the setup header at offset 0x01f1 of kernel image on should be loaded into struct boot_params and examined. The end of setup header -can be calculated as follows: +can be calculated as follows:: 0x0202 + byte value at offset 0x0201 @@ -1107,7 +1228,8 @@ must have read/write permission; CS must be __BOOT_CS and DS, ES, SS must be __BOOT_DS; interrupt must be disabled; %rsi must hold the base address of the struct boot_params. -**** EFI HANDOVER PROTOCOL +EFI Handover Protocol +===================== This protocol allows boot loaders to defer initialisation to the EFI boot stub. The boot loader is required to load the kernel/initrd(s) @@ -1115,7 +1237,7 @@ from the boot media and jump to the EFI handover protocol entry point which is hdr->handover_offset bytes from the beginning of startup_{32,64}. -The function prototype for the handover entry point looks like this, +The function prototype for the handover entry point looks like this:: efi_main(void *handle, efi_system_table_t *table, struct boot_params *bp) @@ -1124,11 +1246,11 @@ firmware, 'table' is the EFI system table - these are the first two arguments of the "handoff state" as described in section 2.3 of the UEFI specification. 'bp' is the boot loader-allocated boot params. -The boot loader *must* fill out the following fields in bp, +The boot loader *must* fill out the following fields in bp:: - o hdr.code32_start - o hdr.cmd_line_ptr - o hdr.ramdisk_image (if applicable) - o hdr.ramdisk_size (if applicable) + - hdr.code32_start + - hdr.cmd_line_ptr + - hdr.ramdisk_image (if applicable) + - hdr.ramdisk_size (if applicable) All other fields should be zero. diff --git a/Documentation/x86/index.rst b/Documentation/x86/index.rst index 9f34545a9c52..d7fc8efac192 100644 --- a/Documentation/x86/index.rst +++ b/Documentation/x86/index.rst @@ -7,3 +7,5 @@ x86-specific Documentation .. toctree:: :maxdepth: 2 :numbered: + + boot |