Sorry, every time I look at this gpt stuff, my eyes stumble
over something new ...
On Tue, 30 Jun 2015 16:31:21 +0530
Nikunj A Dadhania <nik...@linux.vnet.ibm.com> wrote:
> For a GPT+LVM combination disk, older bootloader that does not support
> LVM, cannot load kernel from LVM.
>
> The patch adds support to read from BASIC_DATA UUID partitions for the
> case that the OS installer has installed the CHRP-BOOT config on a FAT
> file system.
>
> Makes GPT detection robust
> * Check for Protective MBR Magic
> * Check for valid GPT Signature
> * Boundary check for allocated block size before reading into the
> buffer
>
> Signed-off-by: Nikunj A Dadhania <nik...@linux.vnet.ibm.com>
> ---
> slof/fs/packages/disk-label.fs | 99
> +++++++++++++++++++++++++++++++++---------
> 1 file changed, 79 insertions(+), 20 deletions(-)
>
> diff --git a/slof/fs/packages/disk-label.fs b/slof/fs/packages/disk-label.fs
> index 347dc5d..5267ddb 100644
> --- a/slof/fs/packages/disk-label.fs
> +++ b/slof/fs/packages/disk-label.fs
...
> +\ The routine checks whether the protective MBR has GPT ID and then
> +\ reads the gpt data from the sector. Also set the seek position and
> +\ the partition size used in caller routines.
> +
> +: get-gpt-partition ( -- true|false )
> + no-gpt? IF false EXIT THEN
> + debug-disk-label? IF cr ." GPT partition found " cr THEN
> + 1 read-disk-buf
> + disk-buf gpt>part-entry-lba x@-le
> block-size * to seek-pos
> disk-buf gpt>part-entry-size l@-le to gpt-part-size
> - disk-buf gpt>num-part-entry l@-le dup 0= IF false EXIT THEN
> + gpt-part-size disk-buf-size > IF
> + cr ." GPT part size exceeds buffer allocated " cr
> + false exit
> + THEN
> + disk-buf gpt>signature x@ GPT-SIGNATURE =
> +;
> +
> +: load-from-gpt-prep-partition ( addr -- size )
> + get-gpt-partition 0= IF false EXIT THEN
> + disk-buf gpt>num-part-entry l@-le dup 0= IF false exit THEN
> 1+ 1 ?DO
> seek-pos 0 seek drop
> disk-buf gpt-part-size read drop gpt-prep-partition? IF
> - debug-disk-label? IF
> - ." GPT PReP partition found " cr
> - THEN
> - disk-buf gpt-part-entry>first-lba x@-le
> - disk-buf gpt-part-entry>last-lba x@-le
> - over - 1+ ( addr offset len )
> - swap ( addr len offset )
> - block-size * to part-offset
> - 0 0 seek drop ( addr len )
> - block-size * read ( size )
> + debug-disk-label? IF ." GPT PReP partition found " cr THEN
> + disk-buf gpt-part-entry>first-lba x@-le ( addr first-lba )
> + disk-buf gpt-part-entry>last-lba x@-le ( addr first-lba last-lba)
> + over - 1+ ( addr first-lba blocks )
> + swap ( addr blocks first-lba )
> + block-size * to part-offset ( addr blocks )
> + 0 0 seek drop ( addr blocks )
> + block-size * read ( size )
> + UNLOOP EXIT
> + THEN
> + seek-pos gpt-part-size i * + to seek-pos
Is this the right way to update the seek pos? Looks somewhat suspicious
to me, shouldn't this rather be:
seek-pos gpt-part-size + to seek-pos
or maybe if you store the base value somewhere instead, something like:
seek-pos-base gpt-part-size i * + to seek-pos
?
> + LOOP
> + false
> +;
> +
> +: try-gpt-dos-partition ( -- true|false )
> + get-gpt-partition 0= IF false EXIT THEN
> + disk-buf gpt>num-part-entry l@-le dup 0= IF false EXIT THEN
> + 1+ 1 ?DO
> + seek-pos 0 seek drop
> + disk-buf gpt-part-size read drop
> + gpt-basic-data-partition? IF
> + debug-disk-label? IF ." GPT BASIC DATA partition found " cr THEN
> + disk-buf gpt-part-entry>first-lba x@-le ( first-lba )
> + dup to part-start ( first-lba )
> + disk-buf gpt-part-entry>last-lba x@-le ( first-lba last-lba )
> + over - 1+ ( first-lba s1 )
> + block-size * to part-size ( first-lba )
> + block-size * to part-offset ( )
> + 0 0 seek drop
> + disk-buf block-size read drop
> + disk-buf fat-bootblock? ( true|false )
> UNLOOP EXIT
> THEN
> seek-pos gpt-part-size i * + to seek-pos
dito (so this bug was likely there before?)
Thomas
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
