U-Boot 2020.07 seems confused by valid GPT partition tables

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 :
deimos_rv64gc$ ls -lap total 18886740 drwxr-xr-x 7 riscv riscv 4096 Nov 3 20:40 ./ drwxr-xr-x 7 root root 4096 Nov 2 16:04 ../ -rw------- 1 riscv riscv 150 Jan 8 2020 .Xauthority -rw------- 1 riscv riscv 14399 Nov 2 19:52 .bash_history -rw-r--r-- 1 riscv riscv 220 Apr 18 2019 .bash_logout -rw-r--r-- 1 riscv riscv 3984 Aug 28 2019 .bashrc drwx------ 3 riscv riscv 4096 Oct 14 2019 .config/ drwx------ 3 riscv riscv 4096 Aug 28 2019 .gnupg/ drwx------ 2 riscv riscv 4096 Nov 2 17:18 .irssi/ -rw-r--r-- 1 riscv riscv 807 Aug 28 2019 .profile drwxr-xr-x 2 riscv riscv 4096 Nov 2 19:14 .ssh/ -rw------- 1 riscv riscv 10986 Nov 3 20:09 .viminfo -rw-r--r-- 1 riscv riscv 265 Nov 18 2019 .vimrc -rw-r--r-- 1 riscv riscv 5402802688 Nov 4 12:40 FreeBSD-13.0-CURRENT-riscv-riscv64.raw -rw-r--r-- 1 riscv riscv 577 Jan 26 2020 freebsd_email_config -rw-r--r-- 1 riscv riscv 34359738368 Nov 4 12:40 freebsd_zpool_1.raw -rw-r--r-- 1 riscv riscv 34359738368 Nov 4 12:40 freebsd_zpool_2.raw -rw-r--r-- 1 riscv riscv 34359738368 Nov 4 12:40 freebsd_zpool_3.raw -rw-r--r-- 1 riscv riscv 34359738368 Nov 3 20:13 freebsd_zpool_4.raw -rw-r--r-- 1 riscv riscv 40 Dec 19 2019 pi.dat drwxr-xr-x 6 riscv riscv 4096 Nov 27 2019 qemu/ -rw-r--r-- 1 riscv riscv 22946 Nov 3 20:40 readme.mhorne -rwxr-xr-x 1 riscv riscv 1039 Nov 3 19:44 rv64imafdc.sh -rw-r--r-- 1 riscv riscv 921 Nov 19 2019 t132s -rw-r--r-- 1 riscv riscv 551064 Nov 3 17:26 u-boot-qemu-riscv64.bin deimos_rv64gc$ deimos_rv64gc$ fdisk FreeBSD-13.0-CURRENT-riscv-riscv64.raw
Welcome to fdisk (util-linux 2.33.1). Changes will remain in memory only, until you decide to write them. Be careful before using the write command.
Command (m for help): p Disk FreeBSD-13.0-CURRENT-riscv-riscv64.raw: 5 GiB, 5402802688 bytes, 10552349 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 9E0C31F4-163C-11EB-BC34-94C6911BAC8D
Device Start End Sectors Size Type FreeBSD-13.0-CURRENT-riscv-riscv64.raw1 3 66586 66584 32.5M EFI System FreeBSD-13.0-CURRENT-riscv-riscv64.raw2 66587 2163738 2097152 1G FreeBSD swap FreeBSD-13.0-CURRENT-riscv-riscv64.raw3 2163739 10552346 8388608 4G FreeBSD UFS
Command (m for help): q
deimos_rv64gc$ fdisk freebsd_zpool_1.raw
Welcome to fdisk (util-linux 2.33.1). Changes will remain in memory only, until you decide to write them. Be careful before using the write command.
Command (m for help): p Disk freebsd_zpool_1.raw: 32 GiB, 34359738368 bytes, 67108864 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: BB2C71A1-1E10-11EB-A047-D56582AA2475
Device Start End Sectors Size Type freebsd_zpool_1.raw1 2048 67106815 67104768 32G FreeBSD ZFS
Command (m for help): q
deimos_rv64gc$ fdisk freebsd_zpool_2.raw
Welcome to fdisk (util-linux 2.33.1). Changes will remain in memory only, until you decide to write them. Be careful before using the write command.
Command (m for help): p Disk freebsd_zpool_2.raw: 32 GiB, 34359738368 bytes, 67108864 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: BCB44094-1E10-11EB-A047-D56582AA2475
Device Start End Sectors Size Type freebsd_zpool_2.raw1 2048 67106815 67104768 32G FreeBSD ZFS
Command (m for help): q
deimos_rv64gc$ fdisk freebsd_zpool_2.raw
Welcome to fdisk (util-linux 2.33.1). Changes will remain in memory only, until you decide to write them. Be careful before using the write command.
Command (m for help): p Disk freebsd_zpool_2.raw: 32 GiB, 34359738368 bytes, 67108864 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: BCB44094-1E10-11EB-A047-D56582AA2475
Device Start End Sectors Size Type freebsd_zpool_2.raw1 2048 67106815 67104768 32G FreeBSD ZFS
Command (m for help): q
deimos_rv64gc$ fdisk freebsd_zpool_3.raw
Welcome to fdisk (util-linux 2.33.1). Changes will remain in memory only, until you decide to write them. Be careful before using the write command.
Command (m for help): p Disk freebsd_zpool_3.raw: 32 GiB, 34359738368 bytes, 67108864 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: BD69AAB4-1E10-11EB-A047-D56582AA2475
Device Start End Sectors Size Type freebsd_zpool_3.raw1 2048 67106815 67104768 32G FreeBSD ZFS
Command (m for help): q
deimos_rv64gc$ fdisk freebsd_zpool_4.raw
Welcome to fdisk (util-linux 2.33.1). Changes will remain in memory only, until you decide to write them. Be careful before using the write command.
Command (m for help): p Disk freebsd_zpool_4.raw: 32 GiB, 34359738368 bytes, 67108864 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: BE1134F9-1E10-11EB-A047-D56582AA2475
Device Start End Sectors Size Type freebsd_zpool_4.raw1 2048 67106815 67104768 32G FreeBSD ZFS
Command (m for help): q
deimos_rv64gc$
However u-boot blows up with a complaint about the filesystem type ??
deimos_rv64gc$ deimos_rv64gc$ ./rv64imafdc.sh
OpenSBI v0.8 ____ _____ ____ _____ / __ \ / ____| _ _ _| | | | |_ __ ___ _ __ | (___ | |_) || | | | | | '_ \ / _ \ '_ \ ___ | _ < | | | |__| | |_) | __/ | | |____) | |_) || |_ ____/| .__/ ___|_| |_|_____/|____/_____| | | |_|
Platform Name : riscv-virtio,qemu Platform Features : timer,mfdeleg Platform HART Count : 2 Boot HART ID : 0 Boot HART ISA : rv64imafdcsu BOOT HART Features : pmp,scounteren,mcounteren,time BOOT HART PMP Count : 16 Firmware Base : 0x80000000 Firmware Size : 100 KB Runtime SBI Version : 0.2
MIDELEG : 0x0000000000000222 MEDELEG : 0x000000000000b109 PMP0 : 0x0000000080000000-0x000000008001ffff (A) PMP1 : 0x0000000000000000-0xffffffffffffffff (A,R,W,X)
U-Boot 2020.07 (Oct 25 2020 - 12:59:03 +0000)
CPU: rv64imafdcsu Model: riscv-virtio,qemu DRAM: 8 GiB In: uart@10000000 Out: uart@10000000 Err: uart@10000000 Net: Warning: virtio-net#6 using MAC address from ROM eth0: virtio-net#6 Hit any key to stop autoboot: 0
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 ?

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!
participants (2)
-
Dennis Clarke
-
Tom Rini