Lines Matching refs:the
4 On the x86 platform, the Linux kernel uses a rather complicated boot
6 well as the desire in the early days to have the kernel itself be a
7 bootable image, the complicated PC memory model and due to changed
8 expectations in the PC industry caused by the effective demise of
11 Currently, the following versions of the Linux/x86 boot protocol exist.
17 well as a formalized way to communicate between the
18 boot loader and the kernel. setup.S made relocatable,
19 although the traditional setup area still assumed
25 Lower the conventional memory ceiling. No overwrite
26 of the traditional setup area, thus making booting
27 safe for systems which use the EBDA from SMM or 32-bit
31 Protocol 2.03: (Kernel 2.4.18-pre1) Explicitly makes the highest possible
32 initrd address available to the bootloader.
34 Protocol 2.04: (Kernel 2.6.14) Extend the syssize field to four bytes.
39 Protocol 2.06: (Kernel 2.6.22) Added a field that contains the size of
40 the boot command line.
48 fields to aid in locating the payload.
54 beyond the kernel_alignment added, new init_size and
60 Protocol 2.12: (Kernel 3.8) Added the xloadflags field and extension fields
66 The traditional memory map for the kernel loader, used for Image or
74 | Stack/heap | For use by the kernel real-mode code.
80 | Protected-mode kernel | The bulk of the kernel image.
92 When using bzImage, the protected-mode kernel was relocated to
93 0x100000 ("high memory"), and the kernel real-mode block (boot sector,
96 2.01 the 0x90000+ memory range is still used internally by the kernel;
97 the 2.02 protocol resolves that problem.
99 It is desirable to keep the "memory ceiling" -- the highest point in
100 low memory touched by the boot loader -- as low as possible, since
102 memory, called the Extended BIOS Data Area, near the top of low
103 memory. The boot loader should use the "INT 12h" BIOS call to verify
106 Unfortunately, if INT 12h reports that the amount of memory is too
107 low, there is usually nothing the boot loader can do but to report an
108 error to the user. The boot loader should therefore be designed to
110 zImage or old bzImage kernels, which need data written into the
111 0x90000 segment, the boot loader should make sure not to use memory
112 above the 0x9A000 point; too many BIOSes will break above that point.
115 memory layout like the following is suggested:
124 | Command line | (Can also be below the X+10000 mark)
126 | Stack/heap | For use by the kernel real-mode code.
140 ... where the address X is as low as the design of the boot loader
146 In the following text, and anywhere in the kernel boot sequence, "a
147 sector" refers to 512 bytes. It is independent of the actual sector
148 size of the underlying medium.
150 The first step in loading a Linux kernel should be to load the
151 real-mode code (boot sector and setup code) and then examine the
153 32K, although the boot loader may choose to load only the first two
154 sectors (1K) and then examine the bootup sector size.
161 01F1/1 ALL(1 setup_sects The size of the setup in sectors
162 01F2/2 ALL root_flags If set, the root is mounted readonly
163 01F4/4 2.04+(2 syssize The size of the 32-bit code in 16-byte paras
184 0228/4 2.02+ cmd_line_ptr 32-bit pointer to the kernel command line
190 0238/4 2.06+ cmdline_size Maximum size of the kernel command line
201 (1) For backwards compatibility, if the setup_sects field contains 0, the
204 (2) For boot protocol prior to 2.04, the upper two bytes of the syssize
205 field are unusable, which means the size of a bzImage kernel
210 If the "HdrS" (0x53726448) magic number is not found at offset 0x202,
211 the boot protocol version is "old". Loading an old kernel, the
218 Otherwise, the "version" field contains the protocol version,
220 setting fields in the header, you must make sure only to set fields
221 supported by the protocol version in use.
226 For each field, some are information from the kernel to the bootloader
227 ("read"), some are expected to be filled out by the bootloader
228 ("write"), and some are expected to be read and modified by the
231 All general purpose boot loaders should write the fields marked
232 (obligatory). Boot loaders who want to load the kernel at a
233 nonstandard address should fill in the fields marked (reloc); other
243 The size of the setup code in 512-byte sectors. If this field is
244 0, the real value is 4. The real-mode code consists of the boot
245 sector (always one 512-byte sector) plus the setup code.
252 If this field is nonzero, the root defaults to readonly. The use of
253 this field is deprecated; use the "ro" or "rw" options on the
261 The size of the protected-mode code in units of 16-byte paragraphs.
263 wide, and therefore cannot be trusted for the size of a kernel if
264 the LOAD_HIGH flag is set.
277 Please see the section on SPECIAL COMMAND LINE OPTIONS.
285 deprecated, use the "root=" option on the command line instead.
292 Contains 0xAA55. This is the closest thing old Linux kernels have
301 relative to byte 0x202. This can be used to determine the size of
302 the header.
309 Contains the magic number "HdrS" (0x53726448).
316 Contains the boot protocol version, in (major << 8)+minor format,
341 be used to display the kernel version to the user. This value
344 For example, if this value is set to 0x1c00, the kernel version
345 number string can be found at offset 0x1e00 in the kernel file.
346 This is a valid value if and only if the "setup_sects" field
347 contains the value 15 or higher, as:
352 0x1c00 >> 9 = 14, so the minimum value for setup_secs is 15.
360 0xTV here, where T is an identifier for the boot loader and V is
364 write the extended ID minus 0x10 to the ext_loader_type field.
365 Similarly, the ext_loader_ver field can be used to provide more than
366 four bits for the bootloader version.
406 - If 0, the protected-mode code is loaded at 0x10000.
407 - If 1, the protected-mode code is loaded at 0x100000.
410 - Used internally by the compressed kernel to communicate
418 This requests to the kernel (decompressor and early
420 accessing the display hardware directly.
424 - If 0, reload the segment registers in the 32bit entry point.
425 - If 1, do not reload the segment registers in the 32bit entry point.
427 a base of 0 (or the equivalent for their environment).
430 Set this bit to 1 to indicate that the value entered in the
439 When using protocol 2.00 or 2.01, if the real mode kernel is not
440 loaded at 0x90000, it gets moved there later in the loading
442 the kernel command line) moved in addition to the real-mode kernel
445 The unit is bytes starting with the beginning of the boot sector.
447 This field is can be ignored when the protocol is 2.02 or higher, or
448 if the real-mode code is loaded at 0x90000.
455 The address to jump to in protected mode. This defaults to the load
456 address of the kernel, and can be used by the boot loader to
457 determine the proper load address.
465 this field to point to the load address.
472 The 32-bit linear address of the initial ramdisk or ramfs. Leave at
480 Size of the initial ramdisk or ramfs. Leave at zero if there is no
495 Set this field to the offset (from the beginning of the real-mode
496 code) of the end of the setup stack/heap, minus 0x0200.
503 This field is used as an extension of the version number in the
518 This field is used as an extension of the type number in
519 type_of_loader field. If the type in type_of_loader is 0xE, then
520 the actual type is (ext_loader_type + 0x10).
522 This field is ignored if the type in type_of_loader is not 0xE.
532 Set this field to the linear address of the kernel command line.
533 The kernel command line can be located anywhere between the end of
534 the setup heap and 0xA0000; it does not have to be located in the
535 same 64K segment as the real-mode code itself.
539 (or better yet, to the string "auto".) If this field is left at
540 zero, the kernel will assume that your boot loader does not support
541 the 2.02+ protocol.
548 The maximum address that may be occupied by the initial
550 field is not present, and the maximum address is 0x37FFFFFF. (This
551 address is defined as the address of the highest safe byte, so if
560 Alignment unit required by the kernel (if relocatable_kernel is
562 incompatible with the value in this field will be realigned during
565 Starting with protocol version 2.10, this reflects the kernel
566 alignment preferred for optimal performance; it is possible for the
567 loader to modify this field to permit a lesser alignment. See the
575 If this field is nonzero, the protected-mode part of the kernel can
576 be loaded at any address that satisfies the kernel_alignment field.
577 After loading, the boot loader must set the code32_start field to
578 point to the loaded code, or to a boot loader hook.
585 This field, if nonzero, indicates as a power of two the minimum
586 alignment required, as opposed to preferred, by the kernel to boot.
587 If a boot loader makes use of this field, it should update the
588 kernel_alignment field with the alignment unit desired; typically:
604 - If 1, this kernel has the legacy 64-bit entry point at 0x200.
610 - If 1, the kernel supports the 32-bit EFI handoff entry point
614 - If 1, the kernel supports the 64-bit EFI handoff entry point
618 - If 1, the kernel supports kexec EFI boot with EFI runtime support.
625 The maximum size of the command line without the terminating
626 zero. This means that the command line can contain at most
627 cmdline_size characters. With protocol version 2.05 and earlier, the
635 In a paravirtualized environment the hardware low level architectural
639 This field allows the bootloader to inform the kernel we are in one
654 This field is currently unused for the default x86/PC environment,
662 If non-zero then this field contains the offset from the beginning
663 of the protected-mode code to the payload.
665 The payload may be compressed. The format of both the compressed and
666 uncompressed data should be determined using the standard magic
678 The length of the payload.
697 Where, the next is a 64-bit physical pointer to the next node of
698 linked list, the next field of the last node is 0; the type is used
699 to identify the contents of data; the len is the length of data
700 field; the data holds the real payload.
702 This list may be modified at a number of points during the bootup
704 sure to consider the case where the linked list already contains
712 This field, if nonzero, represents a preferred load address for the
723 This field indicates the amount of linear contiguous memory starting
724 at the kernel runtime start address that the kernel needs before it
725 is capable of examining its memory map. This is not the same thing
726 as the total amount of memory the kernel needs to boot, but it can
728 address for the kernel.
730 The kernel runtime start address is determined by the following algorithm:
741 This field is the offset from the beginning of the kernel image to
742 the EFI handover protocol entry point. Boot loaders using the EFI
743 handover protocol to boot the kernel should jump to this offset.
750 From boot protocol version 2.08 onwards the CRC-32 is calculated over
751 the entire file using the characteristic polynomial 0x04C11DB7 and an
752 initial remainder of 0xffffffff. The checksum is appended to the
753 file; therefore the CRC of the file up to the limit specified in the
754 syssize field of the header is always 0.
759 The kernel command line has become an important way for the boot
760 loader to communicate with the kernel. Some of its options are also
761 relevant to the boot loader itself, see "special command line options"
765 length can be retrieved from the field cmdline_size. Before protocol
766 version 2.06, the maximum was 255 characters. A string that is too
767 long will be automatically truncated by the kernel.
769 If the boot protocol version is 2.02 or later, the address of the
770 kernel command line is given by the header field cmd_line_ptr (see
771 above.) This address can be anywhere between the end of the setup
774 If the protocol version is *not* 2.02 or higher, the kernel
775 command line is entered using the following protocol:
777 At offset 0x0020 (word), "cmd_line_magic", enter the magic
780 At offset 0x0022 (word), "cmd_line_offset", enter the offset
781 of the kernel command line (relative to the start of the
784 The kernel command line *must* be within the memory region
792 memory allocated for the kernel command line. This needs to be done
793 in the real-mode accessible memory in bottom megabyte.
797 of the low megabyte as possible.
799 Unfortunately, under the following circumstances the 0x90000 memory
805 -> For the 2.00 and 2.01 boot protocols, the real-mode code
807 relocated to 0x90000. For the "old" protocol, the
812 For boot protocol 2.02 or higher, the command line does not have to be
813 located in the same 64K segment as the real-mode setup code; it is
814 thus permitted to give the stack/heap the full 64K segment and locate
815 the command line above it.
817 The kernel command line should not be located below the real-mode
823 As a sample configuration, assume the following layout of the real
826 When loading below 0x90000, use the entire segment:
832 When loading at 0x90000 OR the protocol version is 2.01 or earlier:
838 Such a boot loader should enter the following fields in the header:
884 /* Copy the real-mode kernel */
891 /* It is recommended to clear memory up to the 32K mark */
900 in the kernel file (again, if setup_sects == 0 the real value is 4.)
904 The kernel is a bzImage kernel if the protocol >= 2.00 and the 0x01
905 bit (LOAD_HIGH) in the loadflags field is set:
911 the entire 0x10000-0x90000 range of memory. This means it is pretty
912 much a requirement for these kernels to load the real-mode part at
918 If the command line provided by the boot loader is entered by the
919 user, the user may expect the following command line options to work.
920 They should normally not be deleted from the kernel command line even
921 though not all of them are actually meaningful to the kernel. Boot
922 loader authors who need additional command line options for the boot
925 conflict with actual kernel options now or in the future.
929 decimal, octal, or hexadecimal) or one of the strings
931 (meaning 0xFFFD). This value should be entered into the
932 vid_mode field, as it is used by the kernel before the command
938 << 30, << 40, << 50 or << 60). This specifies the end of
939 memory to the kernel. This affects the possible placement of
941 memory. Note that this is an option to *both* the kernel and
942 the bootloader!
949 In addition, some boot loaders add the following options to the
953 The boot image which was loaded. Again, the meaning of <file>
959 If these options are added by the boot loader, it is highly
960 recommended that they are located *first*, before the user-specified
962 gets confused by the "auto" option.
967 The kernel is started by jumping to the kernel entry point, which is
968 located at *segment* offset 0x20 from the start of the real mode
970 0x90000, the kernel entry point is 9020:0000.
972 At entry, ds = es = ss should point to the start of the real-mode
973 kernel code (0x9000 if the code is loaded at 0x90000), sp should be
974 set up properly, normally pointing to the top of the heap, and
976 the kernel, it is recommended that the boot loader sets fs = gs = ds =
981 /* Note: in the case of the "old" kernel protocol, base_ptr must
982 be == 0x90000 at this point; see the previous sample code */
988 /* Set up the real-mode kernel stack */
993 jmp_far(seg+0x20, 0); /* Run the kernel */
996 switch off the floppy motor before running the kernel, since the
997 kernel boot leaves interrupts off and thus the motor will not be
998 switched off, especially if the loaded kernel has the floppy driver as
1004 If the boot loader runs in a particularly hostile environment (such as
1005 LOADLIN, which runs under DOS) it may be impossible to follow the
1006 standard memory location requirements. Such a boot loader may use the
1007 following hooks that, if set, are invoked by the kernel at the
1011 IMPORTANT: All the hooks are required to preserve %esp, %ebp, %esi and
1020 A 32-bit flat-mode routine *jumped* to immediately after the
1021 transition to protected mode, but before the kernel is
1026 After completing your hook, you should jump to the address
1034 LinuxBIOS, etc, and kexec, the 16-bit real mode setup code in kernel
1038 In 32-bit boot protocol, the first step in loading a Linux kernel
1039 should be to setup the boot parameters (struct boot_params,
1041 should be allocated and initialized to all zero. Then the setup header
1048 In addition to read/modify/write the setup header of the struct
1049 boot_params as that of 16-bit boot protocol, the boot loader should
1050 also fill the additional fields of the struct boot_params as that
1053 After setting up the struct boot_params, the boot loader can load the
1054 32/64-bit kernel in the same way as that of 16-bit boot protocol.
1056 In 32-bit boot protocol, the kernel is started by jumping to the
1057 32-bit kernel entry point, which is the start address of loaded
1060 At entry, the CPU must be in 32-bit protected mode with paging
1061 disabled; a GDT must be loaded with the descriptors for selectors
1065 must be __BOOT_DS; interrupt must be disabled; %esi must hold the base
1066 address of the struct boot_params; %ebp, %edi and %ebx must be zero.
1073 In 64-bit boot protocol, the first step in loading a Linux kernel
1074 should be to setup the boot parameters (struct boot_params,
1077 Then, the setup header at offset 0x01f1 of kernel image on should be
1083 In addition to read/modify/write the setup header of the struct
1084 boot_params as that of 16-bit boot protocol, the boot loader should
1085 also fill the additional fields of the struct boot_params as described
1088 After setting up the struct boot_params, the boot loader can load
1089 64-bit kernel in the same way as that of 16-bit boot protocol, but
1092 In 64-bit boot protocol, the kernel is started by jumping to the
1093 64-bit kernel entry point, which is the start address of loaded
1096 At entry, the CPU must be in 64-bit mode with paging enabled.
1099 a GDT must be loaded with the descriptors for selectors
1103 must be __BOOT_DS; interrupt must be disabled; %rsi must hold the base
1104 address of the struct boot_params.
1108 This protocol allows boot loaders to defer initialisation to the EFI
1109 boot stub. The boot loader is required to load the kernel/initrd(s)
1110 from the boot media and jump to the EFI handover protocol entry point
1111 which is hdr->handover_offset bytes from the beginning of
1114 The function prototype for the handover entry point looks like this,
1118 'handle' is the EFI image handle passed to the boot loader by the EFI
1119 firmware, 'table' is the EFI system table - these are the first two
1120 arguments of the "handoff state" as described in section 2.3 of the
1121 UEFI specification. 'bp' is the boot loader-allocated boot params.
1123 The boot loader *must* fill out the following fields in bp,