x86 boot: 32-bit boot protocol
cover x86 boot: 32-bit boot protocol
This patchset defines a 32-bit boot protocol for x86 platform, adds an extensible boot parameter passing mechanism, export the boot parameters via sysfs.
The patchset has been tested against kernel of git version v2.6.23-6623-g55b70a0 on x86_64 and i386.
This patchset is based on the proposal of Peter Anvin.
v6:
- The linked list of setup_data is copied to memory area right after the kernel _end during early kernel bootstrap to solve the issue that where the safe place is to place linked list of setup_data.
v5:
- Use bt_ioremap/bt_iounmap in copy_setup_data.
v4:
- Reserve setup_data and boot parameters for accessing during runtime.
- Export boot parameters via sysfs.
v3:
- Move hd0_info and hd1_info back to zero page for compatibility.
v2:
- Increase the boot protocol version number
- Check version number before parsing setup data.
- Revise zero page description according to the source code and move them to zero-page.txt.
Best Regards,
Huang Ying
Quoted 7 lines · Ying
This patchset defines a 32-bit boot protocol for x86 platform, adds an extensible boot parameter passing mechanism, export the boot parameters via sysfs.
The patchset has been tested against kernel of git version v2.6.23-6623-g55b70a0 on
x86_64and i386.
Hi Huang,
This patchset should be rebased on top of Rusty's changes; the rebase is
fairly trivial and I was originally intending to simply commit the
rebase as-is, with the boot protocol version bumped to 2.08.
However, the documentation section is simply wrong in a number of places. In particular:
+In 32-bit boot protocol, the first step in loading a Linux kernel +should still be to load the real-mode code and then examine the kernel +header at offset 0x01f1. But, it is not necessary to load all +real-mode code, just first 4K bytes traditionally known as "zero page" +is needed.
This is incorrect. The zeropage (which really is better referred to as struct boot_param) should be initialized to all zero, except for the setup header (starting at offset 0x1f0 or 0x1f1(*)) to the length specified either by boot protocol version or by the byte at offset 0x201.
+At entry, the CPU must be in 32-bit protected mode with paging +disabled; the CS and DS must be 4G flat segments; %esi holds the base +address of the "zero page"; %esp, %ebp, %edi should be zero.
You also need to have a GDT loaded with the selectors for __BOOT_CS (0x10) and __BOOT_DS (0x18) containing appropriate values, and you should enter with interrupts disabled. For safety, set up ES and SS as well as DS.
The bit about %esp, %ebp and %edi being zero is nonsense, although specifying at least %ebp == %edi == 0 for future use isn't a bad idea. On the other hand, %ebx *is* supposed to be zero.
The documentation in zero-page.txt is wrong when it comes to protocol versions. Most of these fields are ancient, and only a handful of the remainder can be tied to specific protocol versions.
+ struct setup_data {
+ u64 next; + u32 type; + u32 len; + u8 data[0];
+ } __attribute__((packed));
Why packed?
Time permitting, I might rewrite this myself, but it may be quicker for you to update it.
-hpa
Hi, Peter,
Quoted 13 lines · H. Peter Anvin
This patchset should be rebased on top of Rusty's changes; the rebase is
fairly trivial and I was originally intending to simply commit the
rebase as-is, with the boot protocol version bumped to 2.08.However, the documentation section is simply wrong in a number of places. In particular:
(quoted diff) +5
-0+In 32-bit boot protocol, the first step in loading a Linux kernel +should still be to load the real-mode code and then examine the kernel +header at offset 0x01f1. But, it is not necessary to load all +real-mode code, just first 4K bytes traditionally known as "zero page" +is needed.
Quoted 4 lines
This is incorrect. The zeropage (which really is better referred to as struct
boot_param) should be initialized to all zero, except for the setup header (starting at offset0x1f0or 0x1f1(*)) to the length specified either by boot protocol version or by the byte at offset0x201.
I will change this.
Quoted 4 lines
(quoted diff) +3
-0+At entry, the CPU must be in 32-bit protected mode with paging +disabled; the CS and DS must be 4G flat segments; %esi holds the base +address of the "zero page"; %esp, %ebp, %edi should be zero.
Quoted 8 lines
You also need to have a GDT loaded with the selectors for
__BOOT_CS(0x10) and__BOOT_DS(0x18) containing appropriate values, and you should enter with interrupts disabled. For safety, set up ES and SS as well as DS.The bit about %esp, %ebp and %edi being zero is nonsense, although specifying at least %ebp == %edi == 0 for future use isn't a bad idea. On the other hand, %ebx *is* supposed to be zero.
I will change this.
Quoted 3 lines
The documentation in zero-page.txt is wrong when it comes to protocol versions. Most of these fields are ancient, and only a handful of the remainder can be tied to specific protocol versions.
So, should the protocol of current fields be set to "ALL" as that of setup header.
Quoted 8 lines
(quoted diff) +6
-0+ struct setup_data { + u64 next; + u32 type; + u32 len; + u8 data[0]; + } __attribute__((packed));Why packed?
I will change this.
Quoted 2 lines
Time permitting, I might rewrite this myself, but it may be quicker for you to update it.
OK, I will update it as soon as possible.
Best Regards,
Huang Ying