bug-grub
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Convention of the internal partitioning format (0xff00ff, etc...)


From: Yoshinori K. Okuji
Subject: Re: Convention of the internal partitioning format (0xff00ff, etc...)
Date: Fri, 23 Nov 2001 01:03:36 +0900
User-agent: Wanderlust/2.6.0 (Twist And Shout) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (Unebigoryoae) APEL/10.3 Emacs/20.7 (i686-pc-linux-gnu) MULE/4.0 (HANANOEN)

At Thu, 22 Nov 2001 09:45:57 +0100,
Christoph Plattner wrote:
> What is the last 0xff for ?

The manual in the original GRUB distribution (i.e. 0.5) says:

   --  at offset 0x8 :  "install_partition"

        This is an unsigned long representing the partition on the currently
        booted disk which GRUB should expect to find it's data files and
        treat as the default root partition.

        The format of is exactly the same as the "partition" part (the "disk"
        part is ignored) of the data passed to an OS by a Multiboot-compliant
        bootloader in the "boot_device" data element, with one exception.

        The exception is that if the first level of disk partitioning is
        left as 0xFF (decimal 255, which is marked as no partitioning being
        used), but the second level does have a partition number, it looks
        for the first BSD-style PC partition, and finds the numbered BSD
        sub-partition in it.  The default "install_partition" 0xFF00FF,
        would then find the first BSD-style PC partition, and use the "a"
        partition in it, and 0xFF01FF would use the "b" partition, etc.

        If an explicit first-level partition is given, then no search is
        performed, and it will expect that the BSD-style PC partition is
        in the appropriate location, else a "no such partition" error will
        be returned.

I don't quote the relevant part of the Multiboot Specification, as I
assume you should have it within your computer.

I'm not sure why this information was lost... Probably because I
reorganized Stage 1, so Stage 1 doesn't possess INSTALL_PARTITION any
longer. I'll fix the documentation later.

> What is the point that the MSB (byte) 0xff is written to disk, but
> inside
> the code the byte must be 0x00, otherwise code lines as
> 
>       part_nr = installed_partition >> 16
> 
> cannot work !!

You mistake the notation for human from the internal representation,
that is, the x86 processor family uses little-endian, so the 0xff is
LSB but not MSB.

Okuji



reply via email to

[Prev in Thread] Current Thread [Next in Thread]