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

[Christoph Plattner]

Hello,
thanks for the answer, but the text below, I had read, but definitly
misunderstood
things. I found that text under internals in a GRUB of some weeks ago.

And again I understand the xx and yy in the 0xaaxxyyzz notation.
I also understand the combimations of xx with yy=0xff and xx=0xff and
yy is the slice and the combination of xx and yy.

But I cannot understand the last 0xFF in the 32bit value (LSB(yte)) and
I have big problems with the first 0xFF, as unpartitioned can also be
coded as 0xFFFFFF (24bit) and is consistent ... or have I something 
missunderstood.

In case of xx=0xFF I have a flat disk device with no MBR (plus empty 
track where stage 1.5 can be placed in) and inside this flat disk
the slices are organized (so I think there will also be a header, which
then is on sector 0 (lba) like a MBR.

In case of xx=0,1,2,3, ... I have a parition table and a MBR (plus free
track 0) and an partitioned image. Each image may also be organized in
slices, so the first track of each partition may also have info. If
slices
are used, yy != 0xFF, otherwise the partition is flat holding a file
system.

The LSB 0xFF is for what ?

And without the 0xFF NSB(yte) I can cover all cases from unpartitioned
up
to partitions plus slices, so what are the 0xFF on MSB for ?

The description below, the thrid paragraph discusses in my oppinion the
xx not the MSB(yte).

Sorry that I ask again, but I am interested in this detail at the
moment.

With friendly regards
Christoph P.


"Yoshinori K. Okuji" wrote:
> 
> 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
> 
> _______________________________________________
> Bug-grub mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/bug-grub

-- 
-------------------------------------------------------
private:        address@hidden
company:        address@hidden