[PATCH SLOF] disk-label: add support for booting from GPT FAT partition

[Thomas Huth]

On Wed, 17 Jun 2015 17:34:13 +0530
Nikunj A Dadhania <nikunj at linux.vnet.ibm.com> wrote:

> Nikunj A Dadhania <nikunj at linux.vnet.ibm.com> writes:
> 
> > Thomas Huth <thuth at redhat.com> writes:
> >>> +\ Check for GPT MSFT BASIC DATA GUID - vfat based
> >>> +EBD0A0A2     CONSTANT GPT-BASIC-DATA-PARTITION-1
> >>> +B9E5         CONSTANT GPT-BASIC-DATA-PARTITION-2
> >>> +4433         CONSTANT GPT-BASIC-DATA-PARTITION-3
> >>> +87C0         CONSTANT GPT-BASIC-DATA-PARTITION-4
> >>> +68B6B72699C7 CONSTANT GPT-BASIC-DATA-PARTITION-5
> >>> +
> >>> +: gpt-basic-data-partition? ( -- true|false )
> >>> +   block gpt-part-entry>part-type-guid l at -le GPT-BASIC-DATA-PARTITION-1 = IF
> >>> +      block gpt-part-entry>part-type-guid 4 + w at -le
> >>> +      GPT-BASIC-DATA-PARTITION-2 = IF
> >>> +         block gpt-part-entry>part-type-guid 6 + w at -le
> >>> +         GPT-BASIC-DATA-PARTITION-3 = IF
> >>> +            block gpt-part-entry>part-type-guid 8 + w@
> >>
> >> Don't you have to byte-swap (w at -le) here, too? Looks somehow strange
> >> that the other UID parts are read byte-swapped but this one is not?
> >
> > Interesting observation, I had used code from gpt-prep-partition? and
> > did not doubt the validity of it. But that is how I see it in the memory
> > though.
> >
> > 4 >  7e50d000 10 dump 
> > 7e50d000: a2 a0 d0 eb e5 b9 33 44 87 c0 68 b6 b7 26 99 c7  ......3D..h..&.. ok
> > 4 >
> 
> And here the answer for that:
> 
>     https://en.wikipedia.org/wiki/GUID_Partition_Table#cite_note-26
>     
>     The GUIDs in this table are written assuming a little-endian byte
>     order. For example, the GUID for an EFI System partition is written
>     as C12A7328-F81F-11D2-BA4B-00A0C93EC93B here, which corresponds to
>     the 16 byte sequence 28h 73h 2Ah C1h 1Fh F8h D2h 11h BAh 4Bh 00h A0h
>     C9h 3Eh C9h 3Bh – only the first three blocks are byte-swapped.
> 
> "only the first three blocks are byte-swapped"

Ok, this seems to be a GUID specialty (as opposed to UUIDs), also see:

https://en.wikipedia.org/wiki/Globally_unique_identifier#Binary_encoding

... but that means that the last 8 bytes are always "big endian", so I
think you could simplify your code here and check the last 8 bytes at
once instead of checking 2 + 6 bytes separately, can't you?

 Thomas