[PATCH -v6 0/3] x86 boot: 32-bit boot protocol

[PATCH -v6 0/3] x86 boot: 32-bit boot protocol

[Huang, 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_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

Re: [PATCH -v6 0/3] x86 boot: 32-bit boot protocol

[H. Peter Anvin]

Huang, Ying wrote:
> 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.
> 

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

Re: [PATCH -v6 0/3] x86 boot: 32-bit boot protocol

[Huang, Ying]

Hi, Peter,

On Mon, 2007-10-22 at 11:42 -0700, H. Peter Anvin wrote:
> 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.

I will change this.

> +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.

I will change this.

> 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.

> +  struct setup_data {
> +	  u64 next;
> +	  u32 type;
> +	  u32 len;
> +	  u8  data[0];
> +  } __attribute__((packed));
> 
> Why packed?

I will change this.

> 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