Lines Matching refs:boot
4 On the x86 platform, the Linux kernel uses a rather complicated boot
11 Currently, the following versions of the Linux/x86 boot protocol exist.
18 boot loader and the kernel. setup.S made relocatable,
40 the boot command line.
42 Protocol 2.07: (Kernel 2.6.24) Added paravirtualised boot protocol.
55 pref_address fields. Added extended boot loader IDs.
78 | Kernel boot sector | The kernel legacy boot sector.
93 0x100000 ("high memory"), and the kernel real-mode block (boot sector,
100 low memory touched by the boot loader -- as low as possible, since
103 memory. The boot loader should use the "INT 12h" BIOS call to verify
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
111 0x90000 segment, the boot loader should make sure not to use memory
114 For a modern bzImage kernel with boot protocol version >= 2.02, a
129 | Kernel boot sector | The kernel legacy boot sector.
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
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
178 0218/4 2.00+ ramdisk_image initrd load address (set by boot loader)
179 021C/4 2.00+ ramdisk_size initrd size (set by boot loader)
182 0226/1 2.02+(3 ext_loader_ver Extended boot loader version
183 0227/1 2.02+(3 ext_loader_type Extended boot loader ID
204 (2) For boot protocol prior to 2.04, the upper two bytes of the syssize
208 (3) Ignored, but safe to set, for boot protocols 2.02-2.09.
211 the boot protocol version is "old". Loading an old kernel, the
231 All general purpose boot loaders should write the fields marked
234 boot loaders can ignore those fields.
244 0, the real value is 4. The real-mode code consists of the boot
316 Contains the boot protocol version, in (major << 8)+minor format,
359 If your boot loader has an assigned id (see table below), enter
360 0xTV here, where T is an identifier for the boot loader and V is
363 For boot loader IDs above T = 0xD, write T = 0xE to this field and
374 Assigned boot loader ids (hexadecimal):
445 The unit is bytes starting with the beginning of the boot sector.
456 address of the kernel, and can be used by the boot loader to
461 1. as a boot loader hook (see ADVANCED BOOT LOADER HOOKS below.)
507 The use of this field is boot loader specific. If not written, it
537 Fill in this field even if your boot loader does not support a
540 zero, the kernel will assume that your boot loader does not support
549 ramdisk/ramfs contents. For boot protocols 2.02 or earlier, this
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.
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
618 - If 1, the kernel supports kexec EFI boot with EFI runtime support.
686 struct setup_data. This is used to define a more extensible boot
726 as the total amount of memory the kernel needs to boot, but it can
727 be used by a relocating boot loader to help select a safe load
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
759 The kernel command line has become an important way for the boot
761 relevant to the boot loader itself, see "special command line options"
769 If the boot protocol version is 2.02 or later, the address of the
803 - When loading a 2.01 or earlier boot protocol kernel.
805 -> For the 2.00 and 2.01 boot protocols, the real-mode code
812 For boot protocol 2.02 or higher, the command line does not have to be
838 Such a boot loader should enter the following fields in the header:
918 If the command line provided by the boot loader is entered by the
922 loader authors who need additional command line options for the boot
946 obviously bootloader-dependent, and some boot loaders
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
976 the kernel, it is recommended that the boot loader sets fs = gs = ds =
995 If your boot sector accesses a floppy drive, it is recommended to
997 kernel boot leaves interrupts off and thus the motor will not be
1004 If the boot loader runs in a particularly hostile environment (such as
1006 standard memory location requirements. Such a boot loader may use the
1027 that was in this field before your boot loader overwrote it
1035 based on legacy BIOS can not be used, so a 32-bit boot protocol needs
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,
1049 boot_params as that of 16-bit boot protocol, the boot loader should
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
1071 and we need a 64-bit boot protocol.
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,
1084 boot_params as that of 16-bit boot protocol, the boot loader should
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
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
1118 'handle' is the EFI image handle passed to the boot loader by the EFI
1121 UEFI specification. 'bp' is the boot loader-allocated boot params.
1123 The boot loader *must* fill out the following fields in bp,