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

[Nikunj A Dadhania]

Thomas Huth <thuth at redhat.com> writes:

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

Yes, I am making these changes, will be sending the series after
testing.

Regards
Nikunj