U-Boot 2020.07 seems confused by valid GPT partition tables

[Tom Rini]

On Wed, Nov 04, 2020 at 11:19:47AM -0500, Dennis Clarke wrote:

> 
> I am trying to boot a reasonable qemu instance that was running for
> about a dozen hours.  I have four qemu raw disk images which have
> valid GPT partition labels and filesystem regions therein thus :
[snip]
> Device 0: QEMU VirtIO Block Device
>             Type: Hard Disk
>             Capacity: 5152.5 MB = 5.0 GB (10552349 x 512)
> ... is now current device
> Scanning virtio 0:1...
> ** Unable to read file / **
> Found EFI removable media binary efi/boot/bootriscv64.efi
> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
> Scanning disk virtio-blk#1...
> ** Unrecognized filesystem type **
> ** Unrecognized filesystem type **
> Scanning disk virtio-blk#2...
> Unhandled exception: Store/AMO access fault
> EPC: 00000000fff6f9fa TVAL: 0000000000000018
> ### ERROR ### Please RESET the board ###
> qemu-system-riscv64: terminating on signal 1 from pid 9968 (-bash)
> deimos_rv64gc$
> deimos_rv64gc$
> 
> Is there an update to u-boot that recognizes the valid GPT partition
> labels ?

It's unclear to me how those disk images end up being presented, but
there's not enough information in the logs either to debug the issue.
You should try the latest, and see if the problem is still there, and if
it is, start adding some more prints to the gpt code to see where things
are failing.  There's a number of debug() statements currently that
might shed some light on what's going on.  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20201104/bfcc562d/attachment-0001.sig>