| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-Id: <20190426153150.21228-3-changbin.du@gmail.com>
Date: Fri, 26 Apr 2019 23:31:25 +0800
From: Changbin Du <changbin.du@...il.com>
To: Jonathan Corbet <corbet@....net>
Cc: tglx@...utronix.de, mingo@...hat.com, bp@...en8.de, x86@...nel.org,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
mchehab+samsung@...nel.org, Changbin Du <changbin.du@...il.com>
Subject: [PATCH 02/27] 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@...il.com>
Cc: Mauro Carvalho Chehab <mchehab+samsung@...nel.org>
---
Documentation/x86/boot.rst | 1238 +++++++++++++++++++++++++++++++++++
Documentation/x86/boot.txt | 1130 --------------------------------
Documentation/x86/index.rst | 2 +
3 files changed, 1240 insertions(+), 1130 deletions(-)
create mode 100644 Documentation/x86/boot.rst
delete mode 100644 Documentation/x86/boot.txt
diff --git a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst
new file mode 100644
index 000000000000..9b289a72b53f
--- /dev/null
+++ b/Documentation/x86/boot.rst
@@ -0,0 +1,1238 @@
+.. 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
+well as the desire in the early days to have the kernel itself be a
+bootable image, the complicated PC memory model and due to changed
+expectations in the PC industry caused by the effective demise of
+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
+ may not even support a command line.
+
+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.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
+ initrd address available to the bootloader.
+
+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.
+ Introduce relocatable_kernel and kernel_alignment fields.
+
+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.
+ 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
+ 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
+ pointer to single linked list of struct setup_data.
+
+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 entry point.
+
+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.
+============= ============================================================
+
+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,
+setup, and stack/heap) was made relocatable to any address between
+0x10000 and end of low memory. Unfortunately, in protocols 2.00 and
+2.01 the 0x90000+ memory range is still used internally by the kernel;
+the 2.02 protocol resolves that problem.
+
+It is desirable to keep the "memory ceiling" -- the highest point in
+low memory touched by the boot loader -- as low as possible, since
+some newer BIOSes have begun to allocate some rather large amounts of
+memory, called the Extended BIOS Data Area, near the top of low
+memory. The boot loader should use the "INT 12h" BIOS call to verify
+how much low memory is available.
+
+Unfortunately, if INT 12h reports that the amount of memory is too
+low, there is usually nothing the boot loader can do but to report an
+error to the user. The boot loader should therefore be designed to
+take up as little space in low memory as it reasonably can. For
+zImage or old bzImage kernels, which need data written into the
+0x90000 segment, the boot loader should make sure not to use memory
+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
+===========================
+
+In the following text, and anywhere in the kernel boot sequence, "a
+sector" refers to 512 bytes. It is independent of the actual sector
+size of the underlying medium.
+
+The first step in loading a Linux kernel should be to load the
+real-mode code (boot sector and setup code) and then examine the
+following header at offset 0x01f1. The real-mode code can total up to
+32K, although the boot loader may choose to load only the first two
+sectors (1K) and then examine the bootup sector size.
+
+The header looks like::
+ =========== ======= ===================== ================================
+ 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::
+
+ Image type = zImage
+ initrd not supported
+ Real-mode kernel must be located at 0x90000.
+
+Otherwise, the "version" field contains the protocol version,
+e.g. protocol version 2.01 will contain 0x0201 in this field. When
+setting fields in the header, you must make sure only to set fields
+supported by the protocol version in use.
+
+
+DETAILS OF HEADER FIELDS
+========================
+
+For each field, some are information from the kernel to the bootloader
+("read"), some are expected to be filled out by the bootloader
+("write"), and some are expected to be read and modified by the
+bootloader ("modify").
+
+All general purpose boot loaders should write the fields marked
+(obligatory). Boot loaders who want to load the kernel at a
+nonstandard address should fill in the fields marked (reloc); other
+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
+be used to display the kernel version to the user. This value
+should be less than (0x200*setup_sects).
+
+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::
+
+ 0x1c00 < 15*0x200 (= 0x1e00) but
+ 0x1c00 >= 14*0x200 (= 0x1c00)
+
+ 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
+a version number. Otherwise, enter 0xFF here.
+
+For boot loader IDs above T = 0xD, write T = 0xE to this field and
+write the extended ID minus 0x10 to the ext_loader_type field.
+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::
+
+ 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)
+ 1 Loadlin
+ 2 bootsect-loader
+ (0x20, all other values reserved)
+ 3 Syslinux
+ 4 Etherboot/gPXE/iPXE
+ 5 ELILO
+ 7 GRUB
+ 8 U-Boot
+ 9 Xen
+ A Gujin
+ 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
+ == ==============================
+
+Please contact <hpa@...or.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.
+
+ 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
+sequence. Fill in this field if you want additional data (such as
+the kernel command line) moved in addition to the real-mode kernel
+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
+determine the proper load address.
+
+This field can be modified for two purposes:
+
+ 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
+(type_of_loader & 0x0f) + (ext_loader_ver << 4).
+
+The use of this field is boot loader specific. If not written, it
+is zero.
+
+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
+the actual type is (ext_loader_type + 0x10).
+
+This field is ignored if the type in type_of_loader is not 0xE.
+
+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
+the setup heap and 0xA0000; it does not have to be located in the
+same 64K segment as the real-mode code itself.
+
+Fill in this field even if your boot loader does not support a
+command line, in which case you can point this to an empty string
+(or better yet, to the string "auto".) If this field is left at
+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
+field is not present, and the maximum address is 0x37FFFFFF. (This
+address is defined as the address of the highest safe byte, so if
+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
+incompatible with the value in this field will be realigned during
+kernel initialization.
+
+Starting with protocol version 2.10, this reflects the kernel
+alignment preferred for optimal performance; it is possible for the
+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 = 1 << min_alignment
+
+There may be a considerable performance cost with an excessively
+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
+accessing process control registers needs to be done differently.
+
+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.
+
+The payload may be compressed. The format of both the compressed and
+uncompressed data should be determined using the standard magic
+numbers. The currently supported compression formats are gzip
+(magic numbers 1F 8B or 1F 9E), bzip2 (magic number 42 5A), LZMA
+(magic number 5D 00), XZ (magic number FD 37), and LZ4 (magic number
+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::
+
+ 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
+to identify the contents of data; the len is the length of data
+field; the data holds the real payload.
+
+This list may be modified at a number of points during the bootup
+process. Therefore, when modifying this list one should always make
+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
+address if possible.
+
+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
+is capable of examining its memory map. This is not the same thing
+as the total amount of memory the kernel needs to boot, but it can
+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::
+
+ 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
+handover protocol to boot the kernel should jump to this offset.
+
+See EFI HANDOVER PROTOCOL below for more details.
+
+
+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
+initial remainder of 0xffffffff. The checksum is appended to the
+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 has become an important way for the boot
+loader to communicate with the kernel. Some of its options are also
+relevant to the boot loader itself, see "special command line options"
+below.
+
+The kernel command line is a null-terminated string. The maximum
+length can be retrieved from the field cmdline_size. Before protocol
+version 2.06, the maximum was 255 characters. A string that is too
+long will be automatically truncated by the kernel.
+
+If the boot protocol version is 2.02 or later, the address of the
+kernel command line is given by the header field cmd_line_ptr (see
+above.) This address can be anywhere between the end of the setup
+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 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.
+
+
+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
+in the real-mode accessible memory in bottom megabyte.
+
+It should be noted that modern machines often have a sizable Extended
+BIOS Data Area (EBDA). As a result, it is advisable to use as little
+of the low megabyte as possible.
+
+Unfortunately, under the following circumstances the 0x90000 memory
+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.
+
+When loading at 0x90000, avoid using memory above 0x9a000.
+
+For boot protocol 2.02 or higher, the command line does not have to be
+located in the same 64K segment as the real-mode setup code; it is
+thus permitted to give the stack/heap the full 64K segment and locate
+the command line above it.
+
+The kernel command line should not be located below the real-mode
+code, nor should it be located in high memory.
+
+
+SAMPLE BOOT CONFIGURATION
+=========================
+
+As a sample configuration, assume the following layout of the real
+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::
+
+ unsigned long base_ptr; /* base address for real-mode segment */
+
+ if ( setup_sects == 0 ) {
+ setup_sects = 4;
+ }
+
+ if ( protocol >= 0x0200 ) {
+ type_of_loader = <type code>;
+ if ( loading_initrd ) {
+ ramdisk_image = <initrd_address>;
+ ramdisk_size = <initrd_size>;
+ }
+
+ if ( protocol >= 0x0202 && loadflags & 0x01 )
+ heap_end = 0xe000;
+ else
+ heap_end = 0x9800;
+
+ if ( protocol >= 0x0201 ) {
+ heap_end_ptr = heap_end - 0x200;
+ loadflags |= 0x80; /* CAN_USE_HEAP */
+ }
+
+ if ( protocol >= 0x0202 ) {
+ cmd_line_ptr = base_ptr + heap_end;
+ strcpy(cmd_line_ptr, cmdline);
+ } else {
+ cmd_line_magic = 0xA33F;
+ cmd_line_offset = heap_end;
+ setup_move_size = heap_end + strlen(cmdline)+1;
+ strcpy(base_ptr+cmd_line_offset, cmdline);
+ }
+ } else {
+ /* Very old kernel */
+
+ heap_end = 0x9800;
+
+ cmd_line_magic = 0xA33F;
+ cmd_line_offset = heap_end;
+
+ /* A very old kernel MUST have its real-mode code
+ loaded at 0x90000 */
+
+ if ( base_ptr != 0x90000 ) {
+ /* Copy the real-mode kernel */
+ memcpy(0x90000, base_ptr, (setup_sects+1)*512);
+ base_ptr = 0x90000; /* Relocated */
+ }
+
+ strcpy(0x90000+cmd_line_offset, cmdline);
+
+ /* It is recommended to clear memory up to the 32K mark */
+ memset(0x90000 + (setup_sects+1)*512, 0,
+ (64-(setup_sects+1))*512);
+ }
+
+
+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.)
+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::
+
+ is_bzImage = (protocol >= 0x0200) && (loadflags & 0x01);
+ load_address = is_bzImage ? 0x100000 : 0x10000;
+
+Note that Image/zImage kernels can be up to 512K in size, and thus use
+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
+============================
+
+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.
+They should normally not be deleted from the kernel command line even
+though not all of them are actually meaningful to the kernel. Boot
+loader authors who need additional command line options for the boot
+loader itself should get them registered in
+Documentation/admin-guide/kernel-parameters.rst to make sure they will not
+conflict with actual kernel options now or in the future.
+
+ vga=<mode>
+ <mode> here is either an integer (in C notation, either
+ decimal, octal, or hexadecimal) or one of the strings
+ "normal" (meaning 0xFFFF), "ext" (meaning 0xFFFE) or "ask"
+ (meaning 0xFFFD). This value should be entered into the
+ vid_mode field, as it is used by the kernel before the command
+ line is parsed.
+
+ mem=<size>
+ <size> is an integer in C notation optionally followed by
+ (case insensitive) K, M, G, T, P or E (meaning << 10, << 20,
+ << 30, << 40, << 50 or << 60). This specifies the end of
+ memory to the kernel. This affects the possible placement of
+ an initrd, since an initrd should be placed near end of
+ memory. Note that this is an option to *both* the kernel and
+ the bootloader!
+
+ initrd=<file>
+ An initrd should be loaded. The meaning of <file> is
+ obviously bootloader-dependent, and some boot loaders
+ (e.g. LILO) do not have such a command.
+
+In addition, some boot loaders add the following options to the
+user-specified command line:
+
+ BOOT_IMAGE=<file>
+ The boot image which was loaded. Again, the meaning of <file>
+ is obviously bootloader-dependent.
+
+ auto
+ The kernel was booted without explicit user intervention.
+
+If these options are added by the boot loader, it is highly
+recommended that they are located *first*, before the user-specified
+or configuration-specified command line. Otherwise, "init=/bin/sh"
+gets confused by the "auto" option.
+
+
+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
+kernel. This means that if you loaded your real-mode kernel code at
+0x90000, the kernel entry point is 9020:0000.
+
+At entry, ds = es = ss should point to the start of the real-mode
+kernel code (0x9000 if the code is loaded at 0x90000), sp should be
+set up properly, normally pointing to the top of the heap, and
+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::
+
+ /* Note: in the case of the "old" kernel protocol, base_ptr must
+ be == 0x90000 at this point; see the previous sample code */
+
+ seg = base_ptr >> 4;
+
+ cli(); /* Enter with interrupts disabled! */
+
+ /* Set up the real-mode kernel stack */
+ _SS = seg;
+ _SP = heap_end;
+
+ _DS = _ES = _FS = _GS = seg;
+ jmp_far(seg+0x20, 0); /* Run the kernel */
+
+If your boot sector accesses a floppy drive, it is recommended to
+switch off the floppy motor before running the kernel, since the
+kernel boot leaves interrupts off and thus the motor will not be
+switched off, especially if the loaded kernel has the floppy driver as
+a demand-loaded module!
+
+
+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
+standard memory location requirements. Such a boot loader may use the
+following hooks that, if set, are invoked by the kernel at the
+appropriate time. The use of these hooks should probably be
+considered an absolutely last resort!
+
+IMPORTANT: All the hooks are required to preserve %esp, %ebp, %esi and
+%edi across invocation.
+
+ realmode_swtch:
+ A 16-bit real mode far subroutine invoked immediately before
+ entering protected mode. The default routine disables NMI, so
+ your routine should probably do so, too.
+
+ code32_start:
+ A 32-bit flat-mode routine *jumped* to immediately after the
+ transition to protected mode, but before the kernel is
+ uncompressed. No segments, except CS, are guaranteed to be
+ set up (current kernels do, but older ones do not); you should
+ set them up to BOOT_DS (0x18) yourself.
+
+ After completing your hook, you should jump to the address
+ that was in this field before your boot loader overwrote it
+ (relocated, if appropriate.)
+
+
+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
+based on legacy BIOS can not be used, so a 32-bit boot protocol needs
+to be defined.
+
+In 32-bit boot protocol, the first step in loading a Linux kernel
+should be to setup the boot parameters (struct boot_params,
+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::
+
+ 0x0202 + byte value at offset 0x0201
+
+In addition to read/modify/write the setup header of the struct
+boot_params as that of 16-bit boot protocol, the boot loader should
+also fill the additional fields of the struct boot_params as that
+described in zero-page.txt.
+
+After setting up the struct boot_params, the boot loader can load the
+32/64-bit kernel in the same way as that of 16-bit boot protocol.
+
+In 32-bit boot protocol, the kernel is started by jumping to the
+32-bit kernel entry point, which is the start address of loaded
+32/64-bit kernel.
+
+At entry, the CPU must be in 32-bit protected mode with paging
+disabled; a GDT must be loaded with the descriptors for selectors
+__BOOT_CS(0x10) and __BOOT_DS(0x18); both descriptors must be 4G flat
+segment; __BOOT_CS must have execute/read permission, and __BOOT_DS
+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
+====================
+
+For machine with 64bit cpus and 64bit kernel, we could use 64bit bootloader
+and we need a 64-bit boot protocol.
+
+In 64-bit boot protocol, the first step in loading a Linux kernel
+should be to setup the boot parameters (struct boot_params,
+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::
+
+ 0x0202 + byte value at offset 0x0201
+
+In addition to read/modify/write the setup header of the struct
+boot_params as that of 16-bit boot protocol, the boot loader should
+also fill the additional fields of the struct boot_params as described
+in zero-page.txt.
+
+After setting up the struct boot_params, the boot loader can load
+64-bit kernel in the same way as that of 16-bit boot protocol, but
+kernel could be loaded above 4G.
+
+In 64-bit boot protocol, the kernel is started by jumping to the
+64-bit kernel entry point, which is the start address of loaded
+64-bit kernel plus 0x200.
+
+At entry, the CPU must be in 64-bit mode with paging enabled.
+The range with setup_header.init_size from start address of loaded
+kernel and zero page and command line buffer get ident mapping;
+a GDT must be loaded with the descriptors for selectors
+__BOOT_CS(0x10) and __BOOT_DS(0x18); both descriptors must be 4G flat
+segment; __BOOT_CS must have execute/read permission, and __BOOT_DS
+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
+=====================
+
+This protocol allows boot loaders to defer initialisation to the EFI
+boot stub. The boot loader is required to load the kernel/initrd(s)
+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::
+
+ efi_main(void *handle, efi_system_table_t *table, struct boot_params *bp)
+
+'handle' is the EFI image handle passed to the boot loader by the EFI
+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::
+
+ - 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/boot.txt b/Documentation/x86/boot.txt
deleted file mode 100644
index f4c2a97bfdbd..000000000000
--- a/Documentation/x86/boot.txt
+++ /dev/null
@@ -1,1130 +0,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
-well as the desire in the early days to have the kernel itself be a
-bootable image, the complicated PC memory model and due to changed
-expectations in the PC industry caused by the effective demise of
-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
- may not even support a command line.
-
-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.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
- initrd address available to the bootloader.
-
-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.
- Introduce relocatable_kernel and kernel_alignment fields.
-
-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.
- 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
- 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
- pointer to single linked list of struct setup_data.
-
-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 entry point.
-
-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.
-
-**** 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,
-setup, and stack/heap) was made relocatable to any address between
-0x10000 and end of low memory. Unfortunately, in protocols 2.00 and
-2.01 the 0x90000+ memory range is still used internally by the kernel;
-the 2.02 protocol resolves that problem.
-
-It is desirable to keep the "memory ceiling" -- the highest point in
-low memory touched by the boot loader -- as low as possible, since
-some newer BIOSes have begun to allocate some rather large amounts of
-memory, called the Extended BIOS Data Area, near the top of low
-memory. The boot loader should use the "INT 12h" BIOS call to verify
-how much low memory is available.
-
-Unfortunately, if INT 12h reports that the amount of memory is too
-low, there is usually nothing the boot loader can do but to report an
-error to the user. The boot loader should therefore be designed to
-take up as little space in low memory as it reasonably can. For
-zImage or old bzImage kernels, which need data written into the
-0x90000 segment, the boot loader should make sure not to use memory
-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
-
-In the following text, and anywhere in the kernel boot sequence, "a
-sector" refers to 512 bytes. It is independent of the actual sector
-size of the underlying medium.
-
-The first step in loading a Linux kernel should be to load the
-real-mode code (boot sector and setup code) and then examine the
-following header at offset 0x01f1. The real-mode code can total up to
-32K, although the boot loader may choose to load only the first two
-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.
-
-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:
-
- Image type = zImage
- initrd not supported
- Real-mode kernel must be located at 0x90000.
-
-Otherwise, the "version" field contains the protocol version,
-e.g. protocol version 2.01 will contain 0x0201 in this field. When
-setting fields in the header, you must make sure only to set fields
-supported by the protocol version in use.
-
-
-**** DETAILS OF HEADER FIELDS
-
-For each field, some are information from the kernel to the bootloader
-("read"), some are expected to be filled out by the bootloader
-("write"), and some are expected to be read and modified by the
-bootloader ("modify").
-
-All general purpose boot loaders should write the fields marked
-(obligatory). Boot loaders who want to load the kernel at a
-nonstandard address should fill in the fields marked (reloc); other
-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
- be used to display the kernel version to the user. This value
- should be less than (0x200*setup_sects).
-
- 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:
-
- 0x1c00 < 15*0x200 (= 0x1e00) but
- 0x1c00 >= 14*0x200 (= 0x1c00)
-
- 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
- a version number. Otherwise, enter 0xFF here.
-
- For boot loader IDs above T = 0xD, write T = 0xE to this field and
- write the extended ID minus 0x10 to the ext_loader_type field.
- 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:
-
- 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)
- 1 Loadlin
- 2 bootsect-loader (0x20, all other values reserved)
- 3 Syslinux
- 4 Etherboot/gPXE/iPXE
- 5 ELILO
- 7 GRUB
- 8 U-Boot
- 9 Xen
- A Gujin
- 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
-
- Please contact <hpa@...or.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.
-
- 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
- sequence. Fill in this field if you want additional data (such as
- the kernel command line) moved in addition to the real-mode kernel
- 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
- determine the proper load address.
-
- This field can be modified for two purposes:
-
- 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
- (type_of_loader & 0x0f) + (ext_loader_ver << 4).
-
- The use of this field is boot loader specific. If not written, it
- is zero.
-
- 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
- the actual type is (ext_loader_type + 0x10).
-
- This field is ignored if the type in type_of_loader is not 0xE.
-
- 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
- the setup heap and 0xA0000; it does not have to be located in the
- same 64K segment as the real-mode code itself.
-
- Fill in this field even if your boot loader does not support a
- command line, in which case you can point this to an empty string
- (or better yet, to the string "auto".) If this field is left at
- 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
- field is not present, and the maximum address is 0x37FFFFFF. (This
- address is defined as the address of the highest safe byte, so if
- 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
- incompatible with the value in this field will be realigned during
- kernel initialization.
-
- Starting with protocol version 2.10, this reflects the kernel
- alignment preferred for optimal performance; it is possible for the
- 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 = 1 << min_alignment
-
- There may be a considerable performance cost with an excessively
- 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
- accessing process control registers needs to be done differently.
-
- 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.
-
- The payload may be compressed. The format of both the compressed and
- uncompressed data should be determined using the standard magic
- numbers. The currently supported compression formats are gzip
- (magic numbers 1F 8B or 1F 9E), bzip2 (magic number 42 5A), LZMA
- (magic number 5D 00), XZ (magic number FD 37), and LZ4 (magic number
- 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:
-
- 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
- to identify the contents of data; the len is the length of data
- field; the data holds the real payload.
-
- This list may be modified at a number of points during the bootup
- process. Therefore, when modifying this list one should always make
- 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
- address if possible.
-
- 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
- is capable of examining its memory map. This is not the same thing
- as the total amount of memory the kernel needs to boot, but it can
- 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:
-
- 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
- handover protocol to boot the kernel should jump to this offset.
-
- See EFI HANDOVER PROTOCOL below for more details.
-
-
-**** 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
-initial remainder of 0xffffffff. The checksum is appended to the
-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 has become an important way for the boot
-loader to communicate with the kernel. Some of its options are also
-relevant to the boot loader itself, see "special command line options"
-below.
-
-The kernel command line is a null-terminated string. The maximum
-length can be retrieved from the field cmdline_size. Before protocol
-version 2.06, the maximum was 255 characters. A string that is too
-long will be automatically truncated by the kernel.
-
-If the boot protocol version is 2.02 or later, the address of the
-kernel command line is given by the header field cmd_line_ptr (see
-above.) This address can be anywhere between the end of the setup
-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 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.
-
-
-**** 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
-in the real-mode accessible memory in bottom megabyte.
-
-It should be noted that modern machines often have a sizable Extended
-BIOS Data Area (EBDA). As a result, it is advisable to use as little
-of the low megabyte as possible.
-
-Unfortunately, under the following circumstances the 0x90000 memory
-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.
-
-When loading at 0x90000, avoid using memory above 0x9a000.
-
-For boot protocol 2.02 or higher, the command line does not have to be
-located in the same 64K segment as the real-mode setup code; it is
-thus permitted to give the stack/heap the full 64K segment and locate
-the command line above it.
-
-The kernel command line should not be located below the real-mode
-code, nor should it be located in high memory.
-
-
-**** SAMPLE BOOT CONFIGURATION
-
-As a sample configuration, assume the following layout of the real
-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:
-
- unsigned long base_ptr; /* base address for real-mode segment */
-
- if ( setup_sects == 0 ) {
- setup_sects = 4;
- }
-
- if ( protocol >= 0x0200 ) {
- type_of_loader = <type code>;
- if ( loading_initrd ) {
- ramdisk_image = <initrd_address>;
- ramdisk_size = <initrd_size>;
- }
-
- if ( protocol >= 0x0202 && loadflags & 0x01 )
- heap_end = 0xe000;
- else
- heap_end = 0x9800;
-
- if ( protocol >= 0x0201 ) {
- heap_end_ptr = heap_end - 0x200;
- loadflags |= 0x80; /* CAN_USE_HEAP */
- }
-
- if ( protocol >= 0x0202 ) {
- cmd_line_ptr = base_ptr + heap_end;
- strcpy(cmd_line_ptr, cmdline);
- } else {
- cmd_line_magic = 0xA33F;
- cmd_line_offset = heap_end;
- setup_move_size = heap_end + strlen(cmdline)+1;
- strcpy(base_ptr+cmd_line_offset, cmdline);
- }
- } else {
- /* Very old kernel */
-
- heap_end = 0x9800;
-
- cmd_line_magic = 0xA33F;
- cmd_line_offset = heap_end;
-
- /* A very old kernel MUST have its real-mode code
- loaded at 0x90000 */
-
- if ( base_ptr != 0x90000 ) {
- /* Copy the real-mode kernel */
- memcpy(0x90000, base_ptr, (setup_sects+1)*512);
- base_ptr = 0x90000; /* Relocated */
- }
-
- strcpy(0x90000+cmd_line_offset, cmdline);
-
- /* It is recommended to clear memory up to the 32K mark */
- memset(0x90000 + (setup_sects+1)*512, 0,
- (64-(setup_sects+1))*512);
- }
-
-
-**** 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.)
-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:
-
- is_bzImage = (protocol >= 0x0200) && (loadflags & 0x01);
- load_address = is_bzImage ? 0x100000 : 0x10000;
-
-Note that Image/zImage kernels can be up to 512K in size, and thus use
-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
-
-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.
-They should normally not be deleted from the kernel command line even
-though not all of them are actually meaningful to the kernel. Boot
-loader authors who need additional command line options for the boot
-loader itself should get them registered in
-Documentation/admin-guide/kernel-parameters.rst to make sure they will not
-conflict with actual kernel options now or in the future.
-
- vga=<mode>
- <mode> here is either an integer (in C notation, either
- decimal, octal, or hexadecimal) or one of the strings
- "normal" (meaning 0xFFFF), "ext" (meaning 0xFFFE) or "ask"
- (meaning 0xFFFD). This value should be entered into the
- vid_mode field, as it is used by the kernel before the command
- line is parsed.
-
- mem=<size>
- <size> is an integer in C notation optionally followed by
- (case insensitive) K, M, G, T, P or E (meaning << 10, << 20,
- << 30, << 40, << 50 or << 60). This specifies the end of
- memory to the kernel. This affects the possible placement of
- an initrd, since an initrd should be placed near end of
- memory. Note that this is an option to *both* the kernel and
- the bootloader!
-
- initrd=<file>
- An initrd should be loaded. The meaning of <file> is
- obviously bootloader-dependent, and some boot loaders
- (e.g. LILO) do not have such a command.
-
-In addition, some boot loaders add the following options to the
-user-specified command line:
-
- BOOT_IMAGE=<file>
- The boot image which was loaded. Again, the meaning of <file>
- is obviously bootloader-dependent.
-
- auto
- The kernel was booted without explicit user intervention.
-
-If these options are added by the boot loader, it is highly
-recommended that they are located *first*, before the user-specified
-or configuration-specified command line. Otherwise, "init=/bin/sh"
-gets confused by the "auto" option.
-
-
-**** 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
-kernel. This means that if you loaded your real-mode kernel code at
-0x90000, the kernel entry point is 9020:0000.
-
-At entry, ds = es = ss should point to the start of the real-mode
-kernel code (0x9000 if the code is loaded at 0x90000), sp should be
-set up properly, normally pointing to the top of the heap, and
-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:
-
- /* Note: in the case of the "old" kernel protocol, base_ptr must
- be == 0x90000 at this point; see the previous sample code */
-
- seg = base_ptr >> 4;
-
- cli(); /* Enter with interrupts disabled! */
-
- /* Set up the real-mode kernel stack */
- _SS = seg;
- _SP = heap_end;
-
- _DS = _ES = _FS = _GS = seg;
- jmp_far(seg+0x20, 0); /* Run the kernel */
-
-If your boot sector accesses a floppy drive, it is recommended to
-switch off the floppy motor before running the kernel, since the
-kernel boot leaves interrupts off and thus the motor will not be
-switched off, especially if the loaded kernel has the floppy driver as
-a demand-loaded module!
-
-
-**** 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
-standard memory location requirements. Such a boot loader may use the
-following hooks that, if set, are invoked by the kernel at the
-appropriate time. The use of these hooks should probably be
-considered an absolutely last resort!
-
-IMPORTANT: All the hooks are required to preserve %esp, %ebp, %esi and
-%edi across invocation.
-
- realmode_swtch:
- A 16-bit real mode far subroutine invoked immediately before
- entering protected mode. The default routine disables NMI, so
- your routine should probably do so, too.
-
- code32_start:
- A 32-bit flat-mode routine *jumped* to immediately after the
- transition to protected mode, but before the kernel is
- uncompressed. No segments, except CS, are guaranteed to be
- set up (current kernels do, but older ones do not); you should
- set them up to BOOT_DS (0x18) yourself.
-
- After completing your hook, you should jump to the address
- that was in this field before your boot loader overwrote it
- (relocated, if appropriate.)
-
-
-**** 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
-based on legacy BIOS can not be used, so a 32-bit boot protocol needs
-to be defined.
-
-In 32-bit boot protocol, the first step in loading a Linux kernel
-should be to setup the boot parameters (struct boot_params,
-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:
-
- 0x0202 + byte value at offset 0x0201
-
-In addition to read/modify/write the setup header of the struct
-boot_params as that of 16-bit boot protocol, the boot loader should
-also fill the additional fields of the struct boot_params as that
-described in zero-page.txt.
-
-After setting up the struct boot_params, the boot loader can load the
-32/64-bit kernel in the same way as that of 16-bit boot protocol.
-
-In 32-bit boot protocol, the kernel is started by jumping to the
-32-bit kernel entry point, which is the start address of loaded
-32/64-bit kernel.
-
-At entry, the CPU must be in 32-bit protected mode with paging
-disabled; a GDT must be loaded with the descriptors for selectors
-__BOOT_CS(0x10) and __BOOT_DS(0x18); both descriptors must be 4G flat
-segment; __BOOT_CS must have execute/read permission, and __BOOT_DS
-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
-
-For machine with 64bit cpus and 64bit kernel, we could use 64bit bootloader
-and we need a 64-bit boot protocol.
-
-In 64-bit boot protocol, the first step in loading a Linux kernel
-should be to setup the boot parameters (struct boot_params,
-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:
-
- 0x0202 + byte value at offset 0x0201
-
-In addition to read/modify/write the setup header of the struct
-boot_params as that of 16-bit boot protocol, the boot loader should
-also fill the additional fields of the struct boot_params as described
-in zero-page.txt.
-
-After setting up the struct boot_params, the boot loader can load
-64-bit kernel in the same way as that of 16-bit boot protocol, but
-kernel could be loaded above 4G.
-
-In 64-bit boot protocol, the kernel is started by jumping to the
-64-bit kernel entry point, which is the start address of loaded
-64-bit kernel plus 0x200.
-
-At entry, the CPU must be in 64-bit mode with paging enabled.
-The range with setup_header.init_size from start address of loaded
-kernel and zero page and command line buffer get ident mapping;
-a GDT must be loaded with the descriptors for selectors
-__BOOT_CS(0x10) and __BOOT_DS(0x18); both descriptors must be 4G flat
-segment; __BOOT_CS must have execute/read permission, and __BOOT_DS
-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
-
-This protocol allows boot loaders to defer initialisation to the EFI
-boot stub. The boot loader is required to load the kernel/initrd(s)
-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,
-
- efi_main(void *handle, efi_system_table_t *table, struct boot_params *bp)
-
-'handle' is the EFI image handle passed to the boot loader by the EFI
-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,
-
- o hdr.code32_start
- o hdr.cmd_line_ptr
- o hdr.ramdisk_image (if applicable)
- o hdr.ramdisk_size (if applicable)
-
-All other fields should be zero.
diff --git a/Documentation/x86/index.rst b/Documentation/x86/index.rst
index 7612d3142b2a..8f08caf4fbbb 100644
--- a/Documentation/x86/index.rst
+++ b/Documentation/x86/index.rst
@@ -7,3 +7,5 @@ Linux x86 Support
.. toctree::
:maxdepth: 2
:numbered:
+
+ boot
--
2.20.1
Powered by blists - more mailing lists