aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/i386/boot.txt
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/i386/boot.txt')
-rw-r--r--Documentation/i386/boot.txt401
1 files changed, 317 insertions, 84 deletions
diff --git a/Documentation/i386/boot.txt b/Documentation/i386/boot.txt
index d01b7a2a0f2e..35985b34d5a6 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-23
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,147 @@ 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 205The byte order of all fields is littleendian (this is x86, after all.)
177 vid_mode: 206
178 Please see the section on SPECIAL COMMAND LINE OPTIONS. 207Field name: setup_secs
179 208Type: read
180 type_of_loader: 209Offset/size: 0x1f1/1
181 If your boot loader has an assigned id (see table below), enter 210Protocol: ALL
182 0xTV here, where T is an identifier for the boot loader and V is 211
183 a version number. Otherwise, enter 0xFF here. 212 The size of the setup code in 512-byte sectors. If this field is
184 213 0, the real value is 4. The real-mode code consists of the boot
185 Assigned boot loader ids: 214 sector (always one 512-byte sector) plus the setup code.
215
216Field name: root_flags
217Type: modify (optional)
218Offset/size: 0x1f2/2
219Protocol: ALL
220
221 If this field is nonzero, the root defaults to readonly. The use of
222 this field is deprecated; use the "ro" or "rw" options on the
223 command line instead.
224
225Field name: syssize
226Type: read
227Offset/size: 0x1f4/4 (protocol 2.04+) 0x1f4/2 (protocol ALL)
228Protocol: 2.04+
229
230 The size of the protected-mode code in units of 16-byte paragraphs.
231 For protocol versions older than 2.04 this field is only two bytes
232 wide, and therefore cannot be trusted for the size of a kernel if
233 the LOAD_HIGH flag is set.
234
235Field name: ram_size
236Type: kernel internal
237Offset/size: 0x1f8/2
238Protocol: ALL
239
240 This field is obsolete.
241
242Field name: vid_mode
243Type: modify (obligatory)
244Offset/size: 0x1fa/2
245
246 Please see the section on SPECIAL COMMAND LINE OPTIONS.
247
248Field name: root_dev
249Type: modify (optional)
250Offset/size: 0x1fc/2
251Protocol: ALL
252
253 The default root device device number. The use of this field is
254 deprecated, use the "root=" option on the command line instead.
255
256Field name: boot_flag
257Type: read
258Offset/size: 0x1fe/2
259Protocol: ALL
260
261 Contains 0xAA55. This is the closest thing old Linux kernels have
262 to a magic number.
263
264Field name: jump
265Type: read
266Offset/size: 0x200/2
267Protocol: 2.00+
268
269 Contains an x86 jump instruction, 0xEB followed by a signed offset
270 relative to byte 0x202. This can be used to determine the size of
271 the header.
272
273Field name: header
274Type: read
275Offset/size: 0x202/4
276Protocol: 2.00+
277
278 Contains the magic number "HdrS" (0x53726448).
279
280Field name: version
281Type: read
282Offset/size: 0x206/2
283Protocol: 2.00+
284
285 Contains the boot protocol version, in (major << 8)+minor format,
286 e.g. 0x0204 for version 2.04, and 0x0a11 for a hypothetical version
287 10.17.
288
289Field name: readmode_swtch
290Type: modify (optional)
291Offset/size: 0x208/4
292Protocol: 2.00+
293
294 Boot loader hook (see ADVANCED BOOT LOADER HOOKS below.)
295
296Field name: start_sys
297Type: read
298Offset/size: 0x20c/4
299Protocol: 2.00+
300
301 The load low segment (0x1000). Obsolete.
302
303Field name: kernel_version
304Type: read
305Offset/size: 0x20e/2
306Protocol: 2.00+
307
308 If set to a nonzero value, contains a pointer to a NUL-terminated
309 human-readable kernel version number string, less 0x200. This can
310 be used to display the kernel version to the user. This value
311 should be less than (0x200*setup_sects).
312
313 For example, if this value is set to 0x1c00, the kernel version
314 number string can be found at offset 0x1e00 in the kernel file.
315 This is a valid value if and only if the "setup_sects" field
316 contains the value 15 or higher, as:
317
318 0x1c00 < 15*0x200 (= 0x1e00) but
319 0x1c00 >= 14*0x200 (= 0x1c00)
320
321 0x1c00 >> 9 = 14, so the minimum value for setup_secs is 15.
322
323Field name: type_of_loader
324Type: write (obligatory)
325Offset/size: 0x210/1
326Protocol: 2.00+
327
328 If your boot loader has an assigned id (see table below), enter
329 0xTV here, where T is an identifier for the boot loader and V is
330 a version number. Otherwise, enter 0xFF here.
331
332 Assigned boot loader ids:
186 0 LILO (0x00 reserved for pre-2.00 bootloader) 333 0 LILO (0x00 reserved for pre-2.00 bootloader)
187 1 Loadlin 334 1 Loadlin
188 2 bootsect-loader (0x20, all other values reserved) 335 2 bootsect-loader (0x20, all other values reserved)
@@ -193,60 +340,145 @@ filled out, however:
193 8 U-BOOT 340 8 U-BOOT
194 9 Xen 341 9 Xen
195 A Gujin 342 A Gujin
343 B Qemu
344
345 Please contact <hpa@zytor.com> if you need a bootloader ID
346 value assigned.
347
348Field name: loadflags
349Type: modify (obligatory)
350Offset/size: 0x211/1
351Protocol: 2.00+
352
353 This field is a bitmask.
354
355 Bit 0 (read): LOADED_HIGH
356 - If 0, the protected-mode code is loaded at 0x10000.
357 - If 1, the protected-mode code is loaded at 0x100000.
358
359 Bit 7 (write): CAN_USE_HEAP
360 Set this bit to 1 to indicate that the value entered in the
361 heap_end_ptr is valid. If this field is clear, some setup code
362 functionality will be disabled.
363
364Field name: setup_move_size
365Type: modify (obligatory)
366Offset/size: 0x212/2
367Protocol: 2.00-2.01
368
369 When using protocol 2.00 or 2.01, if the real mode kernel is not
370 loaded at 0x90000, it gets moved there later in the loading
371 sequence. Fill in this field if you want additional data (such as
372 the kernel command line) moved in addition to the real-mode kernel
373 itself.
374
375 The unit is bytes starting with the beginning of the boot sector.
376
377 This field is can be ignored when the protocol is 2.02 or higher, or
378 if the real-mode code is loaded at 0x90000.
379
380Field name: code32_start
381Type: modify (optional, reloc)
382Offset/size: 0x214/4
383Protocol: 2.00+
384
385 The address to jump to in protected mode. This defaults to the load
386 address of the kernel, and can be used by the boot loader to
387 determine the proper load address.
388
389 This field can be modified for two purposes:
390
391 1. as a boot loader hook (see ADVANCED BOOT LOADER HOOKS below.)
392
393 2. if a bootloader which does not install a hook loads a
394 relocatable kernel at a nonstandard address it will have to modify
395 this field to point to the load address.
396
397Field name: ramdisk_image
398Type: write (obligatory)
399Offset/size: 0x218/4
400Protocol: 2.00+
401
402 The 32-bit linear address of the initial ramdisk or ramfs. Leave at
403 zero if there is no initial ramdisk/ramfs.
404
405Field name: ramdisk_size
406Type: write (obligatory)
407Offset/size: 0x21c/4
408Protocol: 2.00+
409
410 Size of the initial ramdisk or ramfs. Leave at zero if there is no
411 initial ramdisk/ramfs.
412
413Field name: bootsect_kludge
414Type: kernel internal
415Offset/size: 0x220/4
416Protocol: 2.00+
417
418 This field is obsolete.
419
420Field name: heap_end_ptr
421Type: write (obligatory)
422Offset/size: 0x224/2
423Protocol: 2.01+
424
425 Set this field to the offset (from the beginning of the real-mode
426 code) of the end of the setup stack/heap, minus 0x0200.
427
428Field name: cmd_line_ptr
429Type: write (obligatory)
430Offset/size: 0x228/4
431Protocol: 2.02+
432
433 Set this field to the linear address of the kernel command line.
434 The kernel command line can be located anywhere between the end of
435 the setup heap and 0xA0000; it does not have to be located in the
436 same 64K segment as the real-mode code itself.
437
438 Fill in this field even if your boot loader does not support a
439 command line, in which case you can point this to an empty string
440 (or better yet, to the string "auto".) If this field is left at
441 zero, the kernel will assume that your boot loader does not support
442 the 2.02+ protocol.
443
444Field name: initrd_addr_max
445Type: read
446Offset/size: 0x22c/4
447Protocol: 2.03+
448
449 The maximum address that may be occupied by the initial
450 ramdisk/ramfs contents. For boot protocols 2.02 or earlier, this
451 field is not present, and the maximum address is 0x37FFFFFF. (This
452 address is defined as the address of the highest safe byte, so if
453 your ramdisk is exactly 131072 bytes long and this field is
454 0x37FFFFFF, you can start your ramdisk at 0x37FE0000.)
455
456Field name: kernel_alignment
457Type: read (reloc)
458Offset/size: 0x230/4
459Protocol: 2.05+
460
461 Alignment unit required by the kernel (if relocatable_kernel is true.)
462
463Field name: relocatable_kernel
464Type: read (reloc)
465Offset/size: 0x234/1
466Protocol: 2.05+
467
468 If this field is nonzero, the protected-mode part of the kernel can
469 be loaded at any address that satisfies the kernel_alignment field.
470 After loading, the boot loader must set the code32_start field to
471 point to the loaded code, or to a boot loader hook.
472
473Field name: cmdline_size
474Type: read
475Offset/size: 0x238/4
476Protocol: 2.06+
196 477
197 Please contact <hpa@zytor.com> if you need a bootloader ID 478 The maximum size of the command line without the terminating
198 value assigned. 479 zero. This means that the command line can contain at most
199 480 cmdline_size characters. With protocol version 2.05 and earlier, the
200 loadflags, heap_end_ptr: 481 maximum size was 255.
201 If the protocol version is 2.01 or higher, enter the
202 offset limit of the setup heap into heap_end_ptr and set the
203 0x80 bit (CAN_USE_HEAP) of loadflags. heap_end_ptr appears to
204 be relative to the start of setup (offset 0x0200).
205
206 setup_move_size:
207 When using protocol 2.00 or 2.01, if the real mode
208 kernel is not loaded at 0x90000, it gets moved there later in
209 the loading sequence. Fill in this field if you want
210 additional data (such as the kernel command line) moved in
211 addition to the real-mode kernel itself.
212
213 The unit is bytes starting with the beginning of the boot
214 sector.
215
216 ramdisk_image, ramdisk_size:
217 If your boot loader has loaded an initial ramdisk (initrd),
218 set ramdisk_image to the 32-bit pointer to the ramdisk data
219 and the ramdisk_size to the size of the ramdisk data.
220
221 The initrd should typically be located as high in memory as
222 possible, as it may otherwise get overwritten by the early
223 kernel initialization sequence. However, it must never be
224 located above the address specified in the initrd_addr_max
225 field. The initrd should be at least 4K page aligned.
226
227 cmd_line_ptr:
228 If the protocol version is 2.02 or higher, this is a 32-bit
229 pointer to the kernel command line. The kernel command line
230 can be located anywhere between the end of setup and 0xA0000.
231 Fill in this field even if your boot loader does not support a
232 command line, in which case you can point this to an empty
233 string (or better yet, to the string "auto".) If this field
234 is left at zero, the kernel will assume that your boot loader
235 does not support the 2.02+ protocol.
236
237 ramdisk_max:
238 The maximum address that may be occupied by the initrd
239 contents. For boot protocols 2.02 or earlier, this field is
240 not present, and the maximum address is 0x37FFFFFF. (This
241 address is defined as the address of the highest safe byte, so
242 if your ramdisk is exactly 131072 bytes long and this field is
243 0x37FFFFFF, you can start your ramdisk at 0x37FE0000.)
244
245 cmdline_size:
246 The maximum size of the command line without the terminating
247 zero. This means that the command line can contain at most
248 cmdline_size characters. With protocol version 2.05 and
249 earlier, the maximum size was 255.
250 482
251 483
252**** THE KERNEL COMMAND LINE 484**** THE KERNEL COMMAND LINE
@@ -494,7 +726,7 @@ switched off, especially if the loaded kernel has the floppy driver as
494a demand-loaded module! 726a demand-loaded module!
495 727
496 728
497**** ADVANCED BOOT TIME HOOKS 729**** ADVANCED BOOT LOADER HOOKS
498 730
499If the boot loader runs in a particularly hostile environment (such as 731If the boot loader runs in a particularly hostile environment (such as
500LOADLIN, which runs under DOS) it may be impossible to follow the 732LOADLIN, which runs under DOS) it may be impossible to follow the
@@ -519,4 +751,5 @@ IMPORTANT: All the hooks are required to preserve %esp, %ebp, %esi and
519 set them up to BOOT_DS (0x18) yourself. 751 set them up to BOOT_DS (0x18) yourself.
520 752
521 After completing your hook, you should jump to the address 753 After completing your hook, you should jump to the address
522 that was in this field before your boot loader overwrote it. 754 that was in this field before your boot loader overwrote it
755 (relocated, if appropriate.)