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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
