1 THE LINUX/x86 BOOT PROTOCOL 2 --------------------------- 3 4On the x86 platform, the Linux kernel uses a rather complicated boot 5convention. This has evolved partially due to historical aspects, as 6well as the desire in the early days to have the kernel itself be a 7bootable image, the complicated PC memory model and due to changed 8expectations in the PC industry caused by the effective demise of 9real-mode DOS as a mainstream operating system. 10 11Currently, the following versions of the Linux/x86 boot protocol exist. 12 13Old kernels: zImage/Image support only. Some very early kernels 14 may not even support a command line. 15 16Protocol 2.00: (Kernel 1.3.73) Added bzImage and initrd support, as 17 well as a formalized way to communicate between the 18 boot loader and the kernel. setup.S made relocatable, 19 although the traditional setup area still assumed 20 writable. 21 22Protocol 2.01: (Kernel 1.3.76) Added a heap overrun warning. 23 24Protocol 2.02: (Kernel 2.4.0-test3-pre3) New command line protocol. 25 Lower the conventional memory ceiling. No overwrite 26 of the traditional setup area, thus making booting 27 safe for systems which use the EBDA from SMM or 32-bit 28 BIOS entry points. zImage deprecated but still 29 supported. 30 31Protocol 2.03: (Kernel 2.4.18-pre1) Explicitly makes the highest possible 32 initrd address available to the bootloader. 33 34Protocol 2.04: (Kernel 2.6.14) Extend the syssize field to four bytes. 35 36Protocol 2.05: (Kernel 2.6.20) Make protected mode kernel relocatable. 37 Introduce relocatable_kernel and kernel_alignment fields. 38 39Protocol 2.06: (Kernel 2.6.22) Added a field that contains the size of 40 the boot command line. 41 42Protocol 2.07: (Kernel 2.6.24) Added paravirtualised boot protocol. 43 Introduced hardware_subarch and hardware_subarch_data 44 and KEEP_SEGMENTS flag in load_flags. 45 46Protocol 2.08: (Kernel 2.6.26) Added crc32 checksum and ELF format 47 payload. Introduced payload_offset and payload_length 48 fields to aid in locating the payload. 49 50Protocol 2.09: (Kernel 2.6.26) Added a field of 64-bit physical 51 pointer to single linked list of struct setup_data. 52 53**** MEMORY LAYOUT 54 55The traditional memory map for the kernel loader, used for Image or 56zImage kernels, typically looks like: 57 58 | | 590A0000 +------------------------+ 60 | Reserved for BIOS | Do not use. Reserved for BIOS EBDA. 6109A000 +------------------------+ 62 | Command line | 63 | Stack/heap | For use by the kernel real-mode code. 64098000 +------------------------+ 65 | Kernel setup | The kernel real-mode code. 66090200 +------------------------+ 67 | Kernel boot sector | The kernel legacy boot sector. 68090000 +------------------------+ 69 | Protected-mode kernel | The bulk of the kernel image. 70010000 +------------------------+ 71 | Boot loader | <- Boot sector entry point 0000:7C00 72001000 +------------------------+ 73 | Reserved for MBR/BIOS | 74000800 +------------------------+ 75 | Typically used by MBR | 76000600 +------------------------+ 77 | BIOS use only | 78000000 +------------------------+ 79 80 81When using bzImage, the protected-mode kernel was relocated to 820x100000 ("high memory"), and the kernel real-mode block (boot sector, 83setup, and stack/heap) was made relocatable to any address between 840x10000 and end of low memory. Unfortunately, in protocols 2.00 and 852.01 the 0x90000+ memory range is still used internally by the kernel; 86the 2.02 protocol resolves that problem. 87 88It is desirable to keep the "memory ceiling" -- the highest point in 89low memory touched by the boot loader -- as low as possible, since 90some newer BIOSes have begun to allocate some rather large amounts of 91memory, called the Extended BIOS Data Area, near the top of low 92memory. The boot loader should use the "INT 12h" BIOS call to verify 93how much low memory is available. 94 95Unfortunately, if INT 12h reports that the amount of memory is too 96low, there is usually nothing the boot loader can do but to report an 97error to the user. The boot loader should therefore be designed to 98take up as little space in low memory as it reasonably can. For 99zImage or old bzImage kernels, which need data written into the 1000x90000 segment, the boot loader should make sure not to use memory 101above the 0x9A000 point; too many BIOSes will break above that point. 102 103For a modern bzImage kernel with boot protocol version >= 2.02, a 104memory layout like the following is suggested: 105 106 ~ ~ 107 | Protected-mode kernel | 108100000 +------------------------+ 109 | I/O memory hole | 1100A0000 +------------------------+ 111 | Reserved for BIOS | Leave as much as possible unused 112 ~ ~ 113 | Command line | (Can also be below the X+10000 mark) 114X+10000 +------------------------+ 115 | Stack/heap | For use by the kernel real-mode code. 116X+08000 +------------------------+ 117 | Kernel setup | The kernel real-mode code. 118 | Kernel boot sector | The kernel legacy boot sector. 119X +------------------------+ 120 | Boot loader | <- Boot sector entry point 0000:7C00 121001000 +------------------------+ 122 | Reserved for MBR/BIOS | 123000800 +------------------------+ 124 | Typically used by MBR | 125000600 +------------------------+ 126 | BIOS use only | 127000000 +------------------------+ 128 129... where the address X is as low as the design of the boot loader 130permits. 131 132 133**** THE REAL-MODE KERNEL HEADER 134 135In the following text, and anywhere in the kernel boot sequence, "a 136sector" refers to 512 bytes. It is independent of the actual sector 137size of the underlying medium. 138 139The first step in loading a Linux kernel should be to load the 140real-mode code (boot sector and setup code) and then examine the 141following header at offset 0x01f1. The real-mode code can total up to 14232K, although the boot loader may choose to load only the first two 143sectors (1K) and then examine the bootup sector size. 144 145The header looks like: 146 147Offset Proto Name Meaning 148/Size 149 15001F1/1 ALL(1 setup_sects The size of the setup in sectors 15101F2/2 ALL root_flags If set, the root is mounted readonly 15201F4/4 2.04+(2 syssize The size of the 32-bit code in 16-byte paras 15301F8/2 ALL ram_size DO NOT USE - for bootsect.S use only 15401FA/2 ALL vid_mode Video mode control 15501FC/2 ALL root_dev Default root device number 15601FE/2 ALL boot_flag 0xAA55 magic number 1570200/2 2.00+ jump Jump instruction 1580202/4 2.00+ header Magic signature "HdrS" 1590206/2 2.00+ version Boot protocol version supported 1600208/4 2.00+ realmode_swtch Boot loader hook (see below) 161020C/2 2.00+ start_sys The load-low segment (0x1000) (obsolete) 162020E/2 2.00+ kernel_version Pointer to kernel version string 1630210/1 2.00+ type_of_loader Boot loader identifier 1640211/1 2.00+ loadflags Boot protocol option flags 1650212/2 2.00+ setup_move_size Move to high memory size (used with hooks) 1660214/4 2.00+ code32_start Boot loader hook (see below) 1670218/4 2.00+ ramdisk_image initrd load address (set by boot loader) 168021C/4 2.00+ ramdisk_size initrd size (set by boot loader) 1690220/4 2.00+ bootsect_kludge DO NOT USE - for bootsect.S use only 1700224/2 2.01+ heap_end_ptr Free memory after setup end 1710226/2 N/A pad1 Unused 1720228/4 2.02+ cmd_line_ptr 32-bit pointer to the kernel command line 173022C/4 2.03+ initrd_addr_max Highest legal initrd address 1740230/4 2.05+ kernel_alignment Physical addr alignment required for kernel 1750234/1 2.05+ relocatable_kernel Whether kernel is relocatable or not 1760235/3 N/A pad2 Unused 1770238/4 2.06+ cmdline_size Maximum size of the kernel command line 178023C/4 2.07+ hardware_subarch Hardware subarchitecture 1790240/8 2.07+ hardware_subarch_data Subarchitecture-specific data 1800248/4 2.08+ payload_offset Offset of kernel payload 181024C/4 2.08+ payload_length Length of kernel payload 1820250/8 2.09+ setup_data 64-bit physical pointer to linked list 183 of struct setup_data 184 185(1) For backwards compatibility, if the setup_sects field contains 0, the 186 real value is 4. 187 188(2) For boot protocol prior to 2.04, the upper two bytes of the syssize 189 field are unusable, which means the size of a bzImage kernel 190 cannot be determined. 191 192If the "HdrS" (0x53726448) magic number is not found at offset 0x202, 193the boot protocol version is "old". Loading an old kernel, the 194following parameters should be assumed: 195 196 Image type = zImage 197 initrd not supported 198 Real-mode kernel must be located at 0x90000. 199 200Otherwise, the "version" field contains the protocol version, 201e.g. protocol version 2.01 will contain 0x0201 in this field. When 202setting fields in the header, you must make sure only to set fields 203supported by the protocol version in use. 204 205 206**** DETAILS OF HEADER FIELDS 207 208For each field, some are information from the kernel to the bootloader 209("read"), some are expected to be filled out by the bootloader 210("write"), and some are expected to be read and modified by the 211bootloader ("modify"). 212 213All general purpose boot loaders should write the fields marked 214(obligatory). Boot loaders who want to load the kernel at a 215nonstandard address should fill in the fields marked (reloc); other 216boot loaders can ignore those fields. 217 218The byte order of all fields is littleendian (this is x86, after all.) 219 220Field name: setup_sects 221Type: read 222Offset/size: 0x1f1/1 223Protocol: ALL 224 225 The size of the setup code in 512-byte sectors. If this field is 226 0, the real value is 4. The real-mode code consists of the boot 227 sector (always one 512-byte sector) plus the setup code. 228 229Field name: root_flags 230Type: modify (optional) 231Offset/size: 0x1f2/2 232Protocol: ALL 233 234 If this field is nonzero, the root defaults to readonly. The use of 235 this field is deprecated; use the "ro" or "rw" options on the 236 command line instead. 237 238Field name: syssize 239Type: read 240Offset/size: 0x1f4/4 (protocol 2.04+) 0x1f4/2 (protocol ALL) 241Protocol: 2.04+ 242 243 The size of the protected-mode code in units of 16-byte paragraphs. 244 For protocol versions older than 2.04 this field is only two bytes 245 wide, and therefore cannot be trusted for the size of a kernel if 246 the LOAD_HIGH flag is set. 247 248Field name: ram_size 249Type: kernel internal 250Offset/size: 0x1f8/2 251Protocol: ALL 252 253 This field is obsolete. 254 255Field name: vid_mode 256Type: modify (obligatory) 257Offset/size: 0x1fa/2 258 259 Please see the section on SPECIAL COMMAND LINE OPTIONS. 260 261Field name: root_dev 262Type: modify (optional) 263Offset/size: 0x1fc/2 264Protocol: ALL 265 266 The default root device device number. The use of this field is 267 deprecated, use the "root=" option on the command line instead. 268 269Field name: boot_flag 270Type: read 271Offset/size: 0x1fe/2 272Protocol: ALL 273 274 Contains 0xAA55. This is the closest thing old Linux kernels have 275 to a magic number. 276 277Field name: jump 278Type: read 279Offset/size: 0x200/2 280Protocol: 2.00+ 281 282 Contains an x86 jump instruction, 0xEB followed by a signed offset 283 relative to byte 0x202. This can be used to determine the size of 284 the header. 285 286Field name: header 287Type: read 288Offset/size: 0x202/4 289Protocol: 2.00+ 290 291 Contains the magic number "HdrS" (0x53726448). 292 293Field name: version 294Type: read 295Offset/size: 0x206/2 296Protocol: 2.00+ 297 298 Contains the boot protocol version, in (major << 8)+minor format, 299 e.g. 0x0204 for version 2.04, and 0x0a11 for a hypothetical version 300 10.17. 301 302Field name: readmode_swtch 303Type: modify (optional) 304Offset/size: 0x208/4 305Protocol: 2.00+ 306 307 Boot loader hook (see ADVANCED BOOT LOADER HOOKS below.) 308 309Field name: start_sys 310Type: read 311Offset/size: 0x20c/2 312Protocol: 2.00+ 313 314 The load low segment (0x1000). Obsolete. 315 316Field name: kernel_version 317Type: read 318Offset/size: 0x20e/2 319Protocol: 2.00+ 320 321 If set to a nonzero value, contains a pointer to a NUL-terminated 322 human-readable kernel version number string, less 0x200. This can 323 be used to display the kernel version to the user. This value 324 should be less than (0x200*setup_sects). 325 326 For example, if this value is set to 0x1c00, the kernel version 327 number string can be found at offset 0x1e00 in the kernel file. 328 This is a valid value if and only if the "setup_sects" field 329 contains the value 15 or higher, as: 330 331 0x1c00 < 15*0x200 (= 0x1e00) but 332 0x1c00 >= 14*0x200 (= 0x1c00) 333 334 0x1c00 >> 9 = 14, so the minimum value for setup_secs is 15. 335 336Field name: type_of_loader 337Type: write (obligatory) 338Offset/size: 0x210/1 339Protocol: 2.00+ 340 341 If your boot loader has an assigned id (see table below), enter 342 0xTV here, where T is an identifier for the boot loader and V is 343 a version number. Otherwise, enter 0xFF here. 344 345 Assigned boot loader ids: 346 0 LILO (0x00 reserved for pre-2.00 bootloader) 347 1 Loadlin 348 2 bootsect-loader (0x20, all other values reserved) 349 3 SYSLINUX 350 4 EtherBoot 351 5 ELILO 352 7 GRUB 353 8 U-BOOT 354 9 Xen 355 A Gujin 356 B Qemu 357 358 Please contact <hpa@zytor.com> if you need a bootloader ID 359 value assigned. 360 361Field name: loadflags 362Type: modify (obligatory) 363Offset/size: 0x211/1 364Protocol: 2.00+ 365 366 This field is a bitmask. 367 368 Bit 0 (read): LOADED_HIGH 369 - If 0, the protected-mode code is loaded at 0x10000. 370 - If 1, the protected-mode code is loaded at 0x100000. 371 372 Bit 5 (write): QUIET_FLAG 373 - If 0, print early messages. 374 - If 1, suppress early messages. 375 This requests to the kernel (decompressor and early 376 kernel) to not write early messages that require 377 accessing the display hardware directly. 378 379 Bit 6 (write): KEEP_SEGMENTS 380 Protocol: 2.07+ 381 - If 0, reload the segment registers in the 32bit entry point. 382 - If 1, do not reload the segment registers in the 32bit entry point. 383 Assume that %cs %ds %ss %es are all set to flat segments with 384 a base of 0 (or the equivalent for their environment). 385 386 Bit 7 (write): CAN_USE_HEAP 387 Set this bit to 1 to indicate that the value entered in the 388 heap_end_ptr is valid. If this field is clear, some setup code 389 functionality will be disabled. 390 391Field name: setup_move_size 392Type: modify (obligatory) 393Offset/size: 0x212/2 394Protocol: 2.00-2.01 395 396 When using protocol 2.00 or 2.01, if the real mode kernel is not 397 loaded at 0x90000, it gets moved there later in the loading 398 sequence. Fill in this field if you want additional data (such as 399 the kernel command line) moved in addition to the real-mode kernel 400 itself. 401 402 The unit is bytes starting with the beginning of the boot sector. 403 404 This field is can be ignored when the protocol is 2.02 or higher, or 405 if the real-mode code is loaded at 0x90000. 406 407Field name: code32_start 408Type: modify (optional, reloc) 409Offset/size: 0x214/4 410Protocol: 2.00+ 411 412 The address to jump to in protected mode. This defaults to the load 413 address of the kernel, and can be used by the boot loader to 414 determine the proper load address. 415 416 This field can be modified for two purposes: 417 418 1. as a boot loader hook (see ADVANCED BOOT LOADER HOOKS below.) 419 420 2. if a bootloader which does not install a hook loads a 421 relocatable kernel at a nonstandard address it will have to modify 422 this field to point to the load address. 423 424Field name: ramdisk_image 425Type: write (obligatory) 426Offset/size: 0x218/4 427Protocol: 2.00+ 428 429 The 32-bit linear address of the initial ramdisk or ramfs. Leave at 430 zero if there is no initial ramdisk/ramfs. 431 432Field name: ramdisk_size 433Type: write (obligatory) 434Offset/size: 0x21c/4 435Protocol: 2.00+ 436 437 Size of the initial ramdisk or ramfs. Leave at zero if there is no 438 initial ramdisk/ramfs. 439 440Field name: bootsect_kludge 441Type: kernel internal 442Offset/size: 0x220/4 443Protocol: 2.00+ 444 445 This field is obsolete. 446 447Field name: heap_end_ptr 448Type: write (obligatory) 449Offset/size: 0x224/2 450Protocol: 2.01+ 451 452 Set this field to the offset (from the beginning of the real-mode 453 code) of the end of the setup stack/heap, minus 0x0200. 454 455Field name: cmd_line_ptr 456Type: write (obligatory) 457Offset/size: 0x228/4 458Protocol: 2.02+ 459 460 Set this field to the linear address of the kernel command line. 461 The kernel command line can be located anywhere between the end of 462 the setup heap and 0xA0000; it does not have to be located in the 463 same 64K segment as the real-mode code itself. 464 465 Fill in this field even if your boot loader does not support a 466 command line, in which case you can point this to an empty string 467 (or better yet, to the string "auto".) If this field is left at 468 zero, the kernel will assume that your boot loader does not support 469 the 2.02+ protocol. 470 471Field name: initrd_addr_max 472Type: read 473Offset/size: 0x22c/4 474Protocol: 2.03+ 475 476 The maximum address that may be occupied by the initial 477 ramdisk/ramfs contents. For boot protocols 2.02 or earlier, this 478 field is not present, and the maximum address is 0x37FFFFFF. (This 479 address is defined as the address of the highest safe byte, so if 480 your ramdisk is exactly 131072 bytes long and this field is 481 0x37FFFFFF, you can start your ramdisk at 0x37FE0000.) 482 483Field name: kernel_alignment 484Type: read (reloc) 485Offset/size: 0x230/4 486Protocol: 2.05+ 487 488 Alignment unit required by the kernel (if relocatable_kernel is true.) 489 490Field name: relocatable_kernel 491Type: read (reloc) 492Offset/size: 0x234/1 493Protocol: 2.05+ 494 495 If this field is nonzero, the protected-mode part of the kernel can 496 be loaded at any address that satisfies the kernel_alignment field. 497 After loading, the boot loader must set the code32_start field to 498 point to the loaded code, or to a boot loader hook. 499 500Field name: cmdline_size 501Type: read 502Offset/size: 0x238/4 503Protocol: 2.06+ 504 505 The maximum size of the command line without the terminating 506 zero. This means that the command line can contain at most 507 cmdline_size characters. With protocol version 2.05 and earlier, the 508 maximum size was 255. 509 510Field name: hardware_subarch 511Type: write (optional, defaults to x86/PC) 512Offset/size: 0x23c/4 513Protocol: 2.07+ 514 515 In a paravirtualized environment the hardware low level architectural 516 pieces such as interrupt handling, page table handling, and 517 accessing process control registers needs to be done differently. 518 519 This field allows the bootloader to inform the kernel we are in one 520 one of those environments. 521 522 0x00000000 The default x86/PC environment 523 0x00000001 lguest 524 0x00000002 Xen 525 526Field name: hardware_subarch_data 527Type: write (subarch-dependent) 528Offset/size: 0x240/8 529Protocol: 2.07+ 530 531 A pointer to data that is specific to hardware subarch 532 This field is currently unused for the default x86/PC environment, 533 do not modify. 534 535Field name: payload_offset 536Type: read 537Offset/size: 0x248/4 538Protocol: 2.08+ 539 540 If non-zero then this field contains the offset from the beginning 541 of the protected-mode code to the payload. 542 543 The payload may be compressed. The format of both the compressed and 544 uncompressed data should be determined using the standard magic 545 numbers. Currently only gzip compressed ELF is used. 546 547Field name: payload_length 548Type: read 549Offset/size: 0x24c/4 550Protocol: 2.08+ 551 552 The length of the payload. 553 554Field name: setup_data 555Type: write (special) 556Offset/size: 0x250/8 557Protocol: 2.09+ 558 559 The 64-bit physical pointer to NULL terminated single linked list of 560 struct setup_data. This is used to define a more extensible boot 561 parameters passing mechanism. The definition of struct setup_data is 562 as follow: 563 564 struct setup_data { 565 u64 next; 566 u32 type; 567 u32 len; 568 u8 data[0]; 569 }; 570 571 Where, the next is a 64-bit physical pointer to the next node of 572 linked list, the next field of the last node is 0; the type is used 573 to identify the contents of data; the len is the length of data 574 field; the data holds the real payload. 575 576 This list may be modified at a number of points during the bootup 577 process. Therefore, when modifying this list one should always make 578 sure to consider the case where the linked list already contains 579 entries. 580 581 582**** THE IMAGE CHECKSUM 583 584From boot protocol version 2.08 onwards the CRC-32 is calculated over 585the entire file using the characteristic polynomial 0x04C11DB7 and an 586initial remainder of 0xffffffff. The checksum is appended to the 587file; therefore the CRC of the file up to the limit specified in the 588syssize field of the header is always 0. 589 590 591**** THE KERNEL COMMAND LINE 592 593The kernel command line has become an important way for the boot 594loader to communicate with the kernel. Some of its options are also 595relevant to the boot loader itself, see "special command line options" 596below. 597 598The kernel command line is a null-terminated string. The maximum 599length can be retrieved from the field cmdline_size. Before protocol 600version 2.06, the maximum was 255 characters. A string that is too 601long will be automatically truncated by the kernel. 602 603If the boot protocol version is 2.02 or later, the address of the 604kernel command line is given by the header field cmd_line_ptr (see 605above.) This address can be anywhere between the end of the setup 606heap and 0xA0000. 607 608If the protocol version is *not* 2.02 or higher, the kernel 609command line is entered using the following protocol: 610 611 At offset 0x0020 (word), "cmd_line_magic", enter the magic 612 number 0xA33F. 613 614 At offset 0x0022 (word), "cmd_line_offset", enter the offset 615 of the kernel command line (relative to the start of the 616 real-mode kernel). 617 618 The kernel command line *must* be within the memory region 619 covered by setup_move_size, so you may need to adjust this 620 field. 621 622 623**** MEMORY LAYOUT OF THE REAL-MODE CODE 624 625The real-mode code requires a stack/heap to be set up, as well as 626memory allocated for the kernel command line. This needs to be done 627in the real-mode accessible memory in bottom megabyte. 628 629It should be noted that modern machines often have a sizable Extended 630BIOS Data Area (EBDA). As a result, it is advisable to use as little 631of the low megabyte as possible. 632 633Unfortunately, under the following circumstances the 0x90000 memory 634segment has to be used: 635 636 - When loading a zImage kernel ((loadflags & 0x01) == 0). 637 - When loading a 2.01 or earlier boot protocol kernel. 638 639 -> For the 2.00 and 2.01 boot protocols, the real-mode code 640 can be loaded at another address, but it is internally 641 relocated to 0x90000. For the "old" protocol, the 642 real-mode code must be loaded at 0x90000. 643 644When loading at 0x90000, avoid using memory above 0x9a000. 645 646For boot protocol 2.02 or higher, the command line does not have to be 647located in the same 64K segment as the real-mode setup code; it is 648thus permitted to give the stack/heap the full 64K segment and locate 649the command line above it. 650 651The kernel command line should not be located below the real-mode 652code, nor should it be located in high memory. 653 654 655**** SAMPLE BOOT CONFIGURATION 656 657As a sample configuration, assume the following layout of the real 658mode segment: 659 660 When loading below 0x90000, use the entire segment: 661 662 0x0000-0x7fff Real mode kernel 663 0x8000-0xdfff Stack and heap 664 0xe000-0xffff Kernel command line 665 666 When loading at 0x90000 OR the protocol version is 2.01 or earlier: 667 668 0x0000-0x7fff Real mode kernel 669 0x8000-0x97ff Stack and heap 670 0x9800-0x9fff Kernel command line 671 672Such a boot loader should enter the following fields in the header: 673 674 unsigned long base_ptr; /* base address for real-mode segment */ 675 676 if ( setup_sects == 0 ) { 677 setup_sects = 4; 678 } 679 680 if ( protocol >= 0x0200 ) { 681 type_of_loader = <type code>; 682 if ( loading_initrd ) { 683 ramdisk_image = <initrd_address>; 684 ramdisk_size = <initrd_size>; 685 } 686 687 if ( protocol >= 0x0202 && loadflags & 0x01 ) 688 heap_end = 0xe000; 689 else 690 heap_end = 0x9800; 691 692 if ( protocol >= 0x0201 ) { 693 heap_end_ptr = heap_end - 0x200; 694 loadflags |= 0x80; /* CAN_USE_HEAP */ 695 } 696 697 if ( protocol >= 0x0202 ) { 698 cmd_line_ptr = base_ptr + heap_end; 699 strcpy(cmd_line_ptr, cmdline); 700 } else { 701 cmd_line_magic = 0xA33F; 702 cmd_line_offset = heap_end; 703 setup_move_size = heap_end + strlen(cmdline)+1; 704 strcpy(base_ptr+cmd_line_offset, cmdline); 705 } 706 } else { 707 /* Very old kernel */ 708 709 heap_end = 0x9800; 710 711 cmd_line_magic = 0xA33F; 712 cmd_line_offset = heap_end; 713 714 /* A very old kernel MUST have its real-mode code 715 loaded at 0x90000 */ 716 717 if ( base_ptr != 0x90000 ) { 718 /* Copy the real-mode kernel */ 719 memcpy(0x90000, base_ptr, (setup_sects+1)*512); 720 base_ptr = 0x90000; /* Relocated */ 721 } 722 723 strcpy(0x90000+cmd_line_offset, cmdline); 724 725 /* It is recommended to clear memory up to the 32K mark */ 726 memset(0x90000 + (setup_sects+1)*512, 0, 727 (64-(setup_sects+1))*512); 728 } 729 730 731**** LOADING THE REST OF THE KERNEL 732 733The 32-bit (non-real-mode) kernel starts at offset (setup_sects+1)*512 734in the kernel file (again, if setup_sects == 0 the real value is 4.) 735It should be loaded at address 0x10000 for Image/zImage kernels and 7360x100000 for bzImage kernels. 737 738The kernel is a bzImage kernel if the protocol >= 2.00 and the 0x01 739bit (LOAD_HIGH) in the loadflags field is set: 740 741 is_bzImage = (protocol >= 0x0200) && (loadflags & 0x01); 742 load_address = is_bzImage ? 0x100000 : 0x10000; 743 744Note that Image/zImage kernels can be up to 512K in size, and thus use 745the entire 0x10000-0x90000 range of memory. This means it is pretty 746much a requirement for these kernels to load the real-mode part at 7470x90000. bzImage kernels allow much more flexibility. 748 749 750**** SPECIAL COMMAND LINE OPTIONS 751 752If the command line provided by the boot loader is entered by the 753user, the user may expect the following command line options to work. 754They should normally not be deleted from the kernel command line even 755though not all of them are actually meaningful to the kernel. Boot 756loader authors who need additional command line options for the boot 757loader itself should get them registered in 758Documentation/kernel-parameters.txt to make sure they will not 759conflict with actual kernel options now or in the future. 760 761 vga=<mode> 762 <mode> here is either an integer (in C notation, either 763 decimal, octal, or hexadecimal) or one of the strings 764 "normal" (meaning 0xFFFF), "ext" (meaning 0xFFFE) or "ask" 765 (meaning 0xFFFD). This value should be entered into the 766 vid_mode field, as it is used by the kernel before the command 767 line is parsed. 768 769 mem=<size> 770 <size> is an integer in C notation optionally followed by 771 (case insensitive) K, M, G, T, P or E (meaning << 10, << 20, 772 << 30, << 40, << 50 or << 60). This specifies the end of 773 memory to the kernel. This affects the possible placement of 774 an initrd, since an initrd should be placed near end of 775 memory. Note that this is an option to *both* the kernel and 776 the bootloader! 777 778 initrd=<file> 779 An initrd should be loaded. The meaning of <file> is 780 obviously bootloader-dependent, and some boot loaders 781 (e.g. LILO) do not have such a command. 782 783In addition, some boot loaders add the following options to the 784user-specified command line: 785 786 BOOT_IMAGE=<file> 787 The boot image which was loaded. Again, the meaning of <file> 788 is obviously bootloader-dependent. 789 790 auto 791 The kernel was booted without explicit user intervention. 792 793If these options are added by the boot loader, it is highly 794recommended that they are located *first*, before the user-specified 795or configuration-specified command line. Otherwise, "init=/bin/sh" 796gets confused by the "auto" option. 797 798 799**** RUNNING THE KERNEL 800 801The kernel is started by jumping to the kernel entry point, which is 802located at *segment* offset 0x20 from the start of the real mode 803kernel. This means that if you loaded your real-mode kernel code at 8040x90000, the kernel entry point is 9020:0000. 805 806At entry, ds = es = ss should point to the start of the real-mode 807kernel code (0x9000 if the code is loaded at 0x90000), sp should be 808set up properly, normally pointing to the top of the heap, and 809interrupts should be disabled. Furthermore, to guard against bugs in 810the kernel, it is recommended that the boot loader sets fs = gs = ds = 811es = ss. 812 813In our example from above, we would do: 814 815 /* Note: in the case of the "old" kernel protocol, base_ptr must 816 be == 0x90000 at this point; see the previous sample code */ 817 818 seg = base_ptr >> 4; 819 820 cli(); /* Enter with interrupts disabled! */ 821 822 /* Set up the real-mode kernel stack */ 823 _SS = seg; 824 _SP = heap_end; 825 826 _DS = _ES = _FS = _GS = seg; 827 jmp_far(seg+0x20, 0); /* Run the kernel */ 828 829If your boot sector accesses a floppy drive, it is recommended to 830switch off the floppy motor before running the kernel, since the 831kernel boot leaves interrupts off and thus the motor will not be 832switched off, especially if the loaded kernel has the floppy driver as 833a demand-loaded module! 834 835 836**** ADVANCED BOOT LOADER HOOKS 837 838If the boot loader runs in a particularly hostile environment (such as 839LOADLIN, which runs under DOS) it may be impossible to follow the 840standard memory location requirements. Such a boot loader may use the 841following hooks that, if set, are invoked by the kernel at the 842appropriate time. The use of these hooks should probably be 843considered an absolutely last resort! 844 845IMPORTANT: All the hooks are required to preserve %esp, %ebp, %esi and 846%edi across invocation. 847 848 realmode_swtch: 849 A 16-bit real mode far subroutine invoked immediately before 850 entering protected mode. The default routine disables NMI, so 851 your routine should probably do so, too. 852 853 code32_start: 854 A 32-bit flat-mode routine *jumped* to immediately after the 855 transition to protected mode, but before the kernel is 856 uncompressed. No segments, except CS, are guaranteed to be 857 set up (current kernels do, but older ones do not); you should 858 set them up to BOOT_DS (0x18) yourself. 859 860 After completing your hook, you should jump to the address 861 that was in this field before your boot loader overwrote it 862 (relocated, if appropriate.) 863 864 865**** 32-bit BOOT PROTOCOL 866 867For machine with some new BIOS other than legacy BIOS, such as EFI, 868LinuxBIOS, etc, and kexec, the 16-bit real mode setup code in kernel 869based on legacy BIOS can not be used, so a 32-bit boot protocol needs 870to be defined. 871 872In 32-bit boot protocol, the first step in loading a Linux kernel 873should be to setup the boot parameters (struct boot_params, 874traditionally known as "zero page"). The memory for struct boot_params 875should be allocated and initialized to all zero. Then the setup header 876from offset 0x01f1 of kernel image on should be loaded into struct 877boot_params and examined. The end of setup header can be calculated as 878follow: 879 880 0x0202 + byte value at offset 0x0201 881 882In addition to read/modify/write the setup header of the struct 883boot_params as that of 16-bit boot protocol, the boot loader should 884also fill the additional fields of the struct boot_params as that 885described in zero-page.txt. 886 887After setupping the struct boot_params, the boot loader can load the 88832/64-bit kernel in the same way as that of 16-bit boot protocol. 889 890In 32-bit boot protocol, the kernel is started by jumping to the 89132-bit kernel entry point, which is the start address of loaded 89232/64-bit kernel. 893 894At entry, the CPU must be in 32-bit protected mode with paging 895disabled; a GDT must be loaded with the descriptors for selectors 896__BOOT_CS(0x10) and __BOOT_DS(0x18); both descriptors must be 4G flat 897segment; __BOOS_CS must have execute/read permission, and __BOOT_DS 898must have read/write permission; CS must be __BOOT_CS and DS, ES, SS 899must be __BOOT_DS; interrupt must be disabled; %esi must hold the base 900address of the struct boot_params; %ebp, %edi and %ebx must be zero. 901