struct setup_header
Defined at line 65 of file ../../zircon/kernel/arch/x86/phys/linuxboot.h
This is the primary protocol data structure that the boot loader reads and
writes. Its placement in boot_params (below) puts the `jump` member at
exactly 512 bytes from the start of boot_params, which is at the start of
the whole bzImage file. The boot loader first loads the first 512-byte
sector, so it can see just boot_params up through `hdr.boot_flag`.
The boot loader then checks `header`, `version`, and `boot_flag` to validate
the precise protocol it should be using. In the versions we support, then
it consults `loadflags` and `syssize` for more details and those tell it
which fixed load address to use for the main kernel image, and how big it is
(in 16-byte units). As `loadflags` is past the first 512 bytes, the boot
loader always reads at least one more sector. Whether it reads more than
that depends on which booting path it's going to use. In either path, it
loads the main kernel at the fixed load address indicated by the version and
loadflags; for bzImage format it's always 1MiB.
* Direct 32-bit entry ignores the rest of the setup area. It allocates a
new boot_params struct somewhere and first zeros the whole thing. Then
it copies just the setup_header region from the original image into that
boot_params::hdr, and modifies various fields in setup_header and other
parts of boot_params to pass information to the kernel. Finally it
simply jumps to the fixed load address indicated by the setup_header
flags, in 32-bit protected mode. The %esi register holds the physical
address of the setup area (i.e. `boot_params*`). The %esp register
points to some usable stack space.
* 16-bit entry uses the rest of the setup area that 32-bit entry ignores.
It looks at setup_header::setup_sects for a count of 512-byte sectors to
read after the first. That whole "setup area" from the beginning of the
image up through the total size `(hdr.setup_sects + 1) * 512` is loaded
at some arbitrary 4KiB-aligned address, hence the moniker "zero page".
Then it simply jumps to 512 bytes into the setup area, in 16-bit real
mode. The %cs segment points to this directly, so the entry point is at
%cs:0. The %ds and %es segments point to the start of the setup area, so
%ds:0 (i.e. `%ds
<
<
4`) is the boot_params object. The %ss:%sp points to
some usable stack space. The boot loader fills in a few essential fields
but not as much as the 32-bit entry protocol would. The 16-bit entry
code is responsible for discovering more on its own and is expected to
rely on the legacy PC 16-bit BIOS ABI. Traditionally, it allocates a new
boot_params struct of its own and copies setup_header and other data into
it to pass along to the 32-bit entry point so it looks like the direct
32-bit entry from a boot loader would.
Public Members
uint8_t setup_sectsuint16_t root_flagsuint32_t syssizeuint16_t ram_sizeuint16_t vid_modeuint16_t root_devuint16_t boot_flaguint16_t jumpuint32_t headeruint16_t versionuint32_t realmode_swtchuint16_t start_sys_seguint16_t kernel_versionuint8_t type_of_loaderuint8_t loadflagsuint16_t setup_move_sizeuint32_t code32_startuint32_t ramdisk_imageuint32_t ramdisk_sizeuint32_t bootsect_kludgeuint16_t heap_end_ptruint8_t ext_loader_veruint8_t ext_loader_typeuint32_t cmd_line_ptruint32_t initrd_addr_maxuint32_t kernel_alignmentuint8_t relocatable_kerneluint8_t min_alignmentuint16_t xloadflagsuint32_t cmdline_sizeuint32_t hardware_subarchuint64_t hardware_subarch_datauint32_t payload_offsetuint32_t payload_lengthuint64_t setup_datauint64_t pref_addressuint32_t init_sizeuint32_t handover_offsetuint32_t kernel_info_offsetstatic const uint16_t kBootFlagEnumerations
enum LoadFlags| Name | Value |
|---|---|
| kLoadedHigh | 1 << 0 |
Defined at line 66 of file ../../zircon/kernel/arch/x86/phys/linuxboot.h
enum XLoadFlags| Name | Value |
|---|---|
| kKernel64 | 1 << 0 |
| kCanBeLoadedAbove4g | 1 << 1 |
Defined at line 70 of file ../../zircon/kernel/arch/x86/phys/linuxboot.h