Loading Documentation/i386/IO-APIC.txt→Documentation/x86/i386/IO-APIC.txt +0 −0 File moved. View file Documentation/i386/boot.txt→Documentation/x86/i386/boot.txt +46 −33 Original line number Original line Diff line number Diff line THE LINUX/I386 BOOT PROTOCOL THE LINUX/x86 BOOT PROTOCOL ---------------------------- --------------------------- H. Peter Anvin <hpa@zytor.com> On the x86 platform, the Linux kernel uses a rather complicated boot Last update 2007-05-23 On the i386 platform, the Linux kernel uses a rather complicated boot convention. This has evolved partially due to historical aspects, as convention. This has evolved partially due to historical aspects, as well as the desire in the early days to have the kernel itself be a well as the desire in the early days to have the kernel itself be a bootable image, the complicated PC memory model and due to changed bootable image, the complicated PC memory model and due to changed expectations in the PC industry caused by the effective demise of expectations in the PC industry caused by the effective demise of real-mode DOS as a mainstream operating system. real-mode DOS as a mainstream operating system. Currently, the following versions of the Linux/i386 boot protocol exist. Currently, the following versions of the Linux/x86 boot protocol exist. Old kernels: zImage/Image support only. Some very early kernels Old kernels: zImage/Image support only. Some very early kernels may not even support a command line. may not even support a command line. Loading Loading @@ -372,10 +369,17 @@ Protocol: 2.00+ - If 0, the protected-mode code is loaded at 0x10000. - If 0, the protected-mode code is loaded at 0x10000. - If 1, the protected-mode code is loaded at 0x100000. - If 1, the protected-mode code is loaded at 0x100000. Bit 5 (write): QUIET_FLAG - If 0, print early messages. - If 1, suppress early messages. This requests to the kernel (decompressor and early kernel) to not write early messages that require accessing the display hardware directly. Bit 6 (write): KEEP_SEGMENTS Bit 6 (write): KEEP_SEGMENTS Protocol: 2.07+ Protocol: 2.07+ - if 0, reload the segment registers in the 32bit entry point. - If 0, reload the segment registers in the 32bit entry point. - if 1, do not reload the segment registers in the 32bit entry point. - If 1, do not reload the segment registers in the 32bit entry point. Assume that %cs %ds %ss %es are all set to flat segments with Assume that %cs %ds %ss %es are all set to flat segments with a base of 0 (or the equivalent for their environment). a base of 0 (or the equivalent for their environment). Loading Loading @@ -504,7 +508,7 @@ Protocol: 2.06+ maximum size was 255. maximum size was 255. Field name: hardware_subarch Field name: hardware_subarch Type: write Type: write (optional, defaults to x86/PC) Offset/size: 0x23c/4 Offset/size: 0x23c/4 Protocol: 2.07+ Protocol: 2.07+ Loading @@ -520,11 +524,13 @@ Protocol: 2.07+ 0x00000002 Xen 0x00000002 Xen Field name: hardware_subarch_data Field name: hardware_subarch_data Type: write Type: write (subarch-dependent) Offset/size: 0x240/8 Offset/size: 0x240/8 Protocol: 2.07+ Protocol: 2.07+ A pointer to data that is specific to hardware subarch A pointer to data that is specific to hardware subarch This field is currently unused for the default x86/PC environment, do not modify. Field name: payload_offset Field name: payload_offset Type: read Type: read Loading @@ -545,6 +551,34 @@ Protocol: 2.08+ The length of the payload. The length of the payload. Field name: setup_data Type: write (special) Offset/size: 0x250/8 Protocol: 2.09+ The 64-bit physical pointer to NULL terminated single linked list of struct setup_data. This is used to define a more extensible boot parameters passing mechanism. The definition of struct setup_data is as follow: struct setup_data { u64 next; u32 type; u32 len; u8 data[0]; }; Where, the next is a 64-bit physical pointer to the next node of linked list, the next field of the last node is 0; the type is used to identify the contents of data; the len is the length of data field; the data holds the real payload. This list may be modified at a number of points during the bootup process. Therefore, when modifying this list one should always make sure to consider the case where the linked list already contains entries. **** THE IMAGE CHECKSUM **** THE IMAGE CHECKSUM From boot protocol version 2.08 onwards the CRC-32 is calculated over From boot protocol version 2.08 onwards the CRC-32 is calculated over Loading @@ -553,6 +587,7 @@ initial remainder of 0xffffffff. The checksum is appended to the file; therefore the CRC of the file up to the limit specified in the file; therefore the CRC of the file up to the limit specified in the syssize field of the header is always 0. syssize field of the header is always 0. **** THE KERNEL COMMAND LINE **** THE KERNEL COMMAND LINE The kernel command line has become an important way for the boot The kernel command line has become an important way for the boot Loading Loading @@ -584,28 +619,6 @@ command line is entered using the following protocol: covered by setup_move_size, so you may need to adjust this covered by setup_move_size, so you may need to adjust this field. field. Field name: setup_data Type: write (obligatory) Offset/size: 0x250/8 Protocol: 2.09+ The 64-bit physical pointer to NULL terminated single linked list of struct setup_data. This is used to define a more extensible boot parameters passing mechanism. The definition of struct setup_data is as follow: struct setup_data { u64 next; u32 type; u32 len; u8 data[0]; }; Where, the next is a 64-bit physical pointer to the next node of linked list, the next field of the last node is 0; the type is used to identify the contents of data; the len is the length of data field; the data holds the real payload. **** MEMORY LAYOUT OF THE REAL-MODE CODE **** MEMORY LAYOUT OF THE REAL-MODE CODE Loading Documentation/i386/usb-legacy-support.txt→Documentation/x86/i386/usb-legacy-support.txt +0 −0 File moved. View file Documentation/i386/zero-page.txt→Documentation/x86/i386/zero-page.txt +0 −0 File moved. View file Documentation/x86_64/00-INDEX→Documentation/x86/x86_64/00-INDEX +0 −0 File moved. View file Loading
Documentation/i386/boot.txt→Documentation/x86/i386/boot.txt +46 −33 Original line number Original line Diff line number Diff line THE LINUX/I386 BOOT PROTOCOL THE LINUX/x86 BOOT PROTOCOL ---------------------------- --------------------------- H. Peter Anvin <hpa@zytor.com> On the x86 platform, the Linux kernel uses a rather complicated boot Last update 2007-05-23 On the i386 platform, the Linux kernel uses a rather complicated boot convention. This has evolved partially due to historical aspects, as convention. This has evolved partially due to historical aspects, as well as the desire in the early days to have the kernel itself be a well as the desire in the early days to have the kernel itself be a bootable image, the complicated PC memory model and due to changed bootable image, the complicated PC memory model and due to changed expectations in the PC industry caused by the effective demise of expectations in the PC industry caused by the effective demise of real-mode DOS as a mainstream operating system. real-mode DOS as a mainstream operating system. Currently, the following versions of the Linux/i386 boot protocol exist. Currently, the following versions of the Linux/x86 boot protocol exist. Old kernels: zImage/Image support only. Some very early kernels Old kernels: zImage/Image support only. Some very early kernels may not even support a command line. may not even support a command line. Loading Loading @@ -372,10 +369,17 @@ Protocol: 2.00+ - If 0, the protected-mode code is loaded at 0x10000. - If 0, the protected-mode code is loaded at 0x10000. - If 1, the protected-mode code is loaded at 0x100000. - If 1, the protected-mode code is loaded at 0x100000. Bit 5 (write): QUIET_FLAG - If 0, print early messages. - If 1, suppress early messages. This requests to the kernel (decompressor and early kernel) to not write early messages that require accessing the display hardware directly. Bit 6 (write): KEEP_SEGMENTS Bit 6 (write): KEEP_SEGMENTS Protocol: 2.07+ Protocol: 2.07+ - if 0, reload the segment registers in the 32bit entry point. - If 0, reload the segment registers in the 32bit entry point. - if 1, do not reload the segment registers in the 32bit entry point. - If 1, do not reload the segment registers in the 32bit entry point. Assume that %cs %ds %ss %es are all set to flat segments with Assume that %cs %ds %ss %es are all set to flat segments with a base of 0 (or the equivalent for their environment). a base of 0 (or the equivalent for their environment). Loading Loading @@ -504,7 +508,7 @@ Protocol: 2.06+ maximum size was 255. maximum size was 255. Field name: hardware_subarch Field name: hardware_subarch Type: write Type: write (optional, defaults to x86/PC) Offset/size: 0x23c/4 Offset/size: 0x23c/4 Protocol: 2.07+ Protocol: 2.07+ Loading @@ -520,11 +524,13 @@ Protocol: 2.07+ 0x00000002 Xen 0x00000002 Xen Field name: hardware_subarch_data Field name: hardware_subarch_data Type: write Type: write (subarch-dependent) Offset/size: 0x240/8 Offset/size: 0x240/8 Protocol: 2.07+ Protocol: 2.07+ A pointer to data that is specific to hardware subarch A pointer to data that is specific to hardware subarch This field is currently unused for the default x86/PC environment, do not modify. Field name: payload_offset Field name: payload_offset Type: read Type: read Loading @@ -545,6 +551,34 @@ Protocol: 2.08+ The length of the payload. The length of the payload. Field name: setup_data Type: write (special) Offset/size: 0x250/8 Protocol: 2.09+ The 64-bit physical pointer to NULL terminated single linked list of struct setup_data. This is used to define a more extensible boot parameters passing mechanism. The definition of struct setup_data is as follow: struct setup_data { u64 next; u32 type; u32 len; u8 data[0]; }; Where, the next is a 64-bit physical pointer to the next node of linked list, the next field of the last node is 0; the type is used to identify the contents of data; the len is the length of data field; the data holds the real payload. This list may be modified at a number of points during the bootup process. Therefore, when modifying this list one should always make sure to consider the case where the linked list already contains entries. **** THE IMAGE CHECKSUM **** THE IMAGE CHECKSUM From boot protocol version 2.08 onwards the CRC-32 is calculated over From boot protocol version 2.08 onwards the CRC-32 is calculated over Loading @@ -553,6 +587,7 @@ initial remainder of 0xffffffff. The checksum is appended to the file; therefore the CRC of the file up to the limit specified in the file; therefore the CRC of the file up to the limit specified in the syssize field of the header is always 0. syssize field of the header is always 0. **** THE KERNEL COMMAND LINE **** THE KERNEL COMMAND LINE The kernel command line has become an important way for the boot The kernel command line has become an important way for the boot Loading Loading @@ -584,28 +619,6 @@ command line is entered using the following protocol: covered by setup_move_size, so you may need to adjust this covered by setup_move_size, so you may need to adjust this field. field. Field name: setup_data Type: write (obligatory) Offset/size: 0x250/8 Protocol: 2.09+ The 64-bit physical pointer to NULL terminated single linked list of struct setup_data. This is used to define a more extensible boot parameters passing mechanism. The definition of struct setup_data is as follow: struct setup_data { u64 next; u32 type; u32 len; u8 data[0]; }; Where, the next is a 64-bit physical pointer to the next node of linked list, the next field of the last node is 0; the type is used to identify the contents of data; the len is the length of data field; the data holds the real payload. **** MEMORY LAYOUT OF THE REAL-MODE CODE **** MEMORY LAYOUT OF THE REAL-MODE CODE Loading
Documentation/i386/usb-legacy-support.txt→Documentation/x86/i386/usb-legacy-support.txt +0 −0 File moved. View file
