Commit | Line | Data |
---|---|---|
f1f238a9 CD |
1 | .. SPDX-License-Identifier: GPL-2.0 |
2 | ||
3 | =========================== | |
4 | The Linux/x86 Boot Protocol | |
5 | =========================== | |
1da177e4 | 6 | |
4039feb5 | 7 | On the x86 platform, the Linux kernel uses a rather complicated boot |
1da177e4 LT |
8 | convention. This has evolved partially due to historical aspects, as |
9 | well as the desire in the early days to have the kernel itself be a | |
10 | bootable image, the complicated PC memory model and due to changed | |
11 | expectations in the PC industry caused by the effective demise of | |
12 | real-mode DOS as a mainstream operating system. | |
13 | ||
4039feb5 | 14 | Currently, the following versions of the Linux/x86 boot protocol exist. |
1da177e4 | 15 | |
f1f238a9 CD |
16 | ============= ============================================================ |
17 | Old kernels zImage/Image support only. Some very early kernels | |
1da177e4 LT |
18 | may not even support a command line. |
19 | ||
f1f238a9 | 20 | Protocol 2.00 (Kernel 1.3.73) Added bzImage and initrd support, as |
1da177e4 LT |
21 | well as a formalized way to communicate between the |
22 | boot loader and the kernel. setup.S made relocatable, | |
23 | although the traditional setup area still assumed | |
24 | writable. | |
25 | ||
f1f238a9 | 26 | Protocol 2.01 (Kernel 1.3.76) Added a heap overrun warning. |
1da177e4 | 27 | |
f1f238a9 | 28 | Protocol 2.02 (Kernel 2.4.0-test3-pre3) New command line protocol. |
1da177e4 LT |
29 | Lower the conventional memory ceiling. No overwrite |
30 | of the traditional setup area, thus making booting | |
31 | safe for systems which use the EBDA from SMM or 32-bit | |
32 | BIOS entry points. zImage deprecated but still | |
33 | supported. | |
34 | ||
f1f238a9 | 35 | Protocol 2.03 (Kernel 2.4.18-pre1) Explicitly makes the highest possible |
1da177e4 LT |
36 | initrd address available to the bootloader. |
37 | ||
f1f238a9 | 38 | Protocol 2.04 (Kernel 2.6.14) Extend the syssize field to four bytes. |
8f9aeca7 | 39 | |
f1f238a9 | 40 | Protocol 2.05 (Kernel 2.6.20) Make protected mode kernel relocatable. |
be274eea | 41 | Introduce relocatable_kernel and kernel_alignment fields. |
f8eeaaf4 | 42 | |
f1f238a9 | 43 | Protocol 2.06 (Kernel 2.6.22) Added a field that contains the size of |
4c0587e6 | 44 | the boot command line. |
8f9aeca7 | 45 | |
f1f238a9 | 46 | Protocol 2.07 (Kernel 2.6.24) Added paravirtualised boot protocol. |
4c0587e6 IC |
47 | Introduced hardware_subarch and hardware_subarch_data |
48 | and KEEP_SEGMENTS flag in load_flags. | |
49 | ||
f1f238a9 | 50 | Protocol 2.08 (Kernel 2.6.26) Added crc32 checksum and ELF format |
2f6de3a1 | 51 | payload. Introduced payload_offset and payload_length |
4c0587e6 IC |
52 | fields to aid in locating the payload. |
53 | ||
f1f238a9 | 54 | Protocol 2.09 (Kernel 2.6.26) Added a field of 64-bit physical |
fb884381 | 55 | pointer to single linked list of struct setup_data. |
1da177e4 | 56 | |
f1f238a9 | 57 | Protocol 2.10 (Kernel 2.6.31) Added a protocol for relaxed alignment |
d297366b | 58 | beyond the kernel_alignment added, new init_size and |
5031296c | 59 | pref_address fields. Added extended boot loader IDs. |
d297366b | 60 | |
f1f238a9 | 61 | Protocol 2.11 (Kernel 3.6) Added a field for offset of EFI handover |
9ca8f72a MF |
62 | protocol entry point. |
63 | ||
f1f238a9 | 64 | Protocol 2.12 (Kernel 3.8) Added the xloadflags field and extension fields |
c5ed311b | 65 | to struct boot_params for loading bzImage and ramdisk |
09c205af PA |
66 | above 4G in 64bit. |
67 | ||
f1f238a9 | 68 | Protocol 2.13 (Kernel 3.14) Support 32- and 64-bit flags being set in |
30cc0b6c JG |
69 | xloadflags to support booting a 64-bit kernel from 32-bit |
70 | EFI | |
2c33c27f | 71 | |
0854cbdb RD |
72 | Protocol 2.14 BURNT BY INCORRECT COMMIT |
73 | ae7e1238e68f2a472a125673ab506d49158c1889 | |
2c33c27f DK |
74 | (x86/boot: Add ACPI RSDP address to setup_header) |
75 | DO NOT USE!!! ASSUME SAME AS 2.13. | |
76 | ||
0854cbdb | 77 | Protocol 2.15 (Kernel 5.5) Added the kernel_info and kernel_info.setup_type_max. |
f1f238a9 | 78 | ============= ============================================================ |
30cc0b6c | 79 | |
2c33c27f DK |
80 | .. note:: |
81 | The protocol version number should be changed only if the setup header | |
82 | is changed. There is no need to update the version number if boot_params | |
83 | or kernel_info are changed. Additionally, it is recommended to use | |
84 | xloadflags (in this case the protocol version number should not be | |
85 | updated either) or kernel_info to communicate supported Linux kernel | |
86 | features to the boot loader. Due to very limited space available in | |
87 | the original setup header every update to it should be considered | |
88 | with great care. Starting from the protocol 2.15 the primary way to | |
89 | communicate things to the boot loader is the kernel_info. | |
90 | ||
1da177e4 | 91 | |
f1f238a9 CD |
92 | Memory Layout |
93 | ============= | |
1da177e4 | 94 | |
f1f238a9 CD |
95 | The traditional memory map for the kernel loader, used for Image or |
96 | zImage kernels, typically looks like:: | |
97 | ||
98 | | | | |
99 | 0A0000 +------------------------+ | |
100 | | Reserved for BIOS | Do not use. Reserved for BIOS EBDA. | |
101 | 09A000 +------------------------+ | |
102 | | Command line | | |
103 | | Stack/heap | For use by the kernel real-mode code. | |
104 | 098000 +------------------------+ | |
105 | | Kernel setup | The kernel real-mode code. | |
106 | 090200 +------------------------+ | |
107 | | Kernel boot sector | The kernel legacy boot sector. | |
108 | 090000 +------------------------+ | |
109 | | Protected-mode kernel | The bulk of the kernel image. | |
110 | 010000 +------------------------+ | |
111 | | Boot loader | <- Boot sector entry point 0000:7C00 | |
112 | 001000 +------------------------+ | |
113 | | Reserved for MBR/BIOS | | |
114 | 000800 +------------------------+ | |
115 | | Typically used by MBR | | |
116 | 000600 +------------------------+ | |
117 | | BIOS use only | | |
118 | 000000 +------------------------+ | |
1da177e4 LT |
119 | |
120 | When using bzImage, the protected-mode kernel was relocated to | |
121 | 0x100000 ("high memory"), and the kernel real-mode block (boot sector, | |
122 | setup, and stack/heap) was made relocatable to any address between | |
dec04cff PA |
123 | 0x10000 and end of low memory. Unfortunately, in protocols 2.00 and |
124 | 2.01 the 0x90000+ memory range is still used internally by the kernel; | |
125 | the 2.02 protocol resolves that problem. | |
1da177e4 LT |
126 | |
127 | It is desirable to keep the "memory ceiling" -- the highest point in | |
128 | low memory touched by the boot loader -- as low as possible, since | |
129 | some newer BIOSes have begun to allocate some rather large amounts of | |
130 | memory, called the Extended BIOS Data Area, near the top of low | |
131 | memory. The boot loader should use the "INT 12h" BIOS call to verify | |
132 | how much low memory is available. | |
133 | ||
134 | Unfortunately, if INT 12h reports that the amount of memory is too | |
135 | low, there is usually nothing the boot loader can do but to report an | |
136 | error to the user. The boot loader should therefore be designed to | |
137 | take up as little space in low memory as it reasonably can. For | |
138 | zImage or old bzImage kernels, which need data written into the | |
139 | 0x90000 segment, the boot loader should make sure not to use memory | |
140 | above the 0x9A000 point; too many BIOSes will break above that point. | |
141 | ||
dec04cff | 142 | For a modern bzImage kernel with boot protocol version >= 2.02, a |
f1f238a9 CD |
143 | memory layout like the following is suggested:: |
144 | ||
145 | ~ ~ | |
146 | | Protected-mode kernel | | |
147 | 100000 +------------------------+ | |
148 | | I/O memory hole | | |
149 | 0A0000 +------------------------+ | |
150 | | Reserved for BIOS | Leave as much as possible unused | |
151 | ~ ~ | |
152 | | Command line | (Can also be below the X+10000 mark) | |
153 | X+10000 +------------------------+ | |
154 | | Stack/heap | For use by the kernel real-mode code. | |
155 | X+08000 +------------------------+ | |
156 | | Kernel setup | The kernel real-mode code. | |
157 | | Kernel boot sector | The kernel legacy boot sector. | |
158 | X +------------------------+ | |
159 | | Boot loader | <- Boot sector entry point 0000:7C00 | |
160 | 001000 +------------------------+ | |
161 | | Reserved for MBR/BIOS | | |
162 | 000800 +------------------------+ | |
163 | | Typically used by MBR | | |
164 | 000600 +------------------------+ | |
165 | | BIOS use only | | |
166 | 000000 +------------------------+ | |
167 | ||
168 | ... where the address X is as low as the design of the boot loader permits. | |
169 | ||
170 | ||
171 | The Real-Mode Kernel Header | |
172 | =========================== | |
1da177e4 LT |
173 | |
174 | In the following text, and anywhere in the kernel boot sequence, "a | |
175 | sector" refers to 512 bytes. It is independent of the actual sector | |
176 | size of the underlying medium. | |
177 | ||
178 | The first step in loading a Linux kernel should be to load the | |
179 | real-mode code (boot sector and setup code) and then examine the | |
180 | following header at offset 0x01f1. The real-mode code can total up to | |
181 | 32K, although the boot loader may choose to load only the first two | |
182 | sectors (1K) and then examine the bootup sector size. | |
183 | ||
184 | The header looks like: | |
185 | ||
f1f238a9 CD |
186 | =========== ======== ===================== ============================================ |
187 | Offset/Size Proto Name Meaning | |
188 | =========== ======== ===================== ============================================ | |
189 | 01F1/1 ALL(1) setup_sects The size of the setup in sectors | |
190 | 01F2/2 ALL root_flags If set, the root is mounted readonly | |
191 | 01F4/4 2.04+(2) syssize The size of the 32-bit code in 16-byte paras | |
192 | 01F8/2 ALL ram_size DO NOT USE - for bootsect.S use only | |
193 | 01FA/2 ALL vid_mode Video mode control | |
194 | 01FC/2 ALL root_dev Default root device number | |
195 | 01FE/2 ALL boot_flag 0xAA55 magic number | |
196 | 0200/2 2.00+ jump Jump instruction | |
197 | 0202/4 2.00+ header Magic signature "HdrS" | |
198 | 0206/2 2.00+ version Boot protocol version supported | |
199 | 0208/4 2.00+ realmode_swtch Boot loader hook (see below) | |
200 | 020C/2 2.00+ start_sys_seg The load-low segment (0x1000) (obsolete) | |
201 | 020E/2 2.00+ kernel_version Pointer to kernel version string | |
202 | 0210/1 2.00+ type_of_loader Boot loader identifier | |
203 | 0211/1 2.00+ loadflags Boot protocol option flags | |
204 | 0212/2 2.00+ setup_move_size Move to high memory size (used with hooks) | |
205 | 0214/4 2.00+ code32_start Boot loader hook (see below) | |
206 | 0218/4 2.00+ ramdisk_image initrd load address (set by boot loader) | |
207 | 021C/4 2.00+ ramdisk_size initrd size (set by boot loader) | |
208 | 0220/4 2.00+ bootsect_kludge DO NOT USE - for bootsect.S use only | |
209 | 0224/2 2.01+ heap_end_ptr Free memory after setup end | |
210 | 0226/1 2.02+(3) ext_loader_ver Extended boot loader version | |
211 | 0227/1 2.02+(3) ext_loader_type Extended boot loader ID | |
212 | 0228/4 2.02+ cmd_line_ptr 32-bit pointer to the kernel command line | |
213 | 022C/4 2.03+ initrd_addr_max Highest legal initrd address | |
214 | 0230/4 2.05+ kernel_alignment Physical addr alignment required for kernel | |
215 | 0234/1 2.05+ relocatable_kernel Whether kernel is relocatable or not | |
216 | 0235/1 2.10+ min_alignment Minimum alignment, as a power of two | |
217 | 0236/2 2.12+ xloadflags Boot protocol option flags | |
218 | 0238/4 2.06+ cmdline_size Maximum size of the kernel command line | |
219 | 023C/4 2.07+ hardware_subarch Hardware subarchitecture | |
220 | 0240/8 2.07+ hardware_subarch_data Subarchitecture-specific data | |
221 | 0248/4 2.08+ payload_offset Offset of kernel payload | |
222 | 024C/4 2.08+ payload_length Length of kernel payload | |
223 | 0250/8 2.09+ setup_data 64-bit physical pointer to linked list | |
224 | of struct setup_data | |
225 | 0258/8 2.10+ pref_address Preferred loading address | |
226 | 0260/4 2.10+ init_size Linear memory required during initialization | |
227 | 0264/4 2.11+ handover_offset Offset of handover entry point | |
2c33c27f | 228 | 0268/4 2.15+ kernel_info_offset Offset of the kernel_info |
f1f238a9 CD |
229 | =========== ======== ===================== ============================================ |
230 | ||
231 | .. note:: | |
232 | (1) For backwards compatibility, if the setup_sects field contains 0, the | |
233 | real value is 4. | |
234 | ||
235 | (2) For boot protocol prior to 2.04, the upper two bytes of the syssize | |
236 | field are unusable, which means the size of a bzImage kernel | |
237 | cannot be determined. | |
238 | ||
239 | (3) Ignored, but safe to set, for boot protocols 2.02-2.09. | |
5031296c | 240 | |
1da177e4 LT |
241 | If the "HdrS" (0x53726448) magic number is not found at offset 0x202, |
242 | the boot protocol version is "old". Loading an old kernel, the | |
f1f238a9 | 243 | following parameters should be assumed:: |
1da177e4 LT |
244 | |
245 | Image type = zImage | |
246 | initrd not supported | |
247 | Real-mode kernel must be located at 0x90000. | |
248 | ||
249 | Otherwise, the "version" field contains the protocol version, | |
250 | e.g. protocol version 2.01 will contain 0x0201 in this field. When | |
251 | setting fields in the header, you must make sure only to set fields | |
252 | supported by the protocol version in use. | |
253 | ||
dec04cff | 254 | |
e156c617 | 255 | Details of Header Fields |
f1f238a9 | 256 | ======================== |
dec04cff PA |
257 | |
258 | For each field, some are information from the kernel to the bootloader | |
259 | ("read"), some are expected to be filled out by the bootloader | |
260 | ("write"), and some are expected to be read and modified by the | |
261 | bootloader ("modify"). | |
262 | ||
263 | All general purpose boot loaders should write the fields marked | |
264 | (obligatory). Boot loaders who want to load the kernel at a | |
265 | nonstandard address should fill in the fields marked (reloc); other | |
266 | boot loaders can ignore those fields. | |
267 | ||
db2668fd PA |
268 | The byte order of all fields is littleendian (this is x86, after all.) |
269 | ||
f1f238a9 | 270 | ============ =========== |
e5371ac5 | 271 | Field name: setup_sects |
dec04cff PA |
272 | Type: read |
273 | Offset/size: 0x1f1/1 | |
274 | Protocol: ALL | |
f1f238a9 | 275 | ============ =========== |
dec04cff PA |
276 | |
277 | The size of the setup code in 512-byte sectors. If this field is | |
278 | 0, the real value is 4. The real-mode code consists of the boot | |
279 | sector (always one 512-byte sector) plus the setup code. | |
280 | ||
f1f238a9 CD |
281 | ============ ================= |
282 | Field name: root_flags | |
283 | Type: modify (optional) | |
284 | Offset/size: 0x1f2/2 | |
285 | Protocol: ALL | |
286 | ============ ================= | |
dec04cff PA |
287 | |
288 | If this field is nonzero, the root defaults to readonly. The use of | |
289 | this field is deprecated; use the "ro" or "rw" options on the | |
290 | command line instead. | |
291 | ||
f1f238a9 | 292 | ============ =============================================== |
dec04cff PA |
293 | Field name: syssize |
294 | Type: read | |
295 | Offset/size: 0x1f4/4 (protocol 2.04+) 0x1f4/2 (protocol ALL) | |
296 | Protocol: 2.04+ | |
f1f238a9 | 297 | ============ =============================================== |
dec04cff PA |
298 | |
299 | The size of the protected-mode code in units of 16-byte paragraphs. | |
300 | For protocol versions older than 2.04 this field is only two bytes | |
301 | wide, and therefore cannot be trusted for the size of a kernel if | |
302 | the LOAD_HIGH flag is set. | |
303 | ||
f1f238a9 | 304 | ============ =============== |
dec04cff PA |
305 | Field name: ram_size |
306 | Type: kernel internal | |
307 | Offset/size: 0x1f8/2 | |
308 | Protocol: ALL | |
f1f238a9 | 309 | ============ =============== |
dec04cff PA |
310 | |
311 | This field is obsolete. | |
312 | ||
f1f238a9 | 313 | ============ =================== |
dec04cff PA |
314 | Field name: vid_mode |
315 | Type: modify (obligatory) | |
316 | Offset/size: 0x1fa/2 | |
f1f238a9 | 317 | ============ =================== |
dec04cff PA |
318 | |
319 | Please see the section on SPECIAL COMMAND LINE OPTIONS. | |
320 | ||
f1f238a9 | 321 | ============ ================= |
dec04cff PA |
322 | Field name: root_dev |
323 | Type: modify (optional) | |
324 | Offset/size: 0x1fc/2 | |
325 | Protocol: ALL | |
f1f238a9 | 326 | ============ ================= |
dec04cff PA |
327 | |
328 | The default root device device number. The use of this field is | |
329 | deprecated, use the "root=" option on the command line instead. | |
330 | ||
f1f238a9 | 331 | ============ ========= |
dec04cff PA |
332 | Field name: boot_flag |
333 | Type: read | |
334 | Offset/size: 0x1fe/2 | |
335 | Protocol: ALL | |
f1f238a9 | 336 | ============ ========= |
dec04cff PA |
337 | |
338 | Contains 0xAA55. This is the closest thing old Linux kernels have | |
339 | to a magic number. | |
340 | ||
f1f238a9 | 341 | ============ ======= |
dec04cff PA |
342 | Field name: jump |
343 | Type: read | |
344 | Offset/size: 0x200/2 | |
345 | Protocol: 2.00+ | |
f1f238a9 | 346 | ============ ======= |
dec04cff PA |
347 | |
348 | Contains an x86 jump instruction, 0xEB followed by a signed offset | |
349 | relative to byte 0x202. This can be used to determine the size of | |
350 | the header. | |
351 | ||
f1f238a9 | 352 | ============ ======= |
dec04cff PA |
353 | Field name: header |
354 | Type: read | |
355 | Offset/size: 0x202/4 | |
356 | Protocol: 2.00+ | |
f1f238a9 | 357 | ============ ======= |
dec04cff PA |
358 | |
359 | Contains the magic number "HdrS" (0x53726448). | |
360 | ||
f1f238a9 | 361 | ============ ======= |
dec04cff | 362 | Field name: version |
38418404 | 363 | Type: read |
dec04cff PA |
364 | Offset/size: 0x206/2 |
365 | Protocol: 2.00+ | |
f1f238a9 | 366 | ============ ======= |
dec04cff | 367 | |
db2668fd PA |
368 | Contains the boot protocol version, in (major << 8)+minor format, |
369 | e.g. 0x0204 for version 2.04, and 0x0a11 for a hypothetical version | |
370 | 10.17. | |
dec04cff | 371 | |
f1f238a9 | 372 | ============ ================= |
e56d0cfe | 373 | Field name: realmode_swtch |
dec04cff PA |
374 | Type: modify (optional) |
375 | Offset/size: 0x208/4 | |
376 | Protocol: 2.00+ | |
f1f238a9 | 377 | ============ ================= |
dec04cff | 378 | |
db2668fd | 379 | Boot loader hook (see ADVANCED BOOT LOADER HOOKS below.) |
dec04cff | 380 | |
f1f238a9 | 381 | ============ ============= |
e56d0cfe | 382 | Field name: start_sys_seg |
dec04cff | 383 | Type: read |
a021e512 | 384 | Offset/size: 0x20c/2 |
dec04cff | 385 | Protocol: 2.00+ |
f1f238a9 | 386 | ============ ============= |
dec04cff PA |
387 | |
388 | The load low segment (0x1000). Obsolete. | |
389 | ||
f1f238a9 | 390 | ============ ============== |
dec04cff PA |
391 | Field name: kernel_version |
392 | Type: read | |
393 | Offset/size: 0x20e/2 | |
394 | Protocol: 2.00+ | |
f1f238a9 | 395 | ============ ============== |
dec04cff PA |
396 | |
397 | If set to a nonzero value, contains a pointer to a NUL-terminated | |
398 | human-readable kernel version number string, less 0x200. This can | |
399 | be used to display the kernel version to the user. This value | |
db2668fd PA |
400 | should be less than (0x200*setup_sects). |
401 | ||
402 | For example, if this value is set to 0x1c00, the kernel version | |
403 | number string can be found at offset 0x1e00 in the kernel file. | |
404 | This is a valid value if and only if the "setup_sects" field | |
f1f238a9 | 405 | contains the value 15 or higher, as:: |
db2668fd PA |
406 | |
407 | 0x1c00 < 15*0x200 (= 0x1e00) but | |
408 | 0x1c00 >= 14*0x200 (= 0x1c00) | |
409 | ||
f1f238a9 | 410 | 0x1c00 >> 9 = 14, So the minimum value for setup_secs is 15. |
dec04cff | 411 | |
f1f238a9 | 412 | ============ ================== |
dec04cff PA |
413 | Field name: type_of_loader |
414 | Type: write (obligatory) | |
415 | Offset/size: 0x210/1 | |
416 | Protocol: 2.00+ | |
f1f238a9 | 417 | ============ ================== |
dec04cff PA |
418 | |
419 | If your boot loader has an assigned id (see table below), enter | |
420 | 0xTV here, where T is an identifier for the boot loader and V is | |
421 | a version number. Otherwise, enter 0xFF here. | |
422 | ||
5031296c PA |
423 | For boot loader IDs above T = 0xD, write T = 0xE to this field and |
424 | write the extended ID minus 0x10 to the ext_loader_type field. | |
425 | Similarly, the ext_loader_ver field can be used to provide more than | |
426 | four bits for the bootloader version. | |
427 | ||
f1f238a9 | 428 | For example, for T = 0x15, V = 0x234, write:: |
5031296c | 429 | |
f1f238a9 CD |
430 | type_of_loader <- 0xE4 |
431 | ext_loader_type <- 0x05 | |
432 | ext_loader_ver <- 0x23 | |
5031296c | 433 | |
c5e5c42a PA |
434 | Assigned boot loader ids (hexadecimal): |
435 | ||
f1f238a9 CD |
436 | == ======================================= |
437 | 0 LILO | |
438 | (0x00 reserved for pre-2.00 bootloader) | |
1da177e4 | 439 | 1 Loadlin |
f1f238a9 CD |
440 | 2 bootsect-loader |
441 | (0x20, all other values reserved) | |
5031296c | 442 | 3 Syslinux |
cd34ab8b | 443 | 4 Etherboot/gPXE/iPXE |
1da177e4 | 444 | 5 ELILO |
9ee670fd | 445 | 7 GRUB |
5031296c | 446 | 8 U-Boot |
354332ee | 447 | 9 Xen |
c229ec5d | 448 | A Gujin |
dec04cff | 449 | B Qemu |
5031296c | 450 | C Arcturus Networks uCbootloader |
4bfe24ac | 451 | D kexec-tools |
f1f238a9 CD |
452 | E Extended (see ext_loader_type) |
453 | F Special (0xFF = undefined) | |
454 | 10 Reserved | |
455 | 11 Minimal Linux Bootloader | |
456 | <http://sebastian-plotz.blogspot.de> | |
457 | 12 OVMF UEFI virtualization stack | |
a27e292b | 458 | 13 barebox |
f1f238a9 | 459 | == ======================================= |
1da177e4 | 460 | |
f1f238a9 | 461 | Please contact <hpa@zytor.com> if you need a bootloader ID value assigned. |
dec04cff | 462 | |
f1f238a9 | 463 | ============ =================== |
dec04cff PA |
464 | Field name: loadflags |
465 | Type: modify (obligatory) | |
466 | Offset/size: 0x211/1 | |
467 | Protocol: 2.00+ | |
f1f238a9 | 468 | ============ =================== |
dec04cff PA |
469 | |
470 | This field is a bitmask. | |
471 | ||
472 | Bit 0 (read): LOADED_HIGH | |
f1f238a9 | 473 | |
dec04cff PA |
474 | - If 0, the protected-mode code is loaded at 0x10000. |
475 | - If 1, the protected-mode code is loaded at 0x100000. | |
476 | ||
d4bd4415 | 477 | Bit 1 (kernel internal): KASLR_FLAG |
f1f238a9 | 478 | |
78cac48c BP |
479 | - Used internally by the compressed kernel to communicate |
480 | KASLR status to kernel proper. | |
f1f238a9 CD |
481 | |
482 | - If 1, KASLR enabled. | |
483 | - If 0, KASLR disabled. | |
78cac48c | 484 | |
4039feb5 | 485 | Bit 5 (write): QUIET_FLAG |
f1f238a9 | 486 | |
4039feb5 PA |
487 | - If 0, print early messages. |
488 | - If 1, suppress early messages. | |
f1f238a9 | 489 | |
4039feb5 PA |
490 | This requests to the kernel (decompressor and early |
491 | kernel) to not write early messages that require | |
492 | accessing the display hardware directly. | |
493 | ||
67a6af7a | 494 | Bit 6 (obsolete): KEEP_SEGMENTS |
f1f238a9 | 495 | |
e5371ac5 | 496 | Protocol: 2.07+ |
f1f238a9 | 497 | |
67a6af7a | 498 | - This flag is obsolete. |
e5371ac5 | 499 | |
dec04cff | 500 | Bit 7 (write): CAN_USE_HEAP |
f1f238a9 | 501 | |
dec04cff PA |
502 | Set this bit to 1 to indicate that the value entered in the |
503 | heap_end_ptr is valid. If this field is clear, some setup code | |
504 | functionality will be disabled. | |
505 | ||
f1f238a9 CD |
506 | |
507 | ============ =================== | |
dec04cff PA |
508 | Field name: setup_move_size |
509 | Type: modify (obligatory) | |
510 | Offset/size: 0x212/2 | |
511 | Protocol: 2.00-2.01 | |
f1f238a9 | 512 | ============ =================== |
dec04cff PA |
513 | |
514 | When using protocol 2.00 or 2.01, if the real mode kernel is not | |
515 | loaded at 0x90000, it gets moved there later in the loading | |
516 | sequence. Fill in this field if you want additional data (such as | |
517 | the kernel command line) moved in addition to the real-mode kernel | |
518 | itself. | |
519 | ||
520 | The unit is bytes starting with the beginning of the boot sector. | |
f1f238a9 | 521 | |
dec04cff PA |
522 | This field is can be ignored when the protocol is 2.02 or higher, or |
523 | if the real-mode code is loaded at 0x90000. | |
524 | ||
f1f238a9 | 525 | ============ ======================== |
dec04cff PA |
526 | Field name: code32_start |
527 | Type: modify (optional, reloc) | |
528 | Offset/size: 0x214/4 | |
529 | Protocol: 2.00+ | |
f1f238a9 | 530 | ============ ======================== |
dec04cff PA |
531 | |
532 | The address to jump to in protected mode. This defaults to the load | |
533 | address of the kernel, and can be used by the boot loader to | |
534 | determine the proper load address. | |
535 | ||
536 | This field can be modified for two purposes: | |
537 | ||
f1f238a9 | 538 | 1. as a boot loader hook (see Advanced Boot Loader Hooks below.) |
dec04cff | 539 | |
f1f238a9 CD |
540 | 2. if a bootloader which does not install a hook loads a |
541 | relocatable kernel at a nonstandard address it will have to modify | |
542 | this field to point to the load address. | |
dec04cff | 543 | |
f1f238a9 | 544 | ============ ================== |
dec04cff PA |
545 | Field name: ramdisk_image |
546 | Type: write (obligatory) | |
547 | Offset/size: 0x218/4 | |
548 | Protocol: 2.00+ | |
f1f238a9 | 549 | ============ ================== |
dec04cff PA |
550 | |
551 | The 32-bit linear address of the initial ramdisk or ramfs. Leave at | |
552 | zero if there is no initial ramdisk/ramfs. | |
553 | ||
f1f238a9 | 554 | ============ ================== |
dec04cff PA |
555 | Field name: ramdisk_size |
556 | Type: write (obligatory) | |
557 | Offset/size: 0x21c/4 | |
558 | Protocol: 2.00+ | |
f1f238a9 | 559 | ============ ================== |
dec04cff PA |
560 | |
561 | Size of the initial ramdisk or ramfs. Leave at zero if there is no | |
562 | initial ramdisk/ramfs. | |
563 | ||
f1f238a9 | 564 | ============ =============== |
dec04cff PA |
565 | Field name: bootsect_kludge |
566 | Type: kernel internal | |
567 | Offset/size: 0x220/4 | |
568 | Protocol: 2.00+ | |
f1f238a9 | 569 | ============ =============== |
dec04cff PA |
570 | |
571 | This field is obsolete. | |
572 | ||
f1f238a9 | 573 | ============ ================== |
dec04cff PA |
574 | Field name: heap_end_ptr |
575 | Type: write (obligatory) | |
576 | Offset/size: 0x224/2 | |
577 | Protocol: 2.01+ | |
f1f238a9 | 578 | ============ ================== |
dec04cff PA |
579 | |
580 | Set this field to the offset (from the beginning of the real-mode | |
581 | code) of the end of the setup stack/heap, minus 0x0200. | |
582 | ||
f1f238a9 | 583 | ============ ================ |
5031296c PA |
584 | Field name: ext_loader_ver |
585 | Type: write (optional) | |
586 | Offset/size: 0x226/1 | |
587 | Protocol: 2.02+ | |
f1f238a9 | 588 | ============ ================ |
5031296c PA |
589 | |
590 | This field is used as an extension of the version number in the | |
591 | type_of_loader field. The total version number is considered to be | |
592 | (type_of_loader & 0x0f) + (ext_loader_ver << 4). | |
593 | ||
594 | The use of this field is boot loader specific. If not written, it | |
595 | is zero. | |
596 | ||
597 | Kernels prior to 2.6.31 did not recognize this field, but it is safe | |
598 | to write for protocol version 2.02 or higher. | |
599 | ||
f1f238a9 | 600 | ============ ===================================================== |
5031296c PA |
601 | Field name: ext_loader_type |
602 | Type: write (obligatory if (type_of_loader & 0xf0) == 0xe0) | |
603 | Offset/size: 0x227/1 | |
604 | Protocol: 2.02+ | |
f1f238a9 | 605 | ============ ===================================================== |
5031296c PA |
606 | |
607 | This field is used as an extension of the type number in | |
608 | type_of_loader field. If the type in type_of_loader is 0xE, then | |
609 | the actual type is (ext_loader_type + 0x10). | |
610 | ||
611 | This field is ignored if the type in type_of_loader is not 0xE. | |
612 | ||
613 | Kernels prior to 2.6.31 did not recognize this field, but it is safe | |
614 | to write for protocol version 2.02 or higher. | |
615 | ||
f1f238a9 | 616 | ============ ================== |
dec04cff PA |
617 | Field name: cmd_line_ptr |
618 | Type: write (obligatory) | |
619 | Offset/size: 0x228/4 | |
620 | Protocol: 2.02+ | |
f1f238a9 | 621 | ============ ================== |
dec04cff PA |
622 | |
623 | Set this field to the linear address of the kernel command line. | |
624 | The kernel command line can be located anywhere between the end of | |
625 | the setup heap and 0xA0000; it does not have to be located in the | |
626 | same 64K segment as the real-mode code itself. | |
627 | ||
628 | Fill in this field even if your boot loader does not support a | |
629 | command line, in which case you can point this to an empty string | |
630 | (or better yet, to the string "auto".) If this field is left at | |
631 | zero, the kernel will assume that your boot loader does not support | |
632 | the 2.02+ protocol. | |
633 | ||
f1f238a9 | 634 | ============ =============== |
3e920b53 | 635 | Field name: initrd_addr_max |
dec04cff PA |
636 | Type: read |
637 | Offset/size: 0x22c/4 | |
638 | Protocol: 2.03+ | |
f1f238a9 | 639 | ============ =============== |
dec04cff PA |
640 | |
641 | The maximum address that may be occupied by the initial | |
642 | ramdisk/ramfs contents. For boot protocols 2.02 or earlier, this | |
643 | field is not present, and the maximum address is 0x37FFFFFF. (This | |
644 | address is defined as the address of the highest safe byte, so if | |
645 | your ramdisk is exactly 131072 bytes long and this field is | |
646 | 0x37FFFFFF, you can start your ramdisk at 0x37FE0000.) | |
647 | ||
f1f238a9 | 648 | ============ ============================ |
dec04cff | 649 | Field name: kernel_alignment |
d297366b | 650 | Type: read/modify (reloc) |
dec04cff | 651 | Offset/size: 0x230/4 |
d297366b | 652 | Protocol: 2.05+ (read), 2.10+ (modify) |
f1f238a9 | 653 | ============ ============================ |
d297366b PA |
654 | |
655 | Alignment unit required by the kernel (if relocatable_kernel is | |
656 | true.) A relocatable kernel that is loaded at an alignment | |
657 | incompatible with the value in this field will be realigned during | |
658 | kernel initialization. | |
dec04cff | 659 | |
d297366b PA |
660 | Starting with protocol version 2.10, this reflects the kernel |
661 | alignment preferred for optimal performance; it is possible for the | |
662 | loader to modify this field to permit a lesser alignment. See the | |
663 | min_alignment and pref_address field below. | |
dec04cff | 664 | |
f1f238a9 | 665 | ============ ================== |
dec04cff PA |
666 | Field name: relocatable_kernel |
667 | Type: read (reloc) | |
668 | Offset/size: 0x234/1 | |
669 | Protocol: 2.05+ | |
f1f238a9 | 670 | ============ ================== |
dec04cff PA |
671 | |
672 | If this field is nonzero, the protected-mode part of the kernel can | |
673 | be loaded at any address that satisfies the kernel_alignment field. | |
674 | After loading, the boot loader must set the code32_start field to | |
675 | point to the loaded code, or to a boot loader hook. | |
676 | ||
f1f238a9 | 677 | ============ ============= |
d297366b PA |
678 | Field name: min_alignment |
679 | Type: read (reloc) | |
680 | Offset/size: 0x235/1 | |
681 | Protocol: 2.10+ | |
f1f238a9 | 682 | ============ ============= |
d297366b PA |
683 | |
684 | This field, if nonzero, indicates as a power of two the minimum | |
685 | alignment required, as opposed to preferred, by the kernel to boot. | |
686 | If a boot loader makes use of this field, it should update the | |
f1f238a9 | 687 | kernel_alignment field with the alignment unit desired; typically:: |
d297366b PA |
688 | |
689 | kernel_alignment = 1 << min_alignment | |
690 | ||
691 | There may be a considerable performance cost with an excessively | |
692 | misaligned kernel. Therefore, a loader should typically try each | |
693 | power-of-two alignment from kernel_alignment down to this alignment. | |
694 | ||
f1f238a9 CD |
695 | ============ ========== |
696 | Field name: xloadflags | |
697 | Type: read | |
698 | Offset/size: 0x236/2 | |
699 | Protocol: 2.12+ | |
700 | ============ ========== | |
09c205af PA |
701 | |
702 | This field is a bitmask. | |
703 | ||
704 | Bit 0 (read): XLF_KERNEL_64 | |
f1f238a9 | 705 | |
09c205af PA |
706 | - If 1, this kernel has the legacy 64-bit entry point at 0x200. |
707 | ||
708 | Bit 1 (read): XLF_CAN_BE_LOADED_ABOVE_4G | |
f1f238a9 | 709 | |
09c205af PA |
710 | - If 1, kernel/boot_params/cmdline/ramdisk can be above 4G. |
711 | ||
712 | Bit 2 (read): XLF_EFI_HANDOVER_32 | |
f1f238a9 | 713 | |
09c205af PA |
714 | - If 1, the kernel supports the 32-bit EFI handoff entry point |
715 | given at handover_offset. | |
716 | ||
717 | Bit 3 (read): XLF_EFI_HANDOVER_64 | |
f1f238a9 | 718 | |
09c205af PA |
719 | - If 1, the kernel supports the 64-bit EFI handoff entry point |
720 | given at handover_offset + 0x200. | |
721 | ||
456a29dd | 722 | Bit 4 (read): XLF_EFI_KEXEC |
f1f238a9 | 723 | |
456a29dd DY |
724 | - If 1, the kernel supports kexec EFI boot with EFI runtime support. |
725 | ||
f1f238a9 CD |
726 | |
727 | ============ ============ | |
dec04cff PA |
728 | Field name: cmdline_size |
729 | Type: read | |
730 | Offset/size: 0x238/4 | |
731 | Protocol: 2.06+ | |
f1f238a9 | 732 | ============ ============ |
dec04cff PA |
733 | |
734 | The maximum size of the command line without the terminating | |
735 | zero. This means that the command line can contain at most | |
736 | cmdline_size characters. With protocol version 2.05 and earlier, the | |
737 | maximum size was 255. | |
8f9aeca7 | 738 | |
f1f238a9 | 739 | ============ ==================================== |
e5371ac5 | 740 | Field name: hardware_subarch |
4039feb5 | 741 | Type: write (optional, defaults to x86/PC) |
e5371ac5 RR |
742 | Offset/size: 0x23c/4 |
743 | Protocol: 2.07+ | |
f1f238a9 | 744 | ============ ==================================== |
e5371ac5 RR |
745 | |
746 | In a paravirtualized environment the hardware low level architectural | |
747 | pieces such as interrupt handling, page table handling, and | |
748 | accessing process control registers needs to be done differently. | |
749 | ||
750 | This field allows the bootloader to inform the kernel we are in one | |
751 | one of those environments. | |
752 | ||
f1f238a9 | 753 | ========== ============================== |
e5371ac5 RR |
754 | 0x00000000 The default x86/PC environment |
755 | 0x00000001 lguest | |
756 | 0x00000002 Xen | |
162bc7ab | 757 | 0x00000003 Moorestown MID |
c751e17b | 758 | 0x00000004 CE4100 TV Platform |
f1f238a9 | 759 | ========== ============================== |
e5371ac5 | 760 | |
f1f238a9 | 761 | ============ ========================= |
e5371ac5 | 762 | Field name: hardware_subarch_data |
4039feb5 | 763 | Type: write (subarch-dependent) |
e5371ac5 RR |
764 | Offset/size: 0x240/8 |
765 | Protocol: 2.07+ | |
f1f238a9 | 766 | ============ ========================= |
e5371ac5 RR |
767 | |
768 | A pointer to data that is specific to hardware subarch | |
4039feb5 PA |
769 | This field is currently unused for the default x86/PC environment, |
770 | do not modify. | |
e5371ac5 | 771 | |
f1f238a9 | 772 | ============ ============== |
87253d1b | 773 | Field name: payload_offset |
099e1377 IC |
774 | Type: read |
775 | Offset/size: 0x248/4 | |
776 | Protocol: 2.08+ | |
f1f238a9 | 777 | ============ ============== |
099e1377 | 778 | |
e1286f2c PK |
779 | If non-zero then this field contains the offset from the beginning |
780 | of the protected-mode code to the payload. | |
87253d1b IC |
781 | |
782 | The payload may be compressed. The format of both the compressed and | |
783 | uncompressed data should be determined using the standard magic | |
ee287587 | 784 | numbers. The currently supported compression formats are gzip |
30314804 | 785 | (magic numbers 1F 8B or 1F 9E), bzip2 (magic number 42 5A), LZMA |
fb46d057 NT |
786 | (magic number 5D 00), XZ (magic number FD 37), LZ4 (magic number |
787 | 02 21) and ZSTD (magic number 28 B5). The uncompressed payload is | |
788 | currently always ELF (magic number 7F 45 4C 46). | |
f9b493ac | 789 | |
f1f238a9 | 790 | ============ ============== |
87253d1b | 791 | Field name: payload_length |
099e1377 IC |
792 | Type: read |
793 | Offset/size: 0x24c/4 | |
794 | Protocol: 2.08+ | |
f1f238a9 | 795 | ============ ============== |
099e1377 | 796 | |
87253d1b | 797 | The length of the payload. |
1da177e4 | 798 | |
f1f238a9 | 799 | ============ =============== |
4039feb5 PA |
800 | Field name: setup_data |
801 | Type: write (special) | |
802 | Offset/size: 0x250/8 | |
803 | Protocol: 2.09+ | |
f1f238a9 | 804 | ============ =============== |
4039feb5 PA |
805 | |
806 | The 64-bit physical pointer to NULL terminated single linked list of | |
807 | struct setup_data. This is used to define a more extensible boot | |
808 | parameters passing mechanism. The definition of struct setup_data is | |
f1f238a9 | 809 | as follow:: |
4039feb5 | 810 | |
f1f238a9 CD |
811 | struct setup_data { |
812 | u64 next; | |
813 | u32 type; | |
814 | u32 len; | |
815 | u8 data[0]; | |
816 | }; | |
4039feb5 PA |
817 | |
818 | Where, the next is a 64-bit physical pointer to the next node of | |
819 | linked list, the next field of the last node is 0; the type is used | |
820 | to identify the contents of data; the len is the length of data | |
821 | field; the data holds the real payload. | |
822 | ||
823 | This list may be modified at a number of points during the bootup | |
824 | process. Therefore, when modifying this list one should always make | |
825 | sure to consider the case where the linked list already contains | |
826 | entries. | |
827 | ||
b3c72fc9 DK |
828 | The setup_data is a bit awkward to use for extremely large data objects, |
829 | both because the setup_data header has to be adjacent to the data object | |
830 | and because it has a 32-bit length field. However, it is important that | |
831 | intermediate stages of the boot process have a way to identify which | |
832 | chunks of memory are occupied by kernel data. | |
833 | ||
834 | Thus setup_indirect struct and SETUP_INDIRECT type were introduced in | |
e43630ed | 835 | protocol 2.15:: |
b3c72fc9 | 836 | |
e43630ed DA |
837 | struct setup_indirect { |
838 | __u32 type; | |
839 | __u32 reserved; /* Reserved, must be set to zero. */ | |
840 | __u64 len; | |
841 | __u64 addr; | |
842 | }; | |
b3c72fc9 DK |
843 | |
844 | The type member is a SETUP_INDIRECT | SETUP_* type. However, it cannot be | |
845 | SETUP_INDIRECT itself since making the setup_indirect a tree structure | |
846 | could require a lot of stack space in something that needs to parse it | |
847 | and stack space can be limited in boot contexts. | |
848 | ||
849 | Let's give an example how to point to SETUP_E820_EXT data using setup_indirect. | |
e43630ed DA |
850 | In this case setup_data and setup_indirect will look like this:: |
851 | ||
852 | struct setup_data { | |
853 | __u64 next = 0 or <addr_of_next_setup_data_struct>; | |
854 | __u32 type = SETUP_INDIRECT; | |
bcadb65f | 855 | __u32 len = sizeof(setup_indirect); |
e43630ed DA |
856 | __u8 data[sizeof(setup_indirect)] = struct setup_indirect { |
857 | __u32 type = SETUP_INDIRECT | SETUP_E820_EXT; | |
858 | __u32 reserved = 0; | |
859 | __u64 len = <len_of_SETUP_E820_EXT_data>; | |
860 | __u64 addr = <addr_of_SETUP_E820_EXT_data>; | |
861 | } | |
b3c72fc9 | 862 | } |
b3c72fc9 DK |
863 | |
864 | .. note:: | |
865 | SETUP_INDIRECT | SETUP_NONE objects cannot be properly distinguished | |
866 | from SETUP_INDIRECT itself. So, this kind of objects cannot be provided | |
867 | by the bootloaders. | |
868 | ||
f1f238a9 | 869 | ============ ============ |
d297366b PA |
870 | Field name: pref_address |
871 | Type: read (reloc) | |
872 | Offset/size: 0x258/8 | |
873 | Protocol: 2.10+ | |
f1f238a9 | 874 | ============ ============ |
d297366b PA |
875 | |
876 | This field, if nonzero, represents a preferred load address for the | |
877 | kernel. A relocating bootloader should attempt to load at this | |
878 | address if possible. | |
879 | ||
880 | A non-relocatable kernel will unconditionally move itself and to run | |
881 | at this address. | |
882 | ||
f1f238a9 | 883 | ============ ======= |
d297366b PA |
884 | Field name: init_size |
885 | Type: read | |
11e48fee | 886 | Offset/size: 0x260/4 |
f1f238a9 | 887 | ============ ======= |
d297366b PA |
888 | |
889 | This field indicates the amount of linear contiguous memory starting | |
890 | at the kernel runtime start address that the kernel needs before it | |
891 | is capable of examining its memory map. This is not the same thing | |
892 | as the total amount of memory the kernel needs to boot, but it can | |
893 | be used by a relocating boot loader to help select a safe load | |
894 | address for the kernel. | |
895 | ||
f1f238a9 | 896 | The kernel runtime start address is determined by the following algorithm:: |
d297366b | 897 | |
f1f238a9 | 898 | if (relocatable_kernel) |
d297366b | 899 | runtime_start = align_up(load_address, kernel_alignment) |
f1f238a9 | 900 | else |
d297366b PA |
901 | runtime_start = pref_address |
902 | ||
f1f238a9 | 903 | ============ =============== |
9ca8f72a MF |
904 | Field name: handover_offset |
905 | Type: read | |
906 | Offset/size: 0x264/4 | |
f1f238a9 | 907 | ============ =============== |
9ca8f72a MF |
908 | |
909 | This field is the offset from the beginning of the kernel image to | |
910 | the EFI handover protocol entry point. Boot loaders using the EFI | |
911 | handover protocol to boot the kernel should jump to this offset. | |
912 | ||
913 | See EFI HANDOVER PROTOCOL below for more details. | |
914 | ||
2c33c27f DK |
915 | ============ ================== |
916 | Field name: kernel_info_offset | |
917 | Type: read | |
918 | Offset/size: 0x268/4 | |
919 | Protocol: 2.15+ | |
920 | ============ ================== | |
921 | ||
922 | This field is the offset from the beginning of the kernel image to the | |
923 | kernel_info. The kernel_info structure is embedded in the Linux image | |
924 | in the uncompressed protected mode region. | |
925 | ||
926 | ||
927 | The kernel_info | |
928 | =============== | |
929 | ||
930 | The relationships between the headers are analogous to the various data | |
931 | sections: | |
932 | ||
933 | setup_header = .data | |
934 | boot_params/setup_data = .bss | |
935 | ||
936 | What is missing from the above list? That's right: | |
937 | ||
938 | kernel_info = .rodata | |
939 | ||
940 | We have been (ab)using .data for things that could go into .rodata or .bss for | |
941 | a long time, for lack of alternatives and -- especially early on -- inertia. | |
942 | Also, the BIOS stub is responsible for creating boot_params, so it isn't | |
943 | available to a BIOS-based loader (setup_data is, though). | |
944 | ||
945 | setup_header is permanently limited to 144 bytes due to the reach of the | |
946 | 2-byte jump field, which doubles as a length field for the structure, combined | |
947 | with the size of the "hole" in struct boot_params that a protected-mode loader | |
948 | or the BIOS stub has to copy it into. It is currently 119 bytes long, which | |
949 | leaves us with 25 very precious bytes. This isn't something that can be fixed | |
950 | without revising the boot protocol entirely, breaking backwards compatibility. | |
951 | ||
952 | boot_params proper is limited to 4096 bytes, but can be arbitrarily extended | |
953 | by adding setup_data entries. It cannot be used to communicate properties of | |
954 | the kernel image, because it is .bss and has no image-provided content. | |
955 | ||
956 | kernel_info solves this by providing an extensible place for information about | |
957 | the kernel image. It is readonly, because the kernel cannot rely on a | |
958 | bootloader copying its contents anywhere, but that is OK; if it becomes | |
959 | necessary it can still contain data items that an enabled bootloader would be | |
960 | expected to copy into a setup_data chunk. | |
961 | ||
962 | All kernel_info data should be part of this structure. Fixed size data have to | |
963 | be put before kernel_info_var_len_data label. Variable size data have to be put | |
964 | after kernel_info_var_len_data label. Each chunk of variable size data has to | |
e43630ed | 965 | be prefixed with header/magic and its size, e.g.:: |
2c33c27f DK |
966 | |
967 | kernel_info: | |
968 | .ascii "LToP" /* Header, Linux top (structure). */ | |
969 | .long kernel_info_var_len_data - kernel_info | |
970 | .long kernel_info_end - kernel_info | |
971 | .long 0x01234567 /* Some fixed size data for the bootloaders. */ | |
972 | kernel_info_var_len_data: | |
973 | example_struct: /* Some variable size data for the bootloaders. */ | |
974 | .ascii "0123" /* Header/Magic. */ | |
975 | .long example_struct_end - example_struct | |
976 | .ascii "Struct" | |
977 | .long 0x89012345 | |
978 | example_struct_end: | |
979 | example_strings: /* Some variable size data for the bootloaders. */ | |
980 | .ascii "ABCD" /* Header/Magic. */ | |
981 | .long example_strings_end - example_strings | |
982 | .asciz "String_0" | |
983 | .asciz "String_1" | |
984 | example_strings_end: | |
985 | kernel_info_end: | |
986 | ||
987 | This way the kernel_info is self-contained blob. | |
988 | ||
989 | .. note:: | |
990 | Each variable size data header/magic can be any 4-character string, | |
991 | without \0 at the end of the string, which does not collide with | |
992 | existing variable length data headers/magics. | |
993 | ||
994 | ||
995 | Details of the kernel_info Fields | |
996 | ================================= | |
997 | ||
998 | ============ ======== | |
999 | Field name: header | |
1000 | Offset/size: 0x0000/4 | |
1001 | ============ ======== | |
1002 | ||
1003 | Contains the magic number "LToP" (0x506f544c). | |
1004 | ||
1005 | ============ ======== | |
1006 | Field name: size | |
1007 | Offset/size: 0x0004/4 | |
1008 | ============ ======== | |
1009 | ||
1010 | This field contains the size of the kernel_info including kernel_info.header. | |
1011 | It does not count kernel_info.kernel_info_var_len_data size. This field should be | |
1012 | used by the bootloaders to detect supported fixed size fields in the kernel_info | |
1013 | and beginning of kernel_info.kernel_info_var_len_data. | |
1014 | ||
1015 | ============ ======== | |
1016 | Field name: size_total | |
1017 | Offset/size: 0x0008/4 | |
1018 | ============ ======== | |
1019 | ||
1020 | This field contains the size of the kernel_info including kernel_info.header | |
1021 | and kernel_info.kernel_info_var_len_data. | |
1022 | ||
00cd1c15 DK |
1023 | ============ ============== |
1024 | Field name: setup_type_max | |
1025 | Offset/size: 0x000c/4 | |
1026 | ============ ============== | |
1027 | ||
b3c72fc9 | 1028 | This field contains maximal allowed type for setup_data and setup_indirect structs. |
00cd1c15 | 1029 | |
4039feb5 | 1030 | |
f1f238a9 CD |
1031 | The Image Checksum |
1032 | ================== | |
7d6e737c IC |
1033 | |
1034 | From boot protocol version 2.08 onwards the CRC-32 is calculated over | |
1035 | the entire file using the characteristic polynomial 0x04C11DB7 and an | |
1036 | initial remainder of 0xffffffff. The checksum is appended to the | |
1037 | file; therefore the CRC of the file up to the limit specified in the | |
1038 | syssize field of the header is always 0. | |
1039 | ||
4039feb5 | 1040 | |
f1f238a9 CD |
1041 | The Kernel Command Line |
1042 | ======================= | |
1da177e4 LT |
1043 | |
1044 | The kernel command line has become an important way for the boot | |
1045 | loader to communicate with the kernel. Some of its options are also | |
1046 | relevant to the boot loader itself, see "special command line options" | |
1047 | below. | |
1048 | ||
8f9aeca7 BW |
1049 | The kernel command line is a null-terminated string. The maximum |
1050 | length can be retrieved from the field cmdline_size. Before protocol | |
1051 | version 2.06, the maximum was 255 characters. A string that is too | |
1052 | long will be automatically truncated by the kernel. | |
1da177e4 LT |
1053 | |
1054 | If the boot protocol version is 2.02 or later, the address of the | |
1055 | kernel command line is given by the header field cmd_line_ptr (see | |
f8eeaaf4 PA |
1056 | above.) This address can be anywhere between the end of the setup |
1057 | heap and 0xA0000. | |
1da177e4 LT |
1058 | |
1059 | If the protocol version is *not* 2.02 or higher, the kernel | |
1060 | command line is entered using the following protocol: | |
1061 | ||
f1f238a9 CD |
1062 | - At offset 0x0020 (word), "cmd_line_magic", enter the magic |
1063 | number 0xA33F. | |
1064 | ||
1065 | - At offset 0x0022 (word), "cmd_line_offset", enter the offset | |
1066 | of the kernel command line (relative to the start of the | |
1067 | real-mode kernel). | |
1da177e4 | 1068 | |
f1f238a9 CD |
1069 | - The kernel command line *must* be within the memory region |
1070 | covered by setup_move_size, so you may need to adjust this | |
1071 | field. | |
1da177e4 LT |
1072 | |
1073 | ||
f1f238a9 CD |
1074 | Memory Layout of The Real-Mode Code |
1075 | =================================== | |
de372ecd PA |
1076 | |
1077 | The real-mode code requires a stack/heap to be set up, as well as | |
1078 | memory allocated for the kernel command line. This needs to be done | |
1079 | in the real-mode accessible memory in bottom megabyte. | |
1080 | ||
1081 | It should be noted that modern machines often have a sizable Extended | |
1082 | BIOS Data Area (EBDA). As a result, it is advisable to use as little | |
1083 | of the low megabyte as possible. | |
1084 | ||
1085 | Unfortunately, under the following circumstances the 0x90000 memory | |
1086 | segment has to be used: | |
1087 | ||
1088 | - When loading a zImage kernel ((loadflags & 0x01) == 0). | |
1089 | - When loading a 2.01 or earlier boot protocol kernel. | |
1090 | ||
f1f238a9 CD |
1091 | .. note:: |
1092 | For the 2.00 and 2.01 boot protocols, the real-mode code | |
1093 | can be loaded at another address, but it is internally | |
1094 | relocated to 0x90000. For the "old" protocol, the | |
1095 | real-mode code must be loaded at 0x90000. | |
de372ecd PA |
1096 | |
1097 | When loading at 0x90000, avoid using memory above 0x9a000. | |
1098 | ||
1099 | For boot protocol 2.02 or higher, the command line does not have to be | |
1100 | located in the same 64K segment as the real-mode setup code; it is | |
1101 | thus permitted to give the stack/heap the full 64K segment and locate | |
1102 | the command line above it. | |
1103 | ||
1104 | The kernel command line should not be located below the real-mode | |
1105 | code, nor should it be located in high memory. | |
1106 | ||
1107 | ||
f1f238a9 CD |
1108 | Sample Boot Configuartion |
1109 | ========================= | |
1da177e4 LT |
1110 | |
1111 | As a sample configuration, assume the following layout of the real | |
f1f238a9 | 1112 | mode segment. |
de372ecd PA |
1113 | |
1114 | When loading below 0x90000, use the entire segment: | |
1115 | ||
f1f238a9 | 1116 | ============= =================== |
de372ecd PA |
1117 | 0x0000-0x7fff Real mode kernel |
1118 | 0x8000-0xdfff Stack and heap | |
1119 | 0xe000-0xffff Kernel command line | |
f1f238a9 | 1120 | ============= =================== |
1da177e4 | 1121 | |
de372ecd PA |
1122 | When loading at 0x90000 OR the protocol version is 2.01 or earlier: |
1123 | ||
f1f238a9 | 1124 | ============= =================== |
de372ecd PA |
1125 | 0x0000-0x7fff Real mode kernel |
1126 | 0x8000-0x97ff Stack and heap | |
1127 | 0x9800-0x9fff Kernel command line | |
f1f238a9 | 1128 | ============= =================== |
1da177e4 | 1129 | |
f1f238a9 | 1130 | Such a boot loader should enter the following fields in the header:: |
1da177e4 LT |
1131 | |
1132 | unsigned long base_ptr; /* base address for real-mode segment */ | |
1133 | ||
1134 | if ( setup_sects == 0 ) { | |
1135 | setup_sects = 4; | |
1136 | } | |
1137 | ||
1138 | if ( protocol >= 0x0200 ) { | |
1139 | type_of_loader = <type code>; | |
1140 | if ( loading_initrd ) { | |
1141 | ramdisk_image = <initrd_address>; | |
1142 | ramdisk_size = <initrd_size>; | |
1143 | } | |
de372ecd PA |
1144 | |
1145 | if ( protocol >= 0x0202 && loadflags & 0x01 ) | |
1146 | heap_end = 0xe000; | |
1147 | else | |
1148 | heap_end = 0x9800; | |
1149 | ||
1da177e4 | 1150 | if ( protocol >= 0x0201 ) { |
de372ecd | 1151 | heap_end_ptr = heap_end - 0x200; |
1da177e4 LT |
1152 | loadflags |= 0x80; /* CAN_USE_HEAP */ |
1153 | } | |
de372ecd | 1154 | |
1da177e4 | 1155 | if ( protocol >= 0x0202 ) { |
de372ecd PA |
1156 | cmd_line_ptr = base_ptr + heap_end; |
1157 | strcpy(cmd_line_ptr, cmdline); | |
1da177e4 LT |
1158 | } else { |
1159 | cmd_line_magic = 0xA33F; | |
de372ecd PA |
1160 | cmd_line_offset = heap_end; |
1161 | setup_move_size = heap_end + strlen(cmdline)+1; | |
1162 | strcpy(base_ptr+cmd_line_offset, cmdline); | |
1da177e4 LT |
1163 | } |
1164 | } else { | |
1165 | /* Very old kernel */ | |
1166 | ||
de372ecd PA |
1167 | heap_end = 0x9800; |
1168 | ||
1da177e4 | 1169 | cmd_line_magic = 0xA33F; |
de372ecd | 1170 | cmd_line_offset = heap_end; |
1da177e4 LT |
1171 | |
1172 | /* A very old kernel MUST have its real-mode code | |
1173 | loaded at 0x90000 */ | |
1174 | ||
1175 | if ( base_ptr != 0x90000 ) { | |
1176 | /* Copy the real-mode kernel */ | |
1177 | memcpy(0x90000, base_ptr, (setup_sects+1)*512); | |
1da177e4 LT |
1178 | base_ptr = 0x90000; /* Relocated */ |
1179 | } | |
1180 | ||
de372ecd PA |
1181 | strcpy(0x90000+cmd_line_offset, cmdline); |
1182 | ||
1da177e4 LT |
1183 | /* It is recommended to clear memory up to the 32K mark */ |
1184 | memset(0x90000 + (setup_sects+1)*512, 0, | |
1185 | (64-(setup_sects+1))*512); | |
1186 | } | |
1187 | ||
1188 | ||
f1f238a9 CD |
1189 | Loading The Rest of The Kernel |
1190 | ============================== | |
1da177e4 | 1191 | |
f8eeaaf4 PA |
1192 | The 32-bit (non-real-mode) kernel starts at offset (setup_sects+1)*512 |
1193 | in the kernel file (again, if setup_sects == 0 the real value is 4.) | |
1194 | It should be loaded at address 0x10000 for Image/zImage kernels and | |
1da177e4 LT |
1195 | 0x100000 for bzImage kernels. |
1196 | ||
1197 | The kernel is a bzImage kernel if the protocol >= 2.00 and the 0x01 | |
f1f238a9 | 1198 | bit (LOAD_HIGH) in the loadflags field is set:: |
1da177e4 LT |
1199 | |
1200 | is_bzImage = (protocol >= 0x0200) && (loadflags & 0x01); | |
1201 | load_address = is_bzImage ? 0x100000 : 0x10000; | |
1202 | ||
1203 | Note that Image/zImage kernels can be up to 512K in size, and thus use | |
1204 | the entire 0x10000-0x90000 range of memory. This means it is pretty | |
1205 | much a requirement for these kernels to load the real-mode part at | |
1206 | 0x90000. bzImage kernels allow much more flexibility. | |
1207 | ||
f1f238a9 CD |
1208 | Special Command Line Options |
1209 | ============================ | |
1da177e4 LT |
1210 | |
1211 | If the command line provided by the boot loader is entered by the | |
1212 | user, the user may expect the following command line options to work. | |
1213 | They should normally not be deleted from the kernel command line even | |
1214 | though not all of them are actually meaningful to the kernel. Boot | |
1215 | loader authors who need additional command line options for the boot | |
1216 | loader itself should get them registered in | |
8c27ceff | 1217 | Documentation/admin-guide/kernel-parameters.rst to make sure they will not |
1da177e4 LT |
1218 | conflict with actual kernel options now or in the future. |
1219 | ||
1220 | vga=<mode> | |
1221 | <mode> here is either an integer (in C notation, either | |
1222 | decimal, octal, or hexadecimal) or one of the strings | |
1223 | "normal" (meaning 0xFFFF), "ext" (meaning 0xFFFE) or "ask" | |
1224 | (meaning 0xFFFD). This value should be entered into the | |
1225 | vid_mode field, as it is used by the kernel before the command | |
1226 | line is parsed. | |
1227 | ||
1228 | mem=<size> | |
de372ecd PA |
1229 | <size> is an integer in C notation optionally followed by |
1230 | (case insensitive) K, M, G, T, P or E (meaning << 10, << 20, | |
1231 | << 30, << 40, << 50 or << 60). This specifies the end of | |
1232 | memory to the kernel. This affects the possible placement of | |
1233 | an initrd, since an initrd should be placed near end of | |
1da177e4 LT |
1234 | memory. Note that this is an option to *both* the kernel and |
1235 | the bootloader! | |
1236 | ||
1237 | initrd=<file> | |
1238 | An initrd should be loaded. The meaning of <file> is | |
1239 | obviously bootloader-dependent, and some boot loaders | |
1240 | (e.g. LILO) do not have such a command. | |
1241 | ||
1242 | In addition, some boot loaders add the following options to the | |
1243 | user-specified command line: | |
1244 | ||
1245 | BOOT_IMAGE=<file> | |
1246 | The boot image which was loaded. Again, the meaning of <file> | |
1247 | is obviously bootloader-dependent. | |
1248 | ||
1249 | auto | |
1250 | The kernel was booted without explicit user intervention. | |
1251 | ||
1252 | If these options are added by the boot loader, it is highly | |
1253 | recommended that they are located *first*, before the user-specified | |
1254 | or configuration-specified command line. Otherwise, "init=/bin/sh" | |
1255 | gets confused by the "auto" option. | |
1256 | ||
1257 | ||
f1f238a9 CD |
1258 | Running the Kernel |
1259 | ================== | |
1da177e4 LT |
1260 | |
1261 | The kernel is started by jumping to the kernel entry point, which is | |
1262 | located at *segment* offset 0x20 from the start of the real mode | |
1263 | kernel. This means that if you loaded your real-mode kernel code at | |
1264 | 0x90000, the kernel entry point is 9020:0000. | |
1265 | ||
1266 | At entry, ds = es = ss should point to the start of the real-mode | |
1267 | kernel code (0x9000 if the code is loaded at 0x90000), sp should be | |
1268 | set up properly, normally pointing to the top of the heap, and | |
1269 | interrupts should be disabled. Furthermore, to guard against bugs in | |
1270 | the kernel, it is recommended that the boot loader sets fs = gs = ds = | |
1271 | es = ss. | |
1272 | ||
f1f238a9 | 1273 | In our example from above, we would do:: |
1da177e4 LT |
1274 | |
1275 | /* Note: in the case of the "old" kernel protocol, base_ptr must | |
1276 | be == 0x90000 at this point; see the previous sample code */ | |
1277 | ||
1278 | seg = base_ptr >> 4; | |
1279 | ||
1280 | cli(); /* Enter with interrupts disabled! */ | |
1281 | ||
1282 | /* Set up the real-mode kernel stack */ | |
1283 | _SS = seg; | |
de372ecd | 1284 | _SP = heap_end; |
1da177e4 LT |
1285 | |
1286 | _DS = _ES = _FS = _GS = seg; | |
1287 | jmp_far(seg+0x20, 0); /* Run the kernel */ | |
1288 | ||
1289 | If your boot sector accesses a floppy drive, it is recommended to | |
1290 | switch off the floppy motor before running the kernel, since the | |
1291 | kernel boot leaves interrupts off and thus the motor will not be | |
1292 | switched off, especially if the loaded kernel has the floppy driver as | |
1293 | a demand-loaded module! | |
1294 | ||
1295 | ||
f1f238a9 CD |
1296 | Advanced Boot Loader Hooks |
1297 | ========================== | |
1da177e4 LT |
1298 | |
1299 | If the boot loader runs in a particularly hostile environment (such as | |
1300 | LOADLIN, which runs under DOS) it may be impossible to follow the | |
1301 | standard memory location requirements. Such a boot loader may use the | |
1302 | following hooks that, if set, are invoked by the kernel at the | |
1303 | appropriate time. The use of these hooks should probably be | |
1304 | considered an absolutely last resort! | |
1305 | ||
1306 | IMPORTANT: All the hooks are required to preserve %esp, %ebp, %esi and | |
1307 | %edi across invocation. | |
1308 | ||
1309 | realmode_swtch: | |
1310 | A 16-bit real mode far subroutine invoked immediately before | |
1311 | entering protected mode. The default routine disables NMI, so | |
1312 | your routine should probably do so, too. | |
1313 | ||
1314 | code32_start: | |
1315 | A 32-bit flat-mode routine *jumped* to immediately after the | |
1316 | transition to protected mode, but before the kernel is | |
de372ecd PA |
1317 | uncompressed. No segments, except CS, are guaranteed to be |
1318 | set up (current kernels do, but older ones do not); you should | |
1319 | set them up to BOOT_DS (0x18) yourself. | |
1da177e4 LT |
1320 | |
1321 | After completing your hook, you should jump to the address | |
db2668fd PA |
1322 | that was in this field before your boot loader overwrote it |
1323 | (relocated, if appropriate.) | |
aa69432a HY |
1324 | |
1325 | ||
f1f238a9 CD |
1326 | 32-bit Boot Protocol |
1327 | ==================== | |
aa69432a HY |
1328 | |
1329 | For machine with some new BIOS other than legacy BIOS, such as EFI, | |
1330 | LinuxBIOS, etc, and kexec, the 16-bit real mode setup code in kernel | |
1331 | based on legacy BIOS can not be used, so a 32-bit boot protocol needs | |
1332 | to be defined. | |
1333 | ||
1334 | In 32-bit boot protocol, the first step in loading a Linux kernel | |
1335 | should be to setup the boot parameters (struct boot_params, | |
1336 | traditionally known as "zero page"). The memory for struct boot_params | |
1337 | should be allocated and initialized to all zero. Then the setup header | |
1338 | from offset 0x01f1 of kernel image on should be loaded into struct | |
1339 | boot_params and examined. The end of setup header can be calculated as | |
f1f238a9 | 1340 | follow:: |
aa69432a HY |
1341 | |
1342 | 0x0202 + byte value at offset 0x0201 | |
1343 | ||
1344 | In addition to read/modify/write the setup header of the struct | |
1345 | boot_params as that of 16-bit boot protocol, the boot loader should | |
0c768983 | 1346 | also fill the additional fields of the struct boot_params as |
ff61f079 | 1347 | described in chapter Documentation/arch/x86/zero-page.rst. |
aa69432a | 1348 | |
c6039f4a | 1349 | After setting up the struct boot_params, the boot loader can load the |
aa69432a HY |
1350 | 32/64-bit kernel in the same way as that of 16-bit boot protocol. |
1351 | ||
1352 | In 32-bit boot protocol, the kernel is started by jumping to the | |
1353 | 32-bit kernel entry point, which is the start address of loaded | |
1354 | 32/64-bit kernel. | |
1355 | ||
1356 | At entry, the CPU must be in 32-bit protected mode with paging | |
1357 | disabled; a GDT must be loaded with the descriptors for selectors | |
1358 | __BOOT_CS(0x10) and __BOOT_DS(0x18); both descriptors must be 4G flat | |
c6039f4a | 1359 | segment; __BOOT_CS must have execute/read permission, and __BOOT_DS |
aa69432a HY |
1360 | must have read/write permission; CS must be __BOOT_CS and DS, ES, SS |
1361 | must be __BOOT_DS; interrupt must be disabled; %esi must hold the base | |
1362 | address of the struct boot_params; %ebp, %edi and %ebx must be zero. | |
9ca8f72a | 1363 | |
f1f238a9 CD |
1364 | 64-bit Boot Protocol |
1365 | ==================== | |
8ee2f2df YL |
1366 | |
1367 | For machine with 64bit cpus and 64bit kernel, we could use 64bit bootloader | |
1368 | and we need a 64-bit boot protocol. | |
1369 | ||
1370 | In 64-bit boot protocol, the first step in loading a Linux kernel | |
1371 | should be to setup the boot parameters (struct boot_params, | |
1372 | traditionally known as "zero page"). The memory for struct boot_params | |
1373 | could be allocated anywhere (even above 4G) and initialized to all zero. | |
1374 | Then, the setup header at offset 0x01f1 of kernel image on should be | |
1375 | loaded into struct boot_params and examined. The end of setup header | |
f1f238a9 | 1376 | can be calculated as follows:: |
8ee2f2df YL |
1377 | |
1378 | 0x0202 + byte value at offset 0x0201 | |
1379 | ||
1380 | In addition to read/modify/write the setup header of the struct | |
1381 | boot_params as that of 16-bit boot protocol, the boot loader should | |
1382 | also fill the additional fields of the struct boot_params as described | |
ff61f079 | 1383 | in chapter Documentation/arch/x86/zero-page.rst. |
8ee2f2df YL |
1384 | |
1385 | After setting up the struct boot_params, the boot loader can load | |
1386 | 64-bit kernel in the same way as that of 16-bit boot protocol, but | |
1387 | kernel could be loaded above 4G. | |
1388 | ||
1389 | In 64-bit boot protocol, the kernel is started by jumping to the | |
1390 | 64-bit kernel entry point, which is the start address of loaded | |
1391 | 64-bit kernel plus 0x200. | |
1392 | ||
1393 | At entry, the CPU must be in 64-bit mode with paging enabled. | |
1394 | The range with setup_header.init_size from start address of loaded | |
1395 | kernel and zero page and command line buffer get ident mapping; | |
1396 | a GDT must be loaded with the descriptors for selectors | |
1397 | __BOOT_CS(0x10) and __BOOT_DS(0x18); both descriptors must be 4G flat | |
1398 | segment; __BOOT_CS must have execute/read permission, and __BOOT_DS | |
1399 | must have read/write permission; CS must be __BOOT_CS and DS, ES, SS | |
1400 | must be __BOOT_DS; interrupt must be disabled; %rsi must hold the base | |
1401 | address of the struct boot_params. | |
1402 | ||
8b84769a AB |
1403 | EFI Handover Protocol (deprecated) |
1404 | ================================== | |
9ca8f72a MF |
1405 | |
1406 | This protocol allows boot loaders to defer initialisation to the EFI | |
1407 | boot stub. The boot loader is required to load the kernel/initrd(s) | |
1408 | from the boot media and jump to the EFI handover protocol entry point | |
1409 | which is hdr->handover_offset bytes from the beginning of | |
1410 | startup_{32,64}. | |
1411 | ||
8b84769a AB |
1412 | The boot loader MUST respect the kernel's PE/COFF metadata when it comes |
1413 | to section alignment, the memory footprint of the executable image beyond | |
1414 | the size of the file itself, and any other aspect of the PE/COFF header | |
1415 | that may affect correct operation of the image as a PE/COFF binary in the | |
1416 | execution context provided by the EFI firmware. | |
1417 | ||
f1f238a9 | 1418 | The function prototype for the handover entry point looks like this:: |
9ca8f72a MF |
1419 | |
1420 | efi_main(void *handle, efi_system_table_t *table, struct boot_params *bp) | |
1421 | ||
1422 | 'handle' is the EFI image handle passed to the boot loader by the EFI | |
1423 | firmware, 'table' is the EFI system table - these are the first two | |
1424 | arguments of the "handoff state" as described in section 2.3 of the | |
1425 | UEFI specification. 'bp' is the boot loader-allocated boot params. | |
1426 | ||
f1f238a9 | 1427 | The boot loader *must* fill out the following fields in bp:: |
9ca8f72a | 1428 | |
f1f238a9 CD |
1429 | - hdr.cmd_line_ptr |
1430 | - hdr.ramdisk_image (if applicable) | |
1431 | - hdr.ramdisk_size (if applicable) | |
9ca8f72a MF |
1432 | |
1433 | All other fields should be zero. | |
8b84769a AB |
1434 | |
1435 | NOTE: The EFI Handover Protocol is deprecated in favour of the ordinary PE/COFF | |
1436 | entry point, combined with the LINUX_EFI_INITRD_MEDIA_GUID based initrd | |
1437 | loading protocol (refer to [0] for an example of the bootloader side of | |
1438 | this), which removes the need for any knowledge on the part of the EFI | |
1439 | bootloader regarding the internal representation of boot_params or any | |
1440 | requirements/limitations regarding the placement of the command line | |
1441 | and ramdisk in memory, or the placement of the kernel image itself. | |
1442 | ||
1443 | [0] https://github.com/u-boot/u-boot/commit/ec80b4735a593961fe701cc3a5d717d4739b0fd0 |