diff options
author | H. Peter Anvin <hpa@zytor.com> | 2007-05-17 18:50:47 -0400 |
---|---|---|
committer | Linus Torvalds <torvalds@woody.linux-foundation.org> | 2007-05-18 23:52:26 -0400 |
commit | dec04cff500d4e543c55ab1beb0af85d8ed7e6bd (patch) | |
tree | 341736cf4a4fa51a8f5126e8011f8f7d6553dd53 /Documentation | |
parent | 66123549dbd75c67509c73b9d94bf7a9d2f4b286 (diff) |
Further update of the i386 boot documentation
A number of items in the i386 boot documentation have been either
vague, outdated or hard to read. This text revision adds several more
examples, including a memory map for a modern kernel load. It also
adds a field-by-field detailed description of the setup header, and a
bootloader ID for Qemu.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'Documentation')
-rw-r--r-- | Documentation/i386/boot.txt | 385 |
1 files changed, 303 insertions, 82 deletions
diff --git a/Documentation/i386/boot.txt b/Documentation/i386/boot.txt index d01b7a2a0f2e..66fa67fec2a7 100644 --- a/Documentation/i386/boot.txt +++ b/Documentation/i386/boot.txt | |||
@@ -2,7 +2,7 @@ | |||
2 | ---------------------------- | 2 | ---------------------------- |
3 | 3 | ||
4 | H. Peter Anvin <hpa@zytor.com> | 4 | H. Peter Anvin <hpa@zytor.com> |
5 | Last update 2007-05-07 | 5 | Last update 2007-05-16 |
6 | 6 | ||
7 | On the i386 platform, the Linux kernel uses a rather complicated boot | 7 | On the i386 platform, the Linux kernel uses a rather complicated boot |
8 | convention. This has evolved partially due to historical aspects, as | 8 | convention. This has evolved partially due to historical aspects, as |
@@ -52,7 +52,8 @@ zImage kernels, typically looks like: | |||
52 | 0A0000 +------------------------+ | 52 | 0A0000 +------------------------+ |
53 | | Reserved for BIOS | Do not use. Reserved for BIOS EBDA. | 53 | | Reserved for BIOS | Do not use. Reserved for BIOS EBDA. |
54 | 09A000 +------------------------+ | 54 | 09A000 +------------------------+ |
55 | | Stack/heap/cmdline | For use by the kernel real-mode code. | 55 | | Command line | |
56 | | Stack/heap | For use by the kernel real-mode code. | ||
56 | 098000 +------------------------+ | 57 | 098000 +------------------------+ |
57 | | Kernel setup | The kernel real-mode code. | 58 | | Kernel setup | The kernel real-mode code. |
58 | 090200 +------------------------+ | 59 | 090200 +------------------------+ |
@@ -73,10 +74,9 @@ zImage kernels, typically looks like: | |||
73 | When using bzImage, the protected-mode kernel was relocated to | 74 | When using bzImage, the protected-mode kernel was relocated to |
74 | 0x100000 ("high memory"), and the kernel real-mode block (boot sector, | 75 | 0x100000 ("high memory"), and the kernel real-mode block (boot sector, |
75 | setup, and stack/heap) was made relocatable to any address between | 76 | setup, and stack/heap) was made relocatable to any address between |
76 | 0x10000 and end of low memory. Unfortunately, in protocols 2.00 and | 77 | 0x10000 and end of low memory. Unfortunately, in protocols 2.00 and |
77 | 2.01 the command line is still required to live in the 0x9XXXX memory | 78 | 2.01 the 0x90000+ memory range is still used internally by the kernel; |
78 | range, and that memory range is still overwritten by the early kernel. | 79 | the 2.02 protocol resolves that problem. |
79 | The 2.02 protocol resolves that problem. | ||
80 | 80 | ||
81 | It is desirable to keep the "memory ceiling" -- the highest point in | 81 | It is desirable to keep the "memory ceiling" -- the highest point in |
82 | low memory touched by the boot loader -- as low as possible, since | 82 | low memory touched by the boot loader -- as low as possible, since |
@@ -93,6 +93,35 @@ zImage or old bzImage kernels, which need data written into the | |||
93 | 0x90000 segment, the boot loader should make sure not to use memory | 93 | 0x90000 segment, the boot loader should make sure not to use memory |
94 | above the 0x9A000 point; too many BIOSes will break above that point. | 94 | above the 0x9A000 point; too many BIOSes will break above that point. |
95 | 95 | ||
96 | For a modern bzImage kernel with boot protocol version >= 2.02, a | ||
97 | memory layout like the following is suggested: | ||
98 | |||
99 | ~ ~ | ||
100 | | Protected-mode kernel | | ||
101 | 100000 +------------------------+ | ||
102 | | I/O memory hole | | ||
103 | 0A0000 +------------------------+ | ||
104 | | Reserved for BIOS | Leave as much as possible unused | ||
105 | ~ ~ | ||
106 | | Command line | (Can also be below the X+10000 mark) | ||
107 | X+10000 +------------------------+ | ||
108 | | Stack/heap | For use by the kernel real-mode code. | ||
109 | X+08000 +------------------------+ | ||
110 | | Kernel setup | The kernel real-mode code. | ||
111 | | Kernel boot sector | The kernel legacy boot sector. | ||
112 | X +------------------------+ | ||
113 | | Boot loader | <- Boot sector entry point 0000:7C00 | ||
114 | 001000 +------------------------+ | ||
115 | | Reserved for MBR/BIOS | | ||
116 | 000800 +------------------------+ | ||
117 | | Typically used by MBR | | ||
118 | 000600 +------------------------+ | ||
119 | | BIOS use only | | ||
120 | 000000 +------------------------+ | ||
121 | |||
122 | ... where the address X is as low as the design of the boot loader | ||
123 | permits. | ||
124 | |||
96 | 125 | ||
97 | **** THE REAL-MODE KERNEL HEADER | 126 | **** THE REAL-MODE KERNEL HEADER |
98 | 127 | ||
@@ -160,29 +189,136 @@ e.g. protocol version 2.01 will contain 0x0201 in this field. When | |||
160 | setting fields in the header, you must make sure only to set fields | 189 | setting fields in the header, you must make sure only to set fields |
161 | supported by the protocol version in use. | 190 | supported by the protocol version in use. |
162 | 191 | ||
163 | The "kernel_version" field, if set to a nonzero value, contains a | 192 | |
164 | pointer to a null-terminated human-readable kernel version number | 193 | **** DETAILS OF HEADER FIELDS |
165 | string, less 0x200. This can be used to display the kernel version to | 194 | |
166 | the user. This value should be less than (0x200*setup_sects). For | 195 | For each field, some are information from the kernel to the bootloader |
167 | example, if this value is set to 0x1c00, the kernel version number | 196 | ("read"), some are expected to be filled out by the bootloader |
168 | string can be found at offset 0x1e00 in the kernel file. This is a | 197 | ("write"), and some are expected to be read and modified by the |
169 | valid value if and only if the "setup_sects" field contains the value | 198 | bootloader ("modify"). |
170 | 14 or higher. | 199 | |
171 | 200 | All general purpose boot loaders should write the fields marked | |
172 | Most boot loaders will simply load the kernel at its target address | 201 | (obligatory). Boot loaders who want to load the kernel at a |
173 | directly. Such boot loaders do not need to worry about filling in | 202 | nonstandard address should fill in the fields marked (reloc); other |
174 | most of the fields in the header. The following fields should be | 203 | boot loaders can ignore those fields. |
175 | filled out, however: | 204 | |
176 | 205 | Field name: setup_secs | |
177 | vid_mode: | 206 | Type: read |
178 | Please see the section on SPECIAL COMMAND LINE OPTIONS. | 207 | Offset/size: 0x1f1/1 |
179 | 208 | Protocol: ALL | |
180 | type_of_loader: | 209 | |
181 | If your boot loader has an assigned id (see table below), enter | 210 | The size of the setup code in 512-byte sectors. If this field is |
182 | 0xTV here, where T is an identifier for the boot loader and V is | 211 | 0, the real value is 4. The real-mode code consists of the boot |
183 | a version number. Otherwise, enter 0xFF here. | 212 | sector (always one 512-byte sector) plus the setup code. |
184 | 213 | ||
185 | Assigned boot loader ids: | 214 | Field name: root_flags |
215 | Type: modify (optional) | ||
216 | Offset/size: 0x1f2/2 | ||
217 | Protocol: ALL | ||
218 | |||
219 | If this field is nonzero, the root defaults to readonly. The use of | ||
220 | this field is deprecated; use the "ro" or "rw" options on the | ||
221 | command line instead. | ||
222 | |||
223 | Field name: syssize | ||
224 | Type: read | ||
225 | Offset/size: 0x1f4/4 (protocol 2.04+) 0x1f4/2 (protocol ALL) | ||
226 | Protocol: 2.04+ | ||
227 | |||
228 | The size of the protected-mode code in units of 16-byte paragraphs. | ||
229 | For protocol versions older than 2.04 this field is only two bytes | ||
230 | wide, and therefore cannot be trusted for the size of a kernel if | ||
231 | the LOAD_HIGH flag is set. | ||
232 | |||
233 | Field name: ram_size | ||
234 | Type: kernel internal | ||
235 | Offset/size: 0x1f8/2 | ||
236 | Protocol: ALL | ||
237 | |||
238 | This field is obsolete. | ||
239 | |||
240 | Field name: vid_mode | ||
241 | Type: modify (obligatory) | ||
242 | Offset/size: 0x1fa/2 | ||
243 | |||
244 | Please see the section on SPECIAL COMMAND LINE OPTIONS. | ||
245 | |||
246 | Field name: root_dev | ||
247 | Type: modify (optional) | ||
248 | Offset/size: 0x1fc/2 | ||
249 | Protocol: ALL | ||
250 | |||
251 | The default root device device number. The use of this field is | ||
252 | deprecated, use the "root=" option on the command line instead. | ||
253 | |||
254 | Field name: boot_flag | ||
255 | Type: read | ||
256 | Offset/size: 0x1fe/2 | ||
257 | Protocol: ALL | ||
258 | |||
259 | Contains 0xAA55. This is the closest thing old Linux kernels have | ||
260 | to a magic number. | ||
261 | |||
262 | Field name: jump | ||
263 | Type: read | ||
264 | Offset/size: 0x200/2 | ||
265 | Protocol: 2.00+ | ||
266 | |||
267 | Contains an x86 jump instruction, 0xEB followed by a signed offset | ||
268 | relative to byte 0x202. This can be used to determine the size of | ||
269 | the header. | ||
270 | |||
271 | Field name: header | ||
272 | Type: read | ||
273 | Offset/size: 0x202/4 | ||
274 | Protocol: 2.00+ | ||
275 | |||
276 | Contains the magic number "HdrS" (0x53726448). | ||
277 | |||
278 | Field name: version | ||
279 | Type: read | ||
280 | Offset/size: 0x206/2 | ||
281 | Protocol: 2.00+ | ||
282 | |||
283 | Contains the boot protocol version, e.g. 0x0204 for version 2.04. | ||
284 | |||
285 | Field name: readmode_swtch | ||
286 | Type: modify (optional) | ||
287 | Offset/size: 0x208/4 | ||
288 | Protocol: 2.00+ | ||
289 | |||
290 | Boot loader hook (see separate chapter.) | ||
291 | |||
292 | Field name: start_sys | ||
293 | Type: read | ||
294 | Offset/size: 0x20c/4 | ||
295 | Protocol: 2.00+ | ||
296 | |||
297 | The load low segment (0x1000). Obsolete. | ||
298 | |||
299 | Field name: kernel_version | ||
300 | Type: read | ||
301 | Offset/size: 0x20e/2 | ||
302 | Protocol: 2.00+ | ||
303 | |||
304 | If set to a nonzero value, contains a pointer to a NUL-terminated | ||
305 | human-readable kernel version number string, less 0x200. This can | ||
306 | be used to display the kernel version to the user. This value | ||
307 | should be less than (0x200*setup_sects). For example, if this value | ||
308 | is set to 0x1c00, the kernel version number string can be found at | ||
309 | offset 0x1e00 in the kernel file. This is a valid value if and only | ||
310 | if the "setup_sects" field contains the value 14 or higher. | ||
311 | |||
312 | Field name: type_of_loader | ||
313 | Type: write (obligatory) | ||
314 | Offset/size: 0x210/1 | ||
315 | Protocol: 2.00+ | ||
316 | |||
317 | If your boot loader has an assigned id (see table below), enter | ||
318 | 0xTV here, where T is an identifier for the boot loader and V is | ||
319 | a version number. Otherwise, enter 0xFF here. | ||
320 | |||
321 | Assigned boot loader ids: | ||
186 | 0 LILO (0x00 reserved for pre-2.00 bootloader) | 322 | 0 LILO (0x00 reserved for pre-2.00 bootloader) |
187 | 1 Loadlin | 323 | 1 Loadlin |
188 | 2 bootsect-loader (0x20, all other values reserved) | 324 | 2 bootsect-loader (0x20, all other values reserved) |
@@ -193,60 +329,145 @@ filled out, however: | |||
193 | 8 U-BOOT | 329 | 8 U-BOOT |
194 | 9 Xen | 330 | 9 Xen |
195 | A Gujin | 331 | A Gujin |
332 | B Qemu | ||
196 | 333 | ||
197 | Please contact <hpa@zytor.com> if you need a bootloader ID | 334 | Please contact <hpa@zytor.com> if you need a bootloader ID |
198 | value assigned. | 335 | value assigned. |
199 | 336 | ||
200 | loadflags, heap_end_ptr: | 337 | Field name: loadflags |
201 | If the protocol version is 2.01 or higher, enter the | 338 | Type: modify (obligatory) |
202 | offset limit of the setup heap into heap_end_ptr and set the | 339 | Offset/size: 0x211/1 |
203 | 0x80 bit (CAN_USE_HEAP) of loadflags. heap_end_ptr appears to | 340 | Protocol: 2.00+ |
204 | be relative to the start of setup (offset 0x0200). | 341 | |
205 | 342 | This field is a bitmask. | |
206 | setup_move_size: | 343 | |
207 | When using protocol 2.00 or 2.01, if the real mode | 344 | Bit 0 (read): LOADED_HIGH |
208 | kernel is not loaded at 0x90000, it gets moved there later in | 345 | - If 0, the protected-mode code is loaded at 0x10000. |
209 | the loading sequence. Fill in this field if you want | 346 | - If 1, the protected-mode code is loaded at 0x100000. |
210 | additional data (such as the kernel command line) moved in | 347 | |
211 | addition to the real-mode kernel itself. | 348 | Bit 7 (write): CAN_USE_HEAP |
212 | 349 | Set this bit to 1 to indicate that the value entered in the | |
213 | The unit is bytes starting with the beginning of the boot | 350 | heap_end_ptr is valid. If this field is clear, some setup code |
214 | sector. | 351 | functionality will be disabled. |
215 | 352 | ||
216 | ramdisk_image, ramdisk_size: | 353 | Field name: setup_move_size |
217 | If your boot loader has loaded an initial ramdisk (initrd), | 354 | Type: modify (obligatory) |
218 | set ramdisk_image to the 32-bit pointer to the ramdisk data | 355 | Offset/size: 0x212/2 |
219 | and the ramdisk_size to the size of the ramdisk data. | 356 | Protocol: 2.00-2.01 |
220 | 357 | ||
221 | The initrd should typically be located as high in memory as | 358 | When using protocol 2.00 or 2.01, if the real mode kernel is not |
222 | possible, as it may otherwise get overwritten by the early | 359 | loaded at 0x90000, it gets moved there later in the loading |
223 | kernel initialization sequence. However, it must never be | 360 | sequence. Fill in this field if you want additional data (such as |
224 | located above the address specified in the initrd_addr_max | 361 | the kernel command line) moved in addition to the real-mode kernel |
225 | field. The initrd should be at least 4K page aligned. | 362 | itself. |
226 | 363 | ||
227 | cmd_line_ptr: | 364 | The unit is bytes starting with the beginning of the boot sector. |
228 | If the protocol version is 2.02 or higher, this is a 32-bit | 365 | |
229 | pointer to the kernel command line. The kernel command line | 366 | This field is can be ignored when the protocol is 2.02 or higher, or |
230 | can be located anywhere between the end of setup and 0xA0000. | 367 | if the real-mode code is loaded at 0x90000. |
231 | Fill in this field even if your boot loader does not support a | 368 | |
232 | command line, in which case you can point this to an empty | 369 | Field name: code32_start |
233 | string (or better yet, to the string "auto".) If this field | 370 | Type: modify (optional, reloc) |
234 | is left at zero, the kernel will assume that your boot loader | 371 | Offset/size: 0x214/4 |
235 | does not support the 2.02+ protocol. | 372 | Protocol: 2.00+ |
236 | 373 | ||
237 | ramdisk_max: | 374 | The address to jump to in protected mode. This defaults to the load |
238 | The maximum address that may be occupied by the initrd | 375 | address of the kernel, and can be used by the boot loader to |
239 | contents. For boot protocols 2.02 or earlier, this field is | 376 | determine the proper load address. |
240 | not present, and the maximum address is 0x37FFFFFF. (This | 377 | |
241 | address is defined as the address of the highest safe byte, so | 378 | This field can be modified for two purposes: |
242 | if your ramdisk is exactly 131072 bytes long and this field is | 379 | |
243 | 0x37FFFFFF, you can start your ramdisk at 0x37FE0000.) | 380 | 1. as a boot loader hook (see separate chapter.) |
244 | 381 | ||
245 | cmdline_size: | 382 | 2. if a bootloader which does not install a hook loads a |
246 | The maximum size of the command line without the terminating | 383 | relocatable kernel at a nonstandard address it will have to modify |
247 | zero. This means that the command line can contain at most | 384 | this field to point to the load address. |
248 | cmdline_size characters. With protocol version 2.05 and | 385 | |
249 | earlier, the maximum size was 255. | 386 | Field name: ramdisk_image |
387 | Type: write (obligatory) | ||
388 | Offset/size: 0x218/4 | ||
389 | Protocol: 2.00+ | ||
390 | |||
391 | The 32-bit linear address of the initial ramdisk or ramfs. Leave at | ||
392 | zero if there is no initial ramdisk/ramfs. | ||
393 | |||
394 | Field name: ramdisk_size | ||
395 | Type: write (obligatory) | ||
396 | Offset/size: 0x21c/4 | ||
397 | Protocol: 2.00+ | ||
398 | |||
399 | Size of the initial ramdisk or ramfs. Leave at zero if there is no | ||
400 | initial ramdisk/ramfs. | ||
401 | |||
402 | Field name: bootsect_kludge | ||
403 | Type: kernel internal | ||
404 | Offset/size: 0x220/4 | ||
405 | Protocol: 2.00+ | ||
406 | |||
407 | This field is obsolete. | ||
408 | |||
409 | Field name: heap_end_ptr | ||
410 | Type: write (obligatory) | ||
411 | Offset/size: 0x224/2 | ||
412 | Protocol: 2.01+ | ||
413 | |||
414 | Set this field to the offset (from the beginning of the real-mode | ||
415 | code) of the end of the setup stack/heap, minus 0x0200. | ||
416 | |||
417 | Field name: cmd_line_ptr | ||
418 | Type: write (obligatory) | ||
419 | Offset/size: 0x228/4 | ||
420 | Protocol: 2.02+ | ||
421 | |||
422 | Set this field to the linear address of the kernel command line. | ||
423 | The kernel command line can be located anywhere between the end of | ||
424 | the setup heap and 0xA0000; it does not have to be located in the | ||
425 | same 64K segment as the real-mode code itself. | ||
426 | |||
427 | Fill in this field even if your boot loader does not support a | ||
428 | command line, in which case you can point this to an empty string | ||
429 | (or better yet, to the string "auto".) If this field is left at | ||
430 | zero, the kernel will assume that your boot loader does not support | ||
431 | the 2.02+ protocol. | ||
432 | |||
433 | Field name: initrd_addr_max | ||
434 | Type: read | ||
435 | Offset/size: 0x22c/4 | ||
436 | Protocol: 2.03+ | ||
437 | |||
438 | The maximum address that may be occupied by the initial | ||
439 | ramdisk/ramfs contents. For boot protocols 2.02 or earlier, this | ||
440 | field is not present, and the maximum address is 0x37FFFFFF. (This | ||
441 | address is defined as the address of the highest safe byte, so if | ||
442 | your ramdisk is exactly 131072 bytes long and this field is | ||
443 | 0x37FFFFFF, you can start your ramdisk at 0x37FE0000.) | ||
444 | |||
445 | Field name: kernel_alignment | ||
446 | Type: read (reloc) | ||
447 | Offset/size: 0x230/4 | ||
448 | Protocol: 2.05+ | ||
449 | |||
450 | Alignment unit required by the kernel (if relocatable_kernel is true.) | ||
451 | |||
452 | Field name: relocatable_kernel | ||
453 | Type: read (reloc) | ||
454 | Offset/size: 0x234/1 | ||
455 | Protocol: 2.05+ | ||
456 | |||
457 | If this field is nonzero, the protected-mode part of the kernel can | ||
458 | be loaded at any address that satisfies the kernel_alignment field. | ||
459 | After loading, the boot loader must set the code32_start field to | ||
460 | point to the loaded code, or to a boot loader hook. | ||
461 | |||
462 | Field name: cmdline_size | ||
463 | Type: read | ||
464 | Offset/size: 0x238/4 | ||
465 | Protocol: 2.06+ | ||
466 | |||
467 | The maximum size of the command line without the terminating | ||
468 | zero. This means that the command line can contain at most | ||
469 | cmdline_size characters. With protocol version 2.05 and earlier, the | ||
470 | maximum size was 255. | ||
250 | 471 | ||
251 | 472 | ||
252 | **** THE KERNEL COMMAND LINE | 473 | **** THE KERNEL COMMAND LINE |