Documentation: x86: convert boot.txt to reST
This converts the plain text documentation to reStructuredText format and add it to Sphinx TOC tree. No essential content change. Signed-off-by: Changbin Du <changbin.du@gmail.com> Cc: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Reviewed-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
This commit is contained in:
parent
e5def4c603
commit
f1f238a9f1
|
@ -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
|
||||
|
||||
Memory Layout
|
||||
=============
|
||||
|
||||
The traditional memory map for the kernel loader, used for Image or
|
||||
zImage kernels, typically looks like:
|
||||
zImage kernels, typically looks like::
|
||||
|
||||
| |
|
||||
0A0000 +------------------------+
|
||||
0A0000 +------------------------+
|
||||
| Reserved for BIOS | Do not use. Reserved for BIOS EBDA.
|
||||
09A000 +------------------------+
|
||||
09A000 +------------------------+
|
||||
| Command line |
|
||||
| Stack/heap | For use by the kernel real-mode code.
|
||||
098000 +------------------------+
|
||||
098000 +------------------------+
|
||||
| Kernel setup | The kernel real-mode code.
|
||||
090200 +------------------------+
|
||||
090200 +------------------------+
|
||||
| Kernel boot sector | The kernel legacy boot sector.
|
||||
090000 +------------------------+
|
||||
090000 +------------------------+
|
||||
| Protected-mode kernel | The bulk of the kernel image.
|
||||
010000 +------------------------+
|
||||
010000 +------------------------+
|
||||
| Boot loader | <- Boot sector entry point 0000:7C00
|
||||
001000 +------------------------+
|
||||
001000 +------------------------+
|
||||
| Reserved for MBR/BIOS |
|
||||
000800 +------------------------+
|
||||
000800 +------------------------+
|
||||
| Typically used by MBR |
|
||||
000600 +------------------------+
|
||||
000600 +------------------------+
|
||||
| BIOS use only |
|
||||
000000 +------------------------+
|
||||
|
||||
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:
|
||||
memory layout like the following is suggested::
|
||||
|
||||
~ ~
|
||||
| Protected-mode kernel |
|
||||
100000 +------------------------+
|
||||
100000 +------------------------+
|
||||
| I/O memory hole |
|
||||
0A0000 +------------------------+
|
||||
0A0000 +------------------------+
|
||||
| Reserved for BIOS | Leave as much as possible unused
|
||||
~ ~
|
||||
| Command line | (Can also be below the X+10000 mark)
|
||||
X+10000 +------------------------+
|
||||
X+10000 +------------------------+
|
||||
| Stack/heap | For use by the kernel real-mode code.
|
||||
X+08000 +------------------------+
|
||||
X+08000 +------------------------+
|
||||
| Kernel setup | The kernel real-mode code.
|
||||
| Kernel boot sector | The kernel legacy boot sector.
|
||||
X +------------------------+
|
||||
X +------------------------+
|
||||
| Boot loader | <- Boot sector entry point 0000:7C00
|
||||
001000 +------------------------+
|
||||
001000 +------------------------+
|
||||
| Reserved for MBR/BIOS |
|
||||
000800 +------------------------+
|
||||
000800 +------------------------+
|
||||
| Typically used by MBR |
|
||||
000600 +------------------------+
|
||||
000600 +------------------------+
|
||||
| BIOS use only |
|
||||
000000 +------------------------+
|
||||
000000 +------------------------+
|
||||
|
||||
... where the address X is as low as the design of the boot loader
|
||||
permits.
|
||||
... where the address X is as low as the design of the boot loader permits.
|
||||
|
||||
|
||||
**** THE REAL-MODE KERNEL HEADER
|
||||
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,12 +165,12 @@ 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
|
||||
=========== ======== ===================== ============================================
|
||||
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
|
||||
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
|
||||
|
@ -183,8 +189,8 @@ Offset Proto Name Meaning
|
|||
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
|
||||
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
|
||||
|
@ -201,19 +207,21 @@ Offset Proto Name Meaning
|
|||
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
|
||||
.. 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
|
||||
(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.
|
||||
(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
|
||||
============ =================
|
||||
|
||||
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,7 +406,7 @@ 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
|
||||
|
@ -377,9 +414,12 @@ Protocol: 2.00+
|
|||
|
||||
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
|
||||
|
@ -393,52 +433,67 @@ Protocol: 2.00+
|
|||
E Extended (see ext_loader_type)
|
||||
F Special (0xFF = undefined)
|
||||
10 Reserved
|
||||
11 Minimal Linux Bootloader <http://sebastian-plotz.blogspot.de>
|
||||
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
|
||||
|
@ -451,10 +506,12 @@ Protocol: 2.00-2.01
|
|||
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.
|
||||
|
||||
============ ==================
|
||||
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+
|
||||
============ ==========
|
||||
|
||||
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,22 +771,26 @@ 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;
|
||||
|
@ -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)
|
||||
runtime_start = align_up(load_address, kernel_alignment)
|
||||
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
|
||||
- At offset 0x0020 (word), "cmd_line_magic", enter the magic
|
||||
number 0xA33F.
|
||||
|
||||
At offset 0x0022 (word), "cmd_line_offset", enter the offset
|
||||
- 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
|
||||
- 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,7 +916,8 @@ 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
|
||||
.. 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.
|
||||
|
@ -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.
|
|
@ -7,3 +7,5 @@ x86-specific Documentation
|
|||
.. toctree::
|
||||
:maxdepth: 2
|
||||
:numbered:
|
||||
|
||||
boot
|
||||
|
|
Loading…
Reference in New Issue