aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
authorH. Peter Anvin <hpa@zytor.com>2007-05-17 18:50:47 -0400
committerLinus Torvalds <torvalds@woody.linux-foundation.org>2007-05-18 23:52:26 -0400
commitdec04cff500d4e543c55ab1beb0af85d8ed7e6bd (patch)
tree341736cf4a4fa51a8f5126e8011f8f7d6553dd53 /Documentation
parent66123549dbd75c67509c73b9d94bf7a9d2f4b286 (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.txt385
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
7On the i386 platform, the Linux kernel uses a rather complicated boot 7On the i386 platform, the Linux kernel uses a rather complicated boot
8convention. This has evolved partially due to historical aspects, as 8convention. This has evolved partially due to historical aspects, as
@@ -52,7 +52,8 @@ zImage kernels, typically looks like:
520A0000 +------------------------+ 520A0000 +------------------------+
53 | Reserved for BIOS | Do not use. Reserved for BIOS EBDA. 53 | Reserved for BIOS | Do not use. Reserved for BIOS EBDA.
5409A000 +------------------------+ 5409A000 +------------------------+
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.
56098000 +------------------------+ 57098000 +------------------------+
57 | Kernel setup | The kernel real-mode code. 58 | Kernel setup | The kernel real-mode code.
58090200 +------------------------+ 59090200 +------------------------+
@@ -73,10 +74,9 @@ zImage kernels, typically looks like:
73When using bzImage, the protected-mode kernel was relocated to 74When using bzImage, the protected-mode kernel was relocated to
740x100000 ("high memory"), and the kernel real-mode block (boot sector, 750x100000 ("high memory"), and the kernel real-mode block (boot sector,
75setup, and stack/heap) was made relocatable to any address between 76setup, and stack/heap) was made relocatable to any address between
760x10000 and end of low memory. Unfortunately, in protocols 2.00 and 770x10000 and end of low memory. Unfortunately, in protocols 2.00 and
772.01 the command line is still required to live in the 0x9XXXX memory 782.01 the 0x90000+ memory range is still used internally by the kernel;
78range, and that memory range is still overwritten by the early kernel. 79the 2.02 protocol resolves that problem.
79The 2.02 protocol resolves that problem.
80 80
81It is desirable to keep the "memory ceiling" -- the highest point in 81It is desirable to keep the "memory ceiling" -- the highest point in
82low memory touched by the boot loader -- as low as possible, since 82low 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
930x90000 segment, the boot loader should make sure not to use memory 930x90000 segment, the boot loader should make sure not to use memory
94above the 0x9A000 point; too many BIOSes will break above that point. 94above the 0x9A000 point; too many BIOSes will break above that point.
95 95
96For a modern bzImage kernel with boot protocol version >= 2.02, a
97memory layout like the following is suggested:
98
99 ~ ~
100 | Protected-mode kernel |
101100000 +------------------------+
102 | I/O memory hole |
1030A0000 +------------------------+
104 | Reserved for BIOS | Leave as much as possible unused
105 ~ ~
106 | Command line | (Can also be below the X+10000 mark)
107X+10000 +------------------------+
108 | Stack/heap | For use by the kernel real-mode code.
109X+08000 +------------------------+
110 | Kernel setup | The kernel real-mode code.
111 | Kernel boot sector | The kernel legacy boot sector.
112X +------------------------+
113 | Boot loader | <- Boot sector entry point 0000:7C00
114001000 +------------------------+
115 | Reserved for MBR/BIOS |
116000800 +------------------------+
117 | Typically used by MBR |
118000600 +------------------------+
119 | BIOS use only |
120000000 +------------------------+
121
122... where the address X is as low as the design of the boot loader
123permits.
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
160setting fields in the header, you must make sure only to set fields 189setting fields in the header, you must make sure only to set fields
161supported by the protocol version in use. 190supported by the protocol version in use.
162 191
163The "kernel_version" field, if set to a nonzero value, contains a 192
164pointer to a null-terminated human-readable kernel version number 193**** DETAILS OF HEADER FIELDS
165string, less 0x200. This can be used to display the kernel version to 194
166the user. This value should be less than (0x200*setup_sects). For 195For each field, some are information from the kernel to the bootloader
167example, if this value is set to 0x1c00, the kernel version number 196("read"), some are expected to be filled out by the bootloader
168string 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
169valid value if and only if the "setup_sects" field contains the value 198bootloader ("modify").
17014 or higher. 199
171 200All general purpose boot loaders should write the fields marked
172Most boot loaders will simply load the kernel at its target address 201(obligatory). Boot loaders who want to load the kernel at a
173directly. Such boot loaders do not need to worry about filling in 202nonstandard address should fill in the fields marked (reloc); other
174most of the fields in the header. The following fields should be 203boot loaders can ignore those fields.
175filled out, however: 204
176 205Field name: setup_secs
177 vid_mode: 206Type: read
178 Please see the section on SPECIAL COMMAND LINE OPTIONS. 207Offset/size: 0x1f1/1
179 208Protocol: 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: 214Field name: root_flags
215Type: modify (optional)
216Offset/size: 0x1f2/2
217Protocol: 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
223Field name: syssize
224Type: read
225Offset/size: 0x1f4/4 (protocol 2.04+) 0x1f4/2 (protocol ALL)
226Protocol: 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
233Field name: ram_size
234Type: kernel internal
235Offset/size: 0x1f8/2
236Protocol: ALL
237
238 This field is obsolete.
239
240Field name: vid_mode
241Type: modify (obligatory)
242Offset/size: 0x1fa/2
243
244 Please see the section on SPECIAL COMMAND LINE OPTIONS.
245
246Field name: root_dev
247Type: modify (optional)
248Offset/size: 0x1fc/2
249Protocol: 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
254Field name: boot_flag
255Type: read
256Offset/size: 0x1fe/2
257Protocol: ALL
258
259 Contains 0xAA55. This is the closest thing old Linux kernels have
260 to a magic number.
261
262Field name: jump
263Type: read
264Offset/size: 0x200/2
265Protocol: 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
271Field name: header
272Type: read
273Offset/size: 0x202/4
274Protocol: 2.00+
275
276 Contains the magic number "HdrS" (0x53726448).
277
278Field name: version
279Type: read
280Offset/size: 0x206/2
281Protocol: 2.00+
282
283 Contains the boot protocol version, e.g. 0x0204 for version 2.04.
284
285Field name: readmode_swtch
286Type: modify (optional)
287Offset/size: 0x208/4
288Protocol: 2.00+
289
290 Boot loader hook (see separate chapter.)
291
292Field name: start_sys
293Type: read
294Offset/size: 0x20c/4
295Protocol: 2.00+
296
297 The load low segment (0x1000). Obsolete.
298
299Field name: kernel_version
300Type: read
301Offset/size: 0x20e/2
302Protocol: 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
312Field name: type_of_loader
313Type: write (obligatory)
314Offset/size: 0x210/1
315Protocol: 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: 337Field name: loadflags
201 If the protocol version is 2.01 or higher, enter the 338Type: modify (obligatory)
202 offset limit of the setup heap into heap_end_ptr and set the 339Offset/size: 0x211/1
203 0x80 bit (CAN_USE_HEAP) of loadflags. heap_end_ptr appears to 340Protocol: 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: 353Field name: setup_move_size
217 If your boot loader has loaded an initial ramdisk (initrd), 354Type: modify (obligatory)
218 set ramdisk_image to the 32-bit pointer to the ramdisk data 355Offset/size: 0x212/2
219 and the ramdisk_size to the size of the ramdisk data. 356Protocol: 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 369Field name: code32_start
233 string (or better yet, to the string "auto".) If this field 370Type: modify (optional, reloc)
234 is left at zero, the kernel will assume that your boot loader 371Offset/size: 0x214/4
235 does not support the 2.02+ protocol. 372Protocol: 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. 386Field name: ramdisk_image
387Type: write (obligatory)
388Offset/size: 0x218/4
389Protocol: 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
394Field name: ramdisk_size
395Type: write (obligatory)
396Offset/size: 0x21c/4
397Protocol: 2.00+
398
399 Size of the initial ramdisk or ramfs. Leave at zero if there is no
400 initial ramdisk/ramfs.
401
402Field name: bootsect_kludge
403Type: kernel internal
404Offset/size: 0x220/4
405Protocol: 2.00+
406
407 This field is obsolete.
408
409Field name: heap_end_ptr
410Type: write (obligatory)
411Offset/size: 0x224/2
412Protocol: 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
417Field name: cmd_line_ptr
418Type: write (obligatory)
419Offset/size: 0x228/4
420Protocol: 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
433Field name: initrd_addr_max
434Type: read
435Offset/size: 0x22c/4
436Protocol: 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
445Field name: kernel_alignment
446Type: read (reloc)
447Offset/size: 0x230/4
448Protocol: 2.05+
449
450 Alignment unit required by the kernel (if relocatable_kernel is true.)
451
452Field name: relocatable_kernel
453Type: read (reloc)
454Offset/size: 0x234/1
455Protocol: 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
462Field name: cmdline_size
463Type: read
464Offset/size: 0x238/4
465Protocol: 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