U-Boot v2023.01 broken on riscv64 qemu virt platform: "fdt fixup event failed"
Hello,
it looks like U-Boot v2023.01 is currently broken for the riscv64 architecture on the qemu "virt" platform; the boot process of a riscv64 VM fails during FDT fixup:
-----8<----------8<----------8<----------8<----------8<----------8<-----
OpenSBI v1.1 ____ _____ ____ _____ / __ \ / ____| _ _ _| | | | |_ __ ___ _ __ | (___ | |_) || | | | | | '_ \ / _ \ '_ \ ___ | _ < | | | |__| | |_) | __/ | | |____) | |_) || |_ ____/| .__/ ___|_| |_|_____/|____/_____| | | |_|
Platform Name : riscv-virtio,qemu Platform Features : medeleg Platform HART Count : 4 Platform IPI Device : aclint-mswi Platform Timer Device : aclint-mtimer @ 10000000Hz Platform Console Device : uart8250 Platform HSM Device : --- Platform Reboot Device : sifive_test Platform Shutdown Device : sifive_test Firmware Base : 0x80000000 Firmware Size : 312 KB Runtime SBI Version : 1.0
Domain0 Name : root Domain0 Boot HART : 2 Domain0 HARTs : 0*,1*,2*,3* Domain0 Region00 : 0x0000000002000000-0x000000000200ffff (I) Domain0 Region01 : 0x0000000080000000-0x000000008007ffff () Domain0 Region02 : 0x0000000000000000-0xffffffffffffffff (R,W,X) Domain0 Next Address : 0x0000000080200000 Domain0 Next Arg1 : 0x0000000082200000 Domain0 Next Mode : S-mode Domain0 SysReset : yes
Boot HART ID : 2 Boot HART Domain : root Boot HART Priv Version : v1.12 Boot HART Base ISA : rv64imafdch Boot HART ISA Extensions : time,sstc Boot HART PMP Count : 16 Boot HART PMP Granularity : 4 Boot HART PMP Address Bits: 54 Boot HART MHPM Count : 16 Boot HART MIDELEG : 0x0000000000001666 Boot HART MEDELEG : 0x0000000000f0b509
U-Boot 2023.01+dfsg-1 (Jan 10 2023 - 03:18:09 +0000)
CPU: rv64imafdch_zicsr_zifencei_zihintpause_zba_zbb_zbc_zbs_sstc Model: riscv-virtio,qemu DRAM: 8 GiB Core: 31 devices, 15 uclasses, devicetree: board Flash: 32 MiB Loading Environment from nowhere... OK In: serial@10000000 Out: serial@10000000 Err: serial@10000000 Net: eth0: virtio-net#2 Working FDT set to ff7344b0 Hit any key to stop autoboot: 0
Device 0: QEMU VirtIO Block Device Type: Hard Disk Capacity: 102400.0 MB = 100.0 GB (209715200 x 512) ... is now current device Scanning virtio 0:1... Found /boot/extlinux/extlinux.conf Retrieving file: /boot/extlinux/extlinux.conf U-Boot menu 1: Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 2: Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 (rescue target) 3: Debian GNU/Linux bookworm/sid 6.0.0-6-riscv64 4: Debian GNU/Linux bookworm/sid 6.0.0-6-riscv64 (rescue target) 5: Debian GNU/Linux bookworm/sid 6.0.0-5-riscv64 6: Debian GNU/Linux bookworm/sid 6.0.0-5-riscv64 (rescue target) Enter choice: 1: Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 Retrieving file: /boot/initrd.img-6.1.0-1-riscv64 Retrieving file: /boot/vmlinux-6.1.0-1-riscv64 append: root=/dev/vda1 rw noquiet Moving Image from 0x84000000 to 0x80200000, end=815e5000 ## Flattened Device Tree blob at ff7344b0 Booting using the fdt blob at 0xff7344b0 Working FDT set to ff7344b0 Using Device Tree in place at 00000000ff7344b0, end 00000000ff738dea Working FDT set to ff7344b0 ERROR: fdt fixup event failed: -22 - must RESET the board to recover.
FDT creation failed! hanging...### ERROR ### Please RESET the board ###
-----8<----------8<----------8<----------8<----------8<----------8<-----
Software versions used: - OpenSBI 1.1 (Debian package: opensbi 1.1-2) - QEMU 7.2.0 (Debian package: qemu-system-misc 1:7.2+dfsg-1+b2) - U-Boot v2023.01 (Debian package: u-boot-qemu 2023.01+dfsg-1)
The issue is independent from the kernel that gets booted. With U-Boot v2022.10 everything works without problems. I have used git bisect (with qemu-riscv64_smode_defconfig) to narrow down the specific change that triggers the issue and that has resulted in the following commit:
-----8<----------8<----------8<----------8<----------8<----------8<-----
commit a56f663f07073713042bb0fd08053aeb667e717b (HEAD) Author: Simon Glass sjg@chromium.org Date: Thu Oct 20 18:23:14 2022 -0600
vbe: Add info about the VBE device to the fwupd node
At present we put the driver in the /chosen node in U-Boot. This is a bit strange, since U-Boot doesn't normally use that node itself. It is better to put it under the bootstd node.
To make this work we need to copy create the node under /chosen when fixing up the device tree. Copy over all the properties so that fwupd knows what to do.
Update the sandbox device tree accordingly.
Signed-off-by: Simon Glass sjg@chromium.org
-----8<----------8<----------8<----------8<----------8<----------8<-----
If you should happen to run Debian/unstable, the easiest way to reproduce the problem is as follows:
$ sudo apt install qemu-system-misc opensbi u-boot-qemu
You can then either manually set up a riscv64 VM image as described at https://wiki.debian.org/RISC-V#Setting_up_a_riscv64_virtual_machine or you can use a prebuilt VM image from the Debian Quick Image Baker as described at https://people.debian.org/~gio/dqib/:
$ wget -O riscv64-virt.zip https://gitlab.com/api/v4/projects/giomasce%2Fdqib/jobs/artifacts/master/dow... $ unzip -x riscv64-virt.zip $ cd artifacts
and boot the VM image with
$ qemu-system-riscv64 -smp 4 -nographic -machine virt -m 8G -bios /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.elf -kernel /usr/lib/u-boot/qemu-riscv64_smode/u-boot.bin -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-device,rng=rng0 -append "console=ttyS0 rw root=/dev/vda1 scsi_mod.use_blk_mq=0" -device virtio-blk-device,drive=hd0 -drive file=image.qcow2,format=qcow2,id=hd0 -device virtio-net-device,netdev=usernet -netdev user,id=usernet,hostfwd=tcp::22222-:22
Regards, Karsten
On 1/11/23 20:08, Karsten Merker wrote:
Hello,
it looks like U-Boot v2023.01 is currently broken for the riscv64 architecture on the qemu "virt" platform; the boot process of a riscv64 VM fails during FDT fixup:
-----8<----------8<----------8<----------8<----------8<----------8<-----
OpenSBI v1.1 ____ _____ ____ _____ / __ \ / ____| _ _ _| | | | |_ __ ___ _ __ | (___ | |_) || | | | | | '_ \ / _ \ '_ \ ___ | _ < | | | |__| | |_) | __/ | | |____) | |_) || |_ ____/| .__/ ___|_| |_|_____/|____/_____| | | |_|
Platform Name : riscv-virtio,qemu Platform Features : medeleg Platform HART Count : 4 Platform IPI Device : aclint-mswi Platform Timer Device : aclint-mtimer @ 10000000Hz Platform Console Device : uart8250 Platform HSM Device : --- Platform Reboot Device : sifive_test Platform Shutdown Device : sifive_test Firmware Base : 0x80000000 Firmware Size : 312 KB Runtime SBI Version : 1.0
Domain0 Name : root Domain0 Boot HART : 2 Domain0 HARTs : 0*,1*,2*,3* Domain0 Region00 : 0x0000000002000000-0x000000000200ffff (I) Domain0 Region01 : 0x0000000080000000-0x000000008007ffff () Domain0 Region02 : 0x0000000000000000-0xffffffffffffffff (R,W,X) Domain0 Next Address : 0x0000000080200000 Domain0 Next Arg1 : 0x0000000082200000 Domain0 Next Mode : S-mode Domain0 SysReset : yes
Boot HART ID : 2 Boot HART Domain : root Boot HART Priv Version : v1.12 Boot HART Base ISA : rv64imafdch Boot HART ISA Extensions : time,sstc Boot HART PMP Count : 16 Boot HART PMP Granularity : 4 Boot HART PMP Address Bits: 54 Boot HART MHPM Count : 16 Boot HART MIDELEG : 0x0000000000001666 Boot HART MEDELEG : 0x0000000000f0b509
U-Boot 2023.01+dfsg-1 (Jan 10 2023 - 03:18:09 +0000)
CPU: rv64imafdch_zicsr_zifencei_zihintpause_zba_zbb_zbc_zbs_sstc Model: riscv-virtio,qemu DRAM: 8 GiB Core: 31 devices, 15 uclasses, devicetree: board Flash: 32 MiB Loading Environment from nowhere... OK In: serial@10000000 Out: serial@10000000 Err: serial@10000000 Net: eth0: virtio-net#2 Working FDT set to ff7344b0 Hit any key to stop autoboot: 0
Device 0: QEMU VirtIO Block Device Type: Hard Disk Capacity: 102400.0 MB = 100.0 GB (209715200 x 512) ... is now current device Scanning virtio 0:1... Found /boot/extlinux/extlinux.conf Retrieving file: /boot/extlinux/extlinux.conf U-Boot menu 1: Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 2: Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 (rescue target) 3: Debian GNU/Linux bookworm/sid 6.0.0-6-riscv64 4: Debian GNU/Linux bookworm/sid 6.0.0-6-riscv64 (rescue target) 5: Debian GNU/Linux bookworm/sid 6.0.0-5-riscv64 6: Debian GNU/Linux bookworm/sid 6.0.0-5-riscv64 (rescue target) Enter choice: 1: Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 Retrieving file: /boot/initrd.img-6.1.0-1-riscv64 Retrieving file: /boot/vmlinux-6.1.0-1-riscv64 append: root=/dev/vda1 rw noquiet Moving Image from 0x84000000 to 0x80200000, end=815e5000 ## Flattened Device Tree blob at ff7344b0 Booting using the fdt blob at 0xff7344b0 Working FDT set to ff7344b0 Using Device Tree in place at 00000000ff7344b0, end 00000000ff738dea Working FDT set to ff7344b0 ERROR: fdt fixup event failed: -22
- must RESET the board to recover.
FDT creation failed! hanging...### ERROR ### Please RESET the board ###
-----8<----------8<----------8<----------8<----------8<----------8<-----
Software versions used:
- OpenSBI 1.1 (Debian package: opensbi 1.1-2)
- QEMU 7.2.0 (Debian package: qemu-system-misc 1:7.2+dfsg-1+b2)
- U-Boot v2023.01 (Debian package: u-boot-qemu 2023.01+dfsg-1)
The issue is independent from the kernel that gets booted. With U-Boot v2022.10 everything works without problems. I have used git bisect (with qemu-riscv64_smode_defconfig) to narrow down the specific change that triggers the issue and that has resulted in the following commit:
-----8<----------8<----------8<----------8<----------8<----------8<-----
commit a56f663f07073713042bb0fd08053aeb667e717b (HEAD) Author: Simon Glass sjg@chromium.org Date: Thu Oct 20 18:23:14 2022 -0600
vbe: Add info about the VBE device to the fwupd node At present we put the driver in the /chosen node in U-Boot. This is a bit strange, since U-Boot doesn't normally use that node itself. It is better to put it under the bootstd node. To make this work we need to copy create the node under /chosen when fixing up the device tree. Copy over all the properties so that fwupd knows what to do. Update the sandbox device tree accordingly. Signed-off-by: Simon Glass <sjg@chromium.org>-----8<----------8<----------8<----------8<----------8<----------8<-----
If you should happen to run Debian/unstable, the easiest way to reproduce the problem is as follows:
$ sudo apt install qemu-system-misc opensbi u-boot-qemu
You can then either manually set up a riscv64 VM image as described at https://wiki.debian.org/RISC-V#Setting_up_a_riscv64_virtual_machine or you can use a prebuilt VM image from the Debian Quick Image Baker as described at https://people.debian.org/~gio/dqib/:
$ wget -O riscv64-virt.zip https://gitlab.com/api/v4/projects/giomasce%2Fdqib/jobs/artifacts/master/dow... $ unzip -x riscv64-virt.zip $ cd artifacts
and boot the VM image with
$ qemu-system-riscv64 -smp 4 -nographic -machine virt -m 8G -bios /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.elf -kernel /usr/lib/u-boot/qemu-riscv64_smode/u-boot.bin -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-device,rng=rng0 -append "console=ttyS0 rw root=/dev/vda1 scsi_mod.use_blk_mq=0" -device virtio-blk-device,drive=hd0 -drive file=image.qcow2,format=qcow2,id=hd0 -device virtio-net-device,netdev=usernet -netdev user,id=usernet,hostfwd=tcp::22222-:22
Regards, Karsten
Thanks Karsten for reporting the issue.
Bisection points to Simon's patch:
a56f663f0707371 vbe: Add info about the VBE device to the fwupd node
In bootmeth_vbe_simple_ft_fixup() probing device vbe_simple fails because all fwupd related properties are missing in the QEMU device-tree.
The following change is enough to make QEMU boot again:
CONFIG_BOOTMETH_VBE=n
@Simon:
CONFIG_BOOTMETH_VBE should default to 'no' as only the sandbox provides the required data in the devicetree. Or bootmeth_vbe_simple_ft_fixup() should ignore a failure to probe vbe_simple.
Best regards
Heinrich
() Hi Heinrich,
On Wed, 11 Jan 2023 at 16:22, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 1/11/23 20:08, Karsten Merker wrote:
Hello,
it looks like U-Boot v2023.01 is currently broken for the riscv64 architecture on the qemu "virt" platform; the boot process of a riscv64 VM fails during FDT fixup:
-----8<----------8<----------8<----------8<----------8<----------8<-----
OpenSBI v1.1 ____ _____ ____ _____ / __ \ / ____| _ _ _| | | | |_ __ ___ _ __ | (___ | |_) || | | | | | '_ \ / _ \ '_ \ ___ | _ < | | | |__| | |_) | __/ | | |____) | |_) || |_ ____/| .__/ ___|_| |_|_____/|____/_____| | | |_|
Platform Name : riscv-virtio,qemu Platform Features : medeleg Platform HART Count : 4 Platform IPI Device : aclint-mswi Platform Timer Device : aclint-mtimer @ 10000000Hz Platform Console Device : uart8250 Platform HSM Device : --- Platform Reboot Device : sifive_test Platform Shutdown Device : sifive_test Firmware Base : 0x80000000 Firmware Size : 312 KB Runtime SBI Version : 1.0
Domain0 Name : root Domain0 Boot HART : 2 Domain0 HARTs : 0*,1*,2*,3* Domain0 Region00 : 0x0000000002000000-0x000000000200ffff (I) Domain0 Region01 : 0x0000000080000000-0x000000008007ffff () Domain0 Region02 : 0x0000000000000000-0xffffffffffffffff (R,W,X) Domain0 Next Address : 0x0000000080200000 Domain0 Next Arg1 : 0x0000000082200000 Domain0 Next Mode : S-mode Domain0 SysReset : yes
Boot HART ID : 2 Boot HART Domain : root Boot HART Priv Version : v1.12 Boot HART Base ISA : rv64imafdch Boot HART ISA Extensions : time,sstc Boot HART PMP Count : 16 Boot HART PMP Granularity : 4 Boot HART PMP Address Bits: 54 Boot HART MHPM Count : 16 Boot HART MIDELEG : 0x0000000000001666 Boot HART MEDELEG : 0x0000000000f0b509
U-Boot 2023.01+dfsg-1 (Jan 10 2023 - 03:18:09 +0000)
CPU: rv64imafdch_zicsr_zifencei_zihintpause_zba_zbb_zbc_zbs_sstc Model: riscv-virtio,qemu DRAM: 8 GiB Core: 31 devices, 15 uclasses, devicetree: board Flash: 32 MiB Loading Environment from nowhere... OK In: serial@10000000 Out: serial@10000000 Err: serial@10000000 Net: eth0: virtio-net#2 Working FDT set to ff7344b0 Hit any key to stop autoboot: 0
Device 0: QEMU VirtIO Block Device Type: Hard Disk Capacity: 102400.0 MB = 100.0 GB (209715200 x 512) ... is now current device Scanning virtio 0:1... Found /boot/extlinux/extlinux.conf Retrieving file: /boot/extlinux/extlinux.conf U-Boot menu 1: Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 2: Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 (rescue target) 3: Debian GNU/Linux bookworm/sid 6.0.0-6-riscv64 4: Debian GNU/Linux bookworm/sid 6.0.0-6-riscv64 (rescue target) 5: Debian GNU/Linux bookworm/sid 6.0.0-5-riscv64 6: Debian GNU/Linux bookworm/sid 6.0.0-5-riscv64 (rescue target) Enter choice: 1: Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 Retrieving file: /boot/initrd.img-6.1.0-1-riscv64 Retrieving file: /boot/vmlinux-6.1.0-1-riscv64 append: root=/dev/vda1 rw noquiet Moving Image from 0x84000000 to 0x80200000, end=815e5000 ## Flattened Device Tree blob at ff7344b0 Booting using the fdt blob at 0xff7344b0 Working FDT set to ff7344b0 Using Device Tree in place at 00000000ff7344b0, end 00000000ff738dea Working FDT set to ff7344b0 ERROR: fdt fixup event failed: -22
- must RESET the board to recover.
FDT creation failed! hanging...### ERROR ### Please RESET the board ###
-----8<----------8<----------8<----------8<----------8<----------8<-----
Software versions used:
- OpenSBI 1.1 (Debian package: opensbi 1.1-2)
- QEMU 7.2.0 (Debian package: qemu-system-misc 1:7.2+dfsg-1+b2)
- U-Boot v2023.01 (Debian package: u-boot-qemu 2023.01+dfsg-1)
The issue is independent from the kernel that gets booted. With U-Boot v2022.10 everything works without problems. I have used git bisect (with qemu-riscv64_smode_defconfig) to narrow down the specific change that triggers the issue and that has resulted in the following commit:
-----8<----------8<----------8<----------8<----------8<----------8<-----
commit a56f663f07073713042bb0fd08053aeb667e717b (HEAD) Author: Simon Glass sjg@chromium.org Date: Thu Oct 20 18:23:14 2022 -0600
vbe: Add info about the VBE device to the fwupd node At present we put the driver in the /chosen node in U-Boot. This is a bit strange, since U-Boot doesn't normally use that node itself. It is better to put it under the bootstd node. To make this work we need to copy create the node under /chosen when fixing up the device tree. Copy over all the properties so that fwupd knows what to do. Update the sandbox device tree accordingly. Signed-off-by: Simon Glass <sjg@chromium.org>-----8<----------8<----------8<----------8<----------8<----------8<-----
If you should happen to run Debian/unstable, the easiest way to reproduce the problem is as follows:
$ sudo apt install qemu-system-misc opensbi u-boot-qemu
You can then either manually set up a riscv64 VM image as described at https://wiki.debian.org/RISC-V#Setting_up_a_riscv64_virtual_machine or you can use a prebuilt VM image from the Debian Quick Image Baker as described at https://people.debian.org/~gio/dqib/:
$ wget -O riscv64-virt.zip https://gitlab.com/api/v4/projects/giomasce%2Fdqib/jobs/artifacts/master/dow... $ unzip -x riscv64-virt.zip $ cd artifacts
and boot the VM image with
$ qemu-system-riscv64 -smp 4 -nographic -machine virt -m 8G -bios /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.elf -kernel /usr/lib/u-boot/qemu-riscv64_smode/u-boot.bin -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-device,rng=rng0 -append "console=ttyS0 rw root=/dev/vda1 scsi_mod.use_blk_mq=0" -device virtio-blk-device,drive=hd0 -drive file=image.qcow2,format=qcow2,id=hd0 -device virtio-net-device,netdev=usernet -netdev user,id=usernet,hostfwd=tcp::22222-:22
Regards, Karsten
Thanks Karsten for reporting the issue.
Bisection points to Simon's patch:
a56f663f0707371 vbe: Add info about the VBE device to the fwupd node
In bootmeth_vbe_simple_ft_fixup() probing device vbe_simple fails because all fwupd related properties are missing in the QEMU device-tree.
The following change is enough to make QEMU boot again:
CONFIG_BOOTMETH_VBE=n
@Simon:
CONFIG_BOOTMETH_VBE should default to 'no' as only the sandbox provides the required data in the devicetree. Or bootmeth_vbe_simple_ft_fixup() should ignore a failure to probe vbe_simple.
It is supposed to ignore that failure. Could it be that there is a bug in vbe_find_next_device() that it should set *devp to NULL when it doesn't find anything?
How come this failure does not show in CI?
Regards, Simon
Best regards
Heinrich
On 1/12/23 00:29, Simon Glass wrote:
() Hi Heinrich,
On Wed, 11 Jan 2023 at 16:22, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 1/11/23 20:08, Karsten Merker wrote:
Hello,
it looks like U-Boot v2023.01 is currently broken for the riscv64 architecture on the qemu "virt" platform; the boot process of a riscv64 VM fails during FDT fixup:
-----8<----------8<----------8<----------8<----------8<----------8<-----
OpenSBI v1.1 ____ _____ ____ _____ / __ \ / ____| _ _ _| | | | |_ __ ___ _ __ | (___ | |_) || | | | | | '_ \ / _ \ '_ \ ___ | _ < | | | |__| | |_) | __/ | | |____) | |_) || |_ ____/| .__/ ___|_| |_|_____/|____/_____| | | |_|
Platform Name : riscv-virtio,qemu Platform Features : medeleg Platform HART Count : 4 Platform IPI Device : aclint-mswi Platform Timer Device : aclint-mtimer @ 10000000Hz Platform Console Device : uart8250 Platform HSM Device : --- Platform Reboot Device : sifive_test Platform Shutdown Device : sifive_test Firmware Base : 0x80000000 Firmware Size : 312 KB Runtime SBI Version : 1.0
Domain0 Name : root Domain0 Boot HART : 2 Domain0 HARTs : 0*,1*,2*,3* Domain0 Region00 : 0x0000000002000000-0x000000000200ffff (I) Domain0 Region01 : 0x0000000080000000-0x000000008007ffff () Domain0 Region02 : 0x0000000000000000-0xffffffffffffffff (R,W,X) Domain0 Next Address : 0x0000000080200000 Domain0 Next Arg1 : 0x0000000082200000 Domain0 Next Mode : S-mode Domain0 SysReset : yes
Boot HART ID : 2 Boot HART Domain : root Boot HART Priv Version : v1.12 Boot HART Base ISA : rv64imafdch Boot HART ISA Extensions : time,sstc Boot HART PMP Count : 16 Boot HART PMP Granularity : 4 Boot HART PMP Address Bits: 54 Boot HART MHPM Count : 16 Boot HART MIDELEG : 0x0000000000001666 Boot HART MEDELEG : 0x0000000000f0b509
U-Boot 2023.01+dfsg-1 (Jan 10 2023 - 03:18:09 +0000)
CPU: rv64imafdch_zicsr_zifencei_zihintpause_zba_zbb_zbc_zbs_sstc Model: riscv-virtio,qemu DRAM: 8 GiB Core: 31 devices, 15 uclasses, devicetree: board Flash: 32 MiB Loading Environment from nowhere... OK In: serial@10000000 Out: serial@10000000 Err: serial@10000000 Net: eth0: virtio-net#2 Working FDT set to ff7344b0 Hit any key to stop autoboot: 0
Device 0: QEMU VirtIO Block Device Type: Hard Disk Capacity: 102400.0 MB = 100.0 GB (209715200 x 512) ... is now current device Scanning virtio 0:1... Found /boot/extlinux/extlinux.conf Retrieving file: /boot/extlinux/extlinux.conf U-Boot menu 1: Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 2: Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 (rescue target) 3: Debian GNU/Linux bookworm/sid 6.0.0-6-riscv64 4: Debian GNU/Linux bookworm/sid 6.0.0-6-riscv64 (rescue target) 5: Debian GNU/Linux bookworm/sid 6.0.0-5-riscv64 6: Debian GNU/Linux bookworm/sid 6.0.0-5-riscv64 (rescue target) Enter choice: 1: Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 Retrieving file: /boot/initrd.img-6.1.0-1-riscv64 Retrieving file: /boot/vmlinux-6.1.0-1-riscv64 append: root=/dev/vda1 rw noquiet Moving Image from 0x84000000 to 0x80200000, end=815e5000 ## Flattened Device Tree blob at ff7344b0 Booting using the fdt blob at 0xff7344b0 Working FDT set to ff7344b0 Using Device Tree in place at 00000000ff7344b0, end 00000000ff738dea Working FDT set to ff7344b0 ERROR: fdt fixup event failed: -22
- must RESET the board to recover.
FDT creation failed! hanging...### ERROR ### Please RESET the board ###
-----8<----------8<----------8<----------8<----------8<----------8<-----
Software versions used:
- OpenSBI 1.1 (Debian package: opensbi 1.1-2)
- QEMU 7.2.0 (Debian package: qemu-system-misc 1:7.2+dfsg-1+b2)
- U-Boot v2023.01 (Debian package: u-boot-qemu 2023.01+dfsg-1)
The issue is independent from the kernel that gets booted. With U-Boot v2022.10 everything works without problems. I have used git bisect (with qemu-riscv64_smode_defconfig) to narrow down the specific change that triggers the issue and that has resulted in the following commit:
-----8<----------8<----------8<----------8<----------8<----------8<-----
commit a56f663f07073713042bb0fd08053aeb667e717b (HEAD) Author: Simon Glass sjg@chromium.org Date: Thu Oct 20 18:23:14 2022 -0600
vbe: Add info about the VBE device to the fwupd node At present we put the driver in the /chosen node in U-Boot. This is a bit strange, since U-Boot doesn't normally use that node itself. It is better to put it under the bootstd node. To make this work we need to copy create the node under /chosen when fixing up the device tree. Copy over all the properties so that fwupd knows what to do. Update the sandbox device tree accordingly. Signed-off-by: Simon Glass <sjg@chromium.org>-----8<----------8<----------8<----------8<----------8<----------8<-----
If you should happen to run Debian/unstable, the easiest way to reproduce the problem is as follows:
$ sudo apt install qemu-system-misc opensbi u-boot-qemu
You can then either manually set up a riscv64 VM image as described at https://wiki.debian.org/RISC-V#Setting_up_a_riscv64_virtual_machine or you can use a prebuilt VM image from the Debian Quick Image Baker as described at https://people.debian.org/~gio/dqib/:
$ wget -O riscv64-virt.zip https://gitlab.com/api/v4/projects/giomasce%2Fdqib/jobs/artifacts/master/dow... $ unzip -x riscv64-virt.zip $ cd artifacts
and boot the VM image with
$ qemu-system-riscv64 -smp 4 -nographic -machine virt -m 8G -bios /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.elf -kernel /usr/lib/u-boot/qemu-riscv64_smode/u-boot.bin -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-device,rng=rng0 -append "console=ttyS0 rw root=/dev/vda1 scsi_mod.use_blk_mq=0" -device virtio-blk-device,drive=hd0 -drive file=image.qcow2,format=qcow2,id=hd0 -device virtio-net-device,netdev=usernet -netdev user,id=usernet,hostfwd=tcp::22222-:22
Regards, Karsten
Thanks Karsten for reporting the issue.
Bisection points to Simon's patch:
a56f663f0707371 vbe: Add info about the VBE device to the fwupd node
In bootmeth_vbe_simple_ft_fixup() probing device vbe_simple fails because all fwupd related properties are missing in the QEMU device-tree.
The following change is enough to make QEMU boot again:
CONFIG_BOOTMETH_VBE=n
@Simon:
CONFIG_BOOTMETH_VBE should default to 'no' as only the sandbox provides the required data in the devicetree. Or bootmeth_vbe_simple_ft_fixup() should ignore a failure to probe vbe_simple.
It is supposed to ignore that failure. Could it be that there is a bug in vbe_find_next_device() that it should set *devp to NULL when it doesn't find anything?
The vbe_simple device exists on qemu-riscv64_smode_defconfig but cannot be probed.
How come this failure does not show in CI?
We currently lack tests to actually start a binary via the Linux legacy entry point.
Best regards
Heinrich
Hi Heinrich,
On Wed, 11 Jan 2023 at 16:40, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 1/12/23 00:29, Simon Glass wrote:
() Hi Heinrich,
On Wed, 11 Jan 2023 at 16:22, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 1/11/23 20:08, Karsten Merker wrote:
Hello,
it looks like U-Boot v2023.01 is currently broken for the riscv64 architecture on the qemu "virt" platform; the boot process of a riscv64 VM fails during FDT fixup:
-----8<----------8<----------8<----------8<----------8<----------8<-----
OpenSBI v1.1 ____ _____ ____ _____ / __ \ / ____| _ _ _| | | | |_ __ ___ _ __ | (___ | |_) || | | | | | '_ \ / _ \ '_ \ ___ | _ < | | | |__| | |_) | __/ | | |____) | |_) || |_ ____/| .__/ ___|_| |_|_____/|____/_____| | | |_|
Platform Name : riscv-virtio,qemu Platform Features : medeleg Platform HART Count : 4 Platform IPI Device : aclint-mswi Platform Timer Device : aclint-mtimer @ 10000000Hz Platform Console Device : uart8250 Platform HSM Device : --- Platform Reboot Device : sifive_test Platform Shutdown Device : sifive_test Firmware Base : 0x80000000 Firmware Size : 312 KB Runtime SBI Version : 1.0
Domain0 Name : root Domain0 Boot HART : 2 Domain0 HARTs : 0*,1*,2*,3* Domain0 Region00 : 0x0000000002000000-0x000000000200ffff (I) Domain0 Region01 : 0x0000000080000000-0x000000008007ffff () Domain0 Region02 : 0x0000000000000000-0xffffffffffffffff (R,W,X) Domain0 Next Address : 0x0000000080200000 Domain0 Next Arg1 : 0x0000000082200000 Domain0 Next Mode : S-mode Domain0 SysReset : yes
Boot HART ID : 2 Boot HART Domain : root Boot HART Priv Version : v1.12 Boot HART Base ISA : rv64imafdch Boot HART ISA Extensions : time,sstc Boot HART PMP Count : 16 Boot HART PMP Granularity : 4 Boot HART PMP Address Bits: 54 Boot HART MHPM Count : 16 Boot HART MIDELEG : 0x0000000000001666 Boot HART MEDELEG : 0x0000000000f0b509
U-Boot 2023.01+dfsg-1 (Jan 10 2023 - 03:18:09 +0000)
CPU: rv64imafdch_zicsr_zifencei_zihintpause_zba_zbb_zbc_zbs_sstc Model: riscv-virtio,qemu DRAM: 8 GiB Core: 31 devices, 15 uclasses, devicetree: board Flash: 32 MiB Loading Environment from nowhere... OK In: serial@10000000 Out: serial@10000000 Err: serial@10000000 Net: eth0: virtio-net#2 Working FDT set to ff7344b0 Hit any key to stop autoboot: 0
Device 0: QEMU VirtIO Block Device Type: Hard Disk Capacity: 102400.0 MB = 100.0 GB (209715200 x 512) ... is now current device Scanning virtio 0:1... Found /boot/extlinux/extlinux.conf Retrieving file: /boot/extlinux/extlinux.conf U-Boot menu 1: Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 2: Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 (rescue target) 3: Debian GNU/Linux bookworm/sid 6.0.0-6-riscv64 4: Debian GNU/Linux bookworm/sid 6.0.0-6-riscv64 (rescue target) 5: Debian GNU/Linux bookworm/sid 6.0.0-5-riscv64 6: Debian GNU/Linux bookworm/sid 6.0.0-5-riscv64 (rescue target) Enter choice: 1: Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 Retrieving file: /boot/initrd.img-6.1.0-1-riscv64 Retrieving file: /boot/vmlinux-6.1.0-1-riscv64 append: root=/dev/vda1 rw noquiet Moving Image from 0x84000000 to 0x80200000, end=815e5000 ## Flattened Device Tree blob at ff7344b0 Booting using the fdt blob at 0xff7344b0 Working FDT set to ff7344b0 Using Device Tree in place at 00000000ff7344b0, end 00000000ff738dea Working FDT set to ff7344b0 ERROR: fdt fixup event failed: -22
- must RESET the board to recover.
FDT creation failed! hanging...### ERROR ### Please RESET the board ###
-----8<----------8<----------8<----------8<----------8<----------8<-----
Software versions used:
- OpenSBI 1.1 (Debian package: opensbi 1.1-2)
- QEMU 7.2.0 (Debian package: qemu-system-misc 1:7.2+dfsg-1+b2)
- U-Boot v2023.01 (Debian package: u-boot-qemu 2023.01+dfsg-1)
The issue is independent from the kernel that gets booted. With U-Boot v2022.10 everything works without problems. I have used git bisect (with qemu-riscv64_smode_defconfig) to narrow down the specific change that triggers the issue and that has resulted in the following commit:
-----8<----------8<----------8<----------8<----------8<----------8<-----
commit a56f663f07073713042bb0fd08053aeb667e717b (HEAD) Author: Simon Glass sjg@chromium.org Date: Thu Oct 20 18:23:14 2022 -0600
vbe: Add info about the VBE device to the fwupd node At present we put the driver in the /chosen node in U-Boot. This is a bit strange, since U-Boot doesn't normally use that node itself. It is better to put it under the bootstd node. To make this work we need to copy create the node under /chosen when fixing up the device tree. Copy over all the properties so that fwupd knows what to do. Update the sandbox device tree accordingly. Signed-off-by: Simon Glass <sjg@chromium.org>-----8<----------8<----------8<----------8<----------8<----------8<-----
If you should happen to run Debian/unstable, the easiest way to reproduce the problem is as follows:
$ sudo apt install qemu-system-misc opensbi u-boot-qemu
You can then either manually set up a riscv64 VM image as described at https://wiki.debian.org/RISC-V#Setting_up_a_riscv64_virtual_machine or you can use a prebuilt VM image from the Debian Quick Image Baker as described at https://people.debian.org/~gio/dqib/:
$ wget -O riscv64-virt.zip https://gitlab.com/api/v4/projects/giomasce%2Fdqib/jobs/artifacts/master/dow... $ unzip -x riscv64-virt.zip $ cd artifacts
and boot the VM image with
$ qemu-system-riscv64 -smp 4 -nographic -machine virt -m 8G -bios /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.elf -kernel /usr/lib/u-boot/qemu-riscv64_smode/u-boot.bin -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-device,rng=rng0 -append "console=ttyS0 rw root=/dev/vda1 scsi_mod.use_blk_mq=0" -device virtio-blk-device,drive=hd0 -drive file=image.qcow2,format=qcow2,id=hd0 -device virtio-net-device,netdev=usernet -netdev user,id=usernet,hostfwd=tcp::22222-:22
Regards, Karsten
Thanks Karsten for reporting the issue.
Bisection points to Simon's patch:
a56f663f0707371 vbe: Add info about the VBE device to the fwupd node
In bootmeth_vbe_simple_ft_fixup() probing device vbe_simple fails because all fwupd related properties are missing in the QEMU device-tree.
The following change is enough to make QEMU boot again:
CONFIG_BOOTMETH_VBE=n
@Simon:
CONFIG_BOOTMETH_VBE should default to 'no' as only the sandbox provides the required data in the devicetree. Or bootmeth_vbe_simple_ft_fixup() should ignore a failure to probe vbe_simple.
It is supposed to ignore that failure. Could it be that there is a bug in vbe_find_next_device() that it should set *devp to NULL when it doesn't find anything?
The vbe_simple device exists on qemu-riscv64_smode_defconfig but cannot be probed.
OK, so setting *devp = NULL before the last 'return 0' might help?
How come this failure does not show in CI?
We currently lack tests to actually start a binary via the Linux legacy entry point.
Ah OK, so the fixup never runs.
Regards, Simon
On 1/12/23 00:42, Simon Glass wrote:
Hi Heinrich,
<snip />
Thanks Karsten for reporting the issue.
Bisection points to Simon's patch:
a56f663f0707371 vbe: Add info about the VBE device to the fwupd node
In bootmeth_vbe_simple_ft_fixup() probing device vbe_simple fails because all fwupd related properties are missing in the QEMU device-tree.
The following change is enough to make QEMU boot again:
CONFIG_BOOTMETH_VBE=n
@Simon:
CONFIG_BOOTMETH_VBE should default to 'no' as only the sandbox provides the required data in the devicetree. Or bootmeth_vbe_simple_ft_fixup() should ignore a failure to probe vbe_simple.
It is supposed to ignore that failure. Could it be that there is a bug in vbe_find_next_device() that it should set *devp to NULL when it doesn't find anything?
The vbe_simple device exists on qemu-riscv64_smode_defconfig but cannot be probed.
OK, so setting *devp = NULL before the last 'return 0' might help?
It is not clear to me what you want to change. Could you send a patch for testing, please.
You can start qemu-riscv64_smode_defconfig on QEMU 7.0 or higher with
qemu-system-riscv64 \ -machine virt -nographic -m 2048 -smp 4 \ -kernel u-boot.bin \ -device virtio-net-device,netdev=eth0 -netdev user,id=eth0 \ -drive file=disk.img,format=raw,if=virtio
You could use this disk image: https://cdimage.ubuntu.com/releases/22.10/release/ubuntu-22.10-preinstalled-... after extraction.
Best regards
Heinrich
How come this failure does not show in CI?
We currently lack tests to actually start a binary via the Linux legacy entry point.
Ah OK, so the fixup never runs.
Regards, Simon
On Thu, Jan 12, 2023 at 12:40:05AM +0100, Heinrich Schuchardt wrote:
On 1/12/23 00:29, Simon Glass wrote:
() Hi Heinrich,
On Wed, 11 Jan 2023 at 16:22, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 1/11/23 20:08, Karsten Merker wrote:
Hello,
it looks like U-Boot v2023.01 is currently broken for the riscv64 architecture on the qemu "virt" platform; the boot process of a riscv64 VM fails during FDT fixup:
-----8<----------8<----------8<----------8<----------8<----------8<-----
OpenSBI v1.1 ____ _____ ____ _____ / __ \ / ____| _ _ _| | | | |_ __ ___ _ __ | (___ | |_) || | | | | | '_ \ / _ \ '_ \ ___ | _ < | | | |__| | |_) | __/ | | |____) | |_) || |_ ____/| .__/ ___|_| |_|_____/|____/_____| | | |_|
Platform Name : riscv-virtio,qemu Platform Features : medeleg Platform HART Count : 4 Platform IPI Device : aclint-mswi Platform Timer Device : aclint-mtimer @ 10000000Hz Platform Console Device : uart8250 Platform HSM Device : --- Platform Reboot Device : sifive_test Platform Shutdown Device : sifive_test Firmware Base : 0x80000000 Firmware Size : 312 KB Runtime SBI Version : 1.0
Domain0 Name : root Domain0 Boot HART : 2 Domain0 HARTs : 0*,1*,2*,3* Domain0 Region00 : 0x0000000002000000-0x000000000200ffff (I) Domain0 Region01 : 0x0000000080000000-0x000000008007ffff () Domain0 Region02 : 0x0000000000000000-0xffffffffffffffff (R,W,X) Domain0 Next Address : 0x0000000080200000 Domain0 Next Arg1 : 0x0000000082200000 Domain0 Next Mode : S-mode Domain0 SysReset : yes
Boot HART ID : 2 Boot HART Domain : root Boot HART Priv Version : v1.12 Boot HART Base ISA : rv64imafdch Boot HART ISA Extensions : time,sstc Boot HART PMP Count : 16 Boot HART PMP Granularity : 4 Boot HART PMP Address Bits: 54 Boot HART MHPM Count : 16 Boot HART MIDELEG : 0x0000000000001666 Boot HART MEDELEG : 0x0000000000f0b509
U-Boot 2023.01+dfsg-1 (Jan 10 2023 - 03:18:09 +0000)
CPU: rv64imafdch_zicsr_zifencei_zihintpause_zba_zbb_zbc_zbs_sstc Model: riscv-virtio,qemu DRAM: 8 GiB Core: 31 devices, 15 uclasses, devicetree: board Flash: 32 MiB Loading Environment from nowhere... OK In: serial@10000000 Out: serial@10000000 Err: serial@10000000 Net: eth0: virtio-net#2 Working FDT set to ff7344b0 Hit any key to stop autoboot: 0
Device 0: QEMU VirtIO Block Device Type: Hard Disk Capacity: 102400.0 MB = 100.0 GB (209715200 x 512) ... is now current device Scanning virtio 0:1... Found /boot/extlinux/extlinux.conf Retrieving file: /boot/extlinux/extlinux.conf U-Boot menu 1: Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 2: Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 (rescue target) 3: Debian GNU/Linux bookworm/sid 6.0.0-6-riscv64 4: Debian GNU/Linux bookworm/sid 6.0.0-6-riscv64 (rescue target) 5: Debian GNU/Linux bookworm/sid 6.0.0-5-riscv64 6: Debian GNU/Linux bookworm/sid 6.0.0-5-riscv64 (rescue target) Enter choice: 1: Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 Retrieving file: /boot/initrd.img-6.1.0-1-riscv64 Retrieving file: /boot/vmlinux-6.1.0-1-riscv64 append: root=/dev/vda1 rw noquiet Moving Image from 0x84000000 to 0x80200000, end=815e5000 ## Flattened Device Tree blob at ff7344b0 Booting using the fdt blob at 0xff7344b0 Working FDT set to ff7344b0 Using Device Tree in place at 00000000ff7344b0, end 00000000ff738dea Working FDT set to ff7344b0 ERROR: fdt fixup event failed: -22
- must RESET the board to recover.
FDT creation failed! hanging...### ERROR ### Please RESET the board ###
-----8<----------8<----------8<----------8<----------8<----------8<-----
Software versions used:
- OpenSBI 1.1 (Debian package: opensbi 1.1-2)
- QEMU 7.2.0 (Debian package: qemu-system-misc 1:7.2+dfsg-1+b2)
- U-Boot v2023.01 (Debian package: u-boot-qemu 2023.01+dfsg-1)
The issue is independent from the kernel that gets booted. With U-Boot v2022.10 everything works without problems. I have used git bisect (with qemu-riscv64_smode_defconfig) to narrow down the specific change that triggers the issue and that has resulted in the following commit:
-----8<----------8<----------8<----------8<----------8<----------8<-----
commit a56f663f07073713042bb0fd08053aeb667e717b (HEAD) Author: Simon Glass sjg@chromium.org Date: Thu Oct 20 18:23:14 2022 -0600
vbe: Add info about the VBE device to the fwupd node At present we put the driver in the /chosen node in U-Boot. This is a bit strange, since U-Boot doesn't normally use that node itself. It is better to put it under the bootstd node. To make this work we need to copy create the node under /chosen when fixing up the device tree. Copy over all the properties so that fwupd knows what to do. Update the sandbox device tree accordingly. Signed-off-by: Simon Glass <sjg@chromium.org>-----8<----------8<----------8<----------8<----------8<----------8<-----
If you should happen to run Debian/unstable, the easiest way to reproduce the problem is as follows:
$ sudo apt install qemu-system-misc opensbi u-boot-qemu
You can then either manually set up a riscv64 VM image as described at https://wiki.debian.org/RISC-V#Setting_up_a_riscv64_virtual_machine or you can use a prebuilt VM image from the Debian Quick Image Baker as described at https://people.debian.org/~gio/dqib/:
$ wget -O riscv64-virt.zip https://gitlab.com/api/v4/projects/giomasce%2Fdqib/jobs/artifacts/master/dow... $ unzip -x riscv64-virt.zip $ cd artifacts
and boot the VM image with
$ qemu-system-riscv64 -smp 4 -nographic -machine virt -m 8G -bios /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.elf -kernel /usr/lib/u-boot/qemu-riscv64_smode/u-boot.bin -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-device,rng=rng0 -append "console=ttyS0 rw root=/dev/vda1 scsi_mod.use_blk_mq=0" -device virtio-blk-device,drive=hd0 -drive file=image.qcow2,format=qcow2,id=hd0 -device virtio-net-device,netdev=usernet -netdev user,id=usernet,hostfwd=tcp::22222-:22
Regards, Karsten
Thanks Karsten for reporting the issue.
Bisection points to Simon's patch:
a56f663f0707371 vbe: Add info about the VBE device to the fwupd node
In bootmeth_vbe_simple_ft_fixup() probing device vbe_simple fails because all fwupd related properties are missing in the QEMU device-tree.
The following change is enough to make QEMU boot again:
CONFIG_BOOTMETH_VBE=n
@Simon:
CONFIG_BOOTMETH_VBE should default to 'no' as only the sandbox provides the required data in the devicetree. Or bootmeth_vbe_simple_ft_fixup() should ignore a failure to probe vbe_simple.
It is supposed to ignore that failure. Could it be that there is a bug in vbe_find_next_device() that it should set *devp to NULL when it doesn't find anything?
The vbe_simple device exists on qemu-riscv64_smode_defconfig but cannot be probed.
How come this failure does not show in CI?
We currently lack tests to actually start a binary via the Linux legacy entry point.
It would be good if we had more tests like test/nokia_rx51_test.sh that booted up a full image. I feel like for platforms that are EBBR compliant it should be less of a problem to do so than it is for nokia_rx51 where part of the challenge is that we need the custom QEMU for it at all.
On 1/12/23 00:59, Tom Rini wrote:
On Thu, Jan 12, 2023 at 12:40:05AM +0100, Heinrich Schuchardt wrote:
On 1/12/23 00:29, Simon Glass wrote:
() Hi Heinrich,
On Wed, 11 Jan 2023 at 16:22, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 1/11/23 20:08, Karsten Merker wrote:
Hello,
it looks like U-Boot v2023.01 is currently broken for the riscv64 architecture on the qemu "virt" platform; the boot process of a riscv64 VM fails during FDT fixup:
-----8<----------8<----------8<----------8<----------8<----------8<-----
OpenSBI v1.1 ____ _____ ____ _____ / __ \ / ____| _ _ _| | | | |_ __ ___ _ __ | (___ | |_) || | | | | | '_ \ / _ \ '_ \ ___ | _ < | | | |__| | |_) | __/ | | |____) | |_) || |_ ____/| .__/ ___|_| |_|_____/|____/_____| | | |_|
Platform Name : riscv-virtio,qemu Platform Features : medeleg Platform HART Count : 4 Platform IPI Device : aclint-mswi Platform Timer Device : aclint-mtimer @ 10000000Hz Platform Console Device : uart8250 Platform HSM Device : --- Platform Reboot Device : sifive_test Platform Shutdown Device : sifive_test Firmware Base : 0x80000000 Firmware Size : 312 KB Runtime SBI Version : 1.0
Domain0 Name : root Domain0 Boot HART : 2 Domain0 HARTs : 0*,1*,2*,3* Domain0 Region00 : 0x0000000002000000-0x000000000200ffff (I) Domain0 Region01 : 0x0000000080000000-0x000000008007ffff () Domain0 Region02 : 0x0000000000000000-0xffffffffffffffff (R,W,X) Domain0 Next Address : 0x0000000080200000 Domain0 Next Arg1 : 0x0000000082200000 Domain0 Next Mode : S-mode Domain0 SysReset : yes
Boot HART ID : 2 Boot HART Domain : root Boot HART Priv Version : v1.12 Boot HART Base ISA : rv64imafdch Boot HART ISA Extensions : time,sstc Boot HART PMP Count : 16 Boot HART PMP Granularity : 4 Boot HART PMP Address Bits: 54 Boot HART MHPM Count : 16 Boot HART MIDELEG : 0x0000000000001666 Boot HART MEDELEG : 0x0000000000f0b509
U-Boot 2023.01+dfsg-1 (Jan 10 2023 - 03:18:09 +0000)
CPU: rv64imafdch_zicsr_zifencei_zihintpause_zba_zbb_zbc_zbs_sstc Model: riscv-virtio,qemu DRAM: 8 GiB Core: 31 devices, 15 uclasses, devicetree: board Flash: 32 MiB Loading Environment from nowhere... OK In: serial@10000000 Out: serial@10000000 Err: serial@10000000 Net: eth0: virtio-net#2 Working FDT set to ff7344b0 Hit any key to stop autoboot: 0
Device 0: QEMU VirtIO Block Device Type: Hard Disk Capacity: 102400.0 MB = 100.0 GB (209715200 x 512) ... is now current device Scanning virtio 0:1... Found /boot/extlinux/extlinux.conf Retrieving file: /boot/extlinux/extlinux.conf U-Boot menu 1: Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 2: Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 (rescue target) 3: Debian GNU/Linux bookworm/sid 6.0.0-6-riscv64 4: Debian GNU/Linux bookworm/sid 6.0.0-6-riscv64 (rescue target) 5: Debian GNU/Linux bookworm/sid 6.0.0-5-riscv64 6: Debian GNU/Linux bookworm/sid 6.0.0-5-riscv64 (rescue target) Enter choice: 1: Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 Retrieving file: /boot/initrd.img-6.1.0-1-riscv64 Retrieving file: /boot/vmlinux-6.1.0-1-riscv64 append: root=/dev/vda1 rw noquiet Moving Image from 0x84000000 to 0x80200000, end=815e5000 ## Flattened Device Tree blob at ff7344b0 Booting using the fdt blob at 0xff7344b0 Working FDT set to ff7344b0 Using Device Tree in place at 00000000ff7344b0, end 00000000ff738dea Working FDT set to ff7344b0 ERROR: fdt fixup event failed: -22 - must RESET the board to recover.
FDT creation failed! hanging...### ERROR ### Please RESET the board ###
-----8<----------8<----------8<----------8<----------8<----------8<-----
Software versions used:
- OpenSBI 1.1 (Debian package: opensbi 1.1-2)
- QEMU 7.2.0 (Debian package: qemu-system-misc 1:7.2+dfsg-1+b2)
- U-Boot v2023.01 (Debian package: u-boot-qemu 2023.01+dfsg-1)
The issue is independent from the kernel that gets booted. With U-Boot v2022.10 everything works without problems. I have used git bisect (with qemu-riscv64_smode_defconfig) to narrow down the specific change that triggers the issue and that has resulted in the following commit:
-----8<----------8<----------8<----------8<----------8<----------8<-----
commit a56f663f07073713042bb0fd08053aeb667e717b (HEAD) Author: Simon Glass sjg@chromium.org Date: Thu Oct 20 18:23:14 2022 -0600
vbe: Add info about the VBE device to the fwupd node At present we put the driver in the /chosen node in U-Boot. This is a bit strange, since U-Boot doesn't normally use that node itself. It is better to put it under the bootstd node. To make this work we need to copy create the node under /chosen when fixing up the device tree. Copy over all the properties so that fwupd knows what to do. Update the sandbox device tree accordingly. Signed-off-by: Simon Glass <sjg@chromium.org>-----8<----------8<----------8<----------8<----------8<----------8<-----
If you should happen to run Debian/unstable, the easiest way to reproduce the problem is as follows:
$ sudo apt install qemu-system-misc opensbi u-boot-qemu
You can then either manually set up a riscv64 VM image as described at https://wiki.debian.org/RISC-V#Setting_up_a_riscv64_virtual_machine or you can use a prebuilt VM image from the Debian Quick Image Baker as described at https://people.debian.org/~gio/dqib/:
$ wget -O riscv64-virt.zip https://gitlab.com/api/v4/projects/giomasce%2Fdqib/jobs/artifacts/master/dow... $ unzip -x riscv64-virt.zip $ cd artifacts
and boot the VM image with
$ qemu-system-riscv64 -smp 4 -nographic -machine virt -m 8G -bios /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.elf -kernel /usr/lib/u-boot/qemu-riscv64_smode/u-boot.bin -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-device,rng=rng0 -append "console=ttyS0 rw root=/dev/vda1 scsi_mod.use_blk_mq=0" -device virtio-blk-device,drive=hd0 -drive file=image.qcow2,format=qcow2,id=hd0 -device virtio-net-device,netdev=usernet -netdev user,id=usernet,hostfwd=tcp::22222-:22
Regards, Karsten
Thanks Karsten for reporting the issue.
Bisection points to Simon's patch:
a56f663f0707371 vbe: Add info about the VBE device to the fwupd node
In bootmeth_vbe_simple_ft_fixup() probing device vbe_simple fails because all fwupd related properties are missing in the QEMU device-tree.
The following change is enough to make QEMU boot again:
CONFIG_BOOTMETH_VBE=n
@Simon:
CONFIG_BOOTMETH_VBE should default to 'no' as only the sandbox provides the required data in the devicetree. Or bootmeth_vbe_simple_ft_fixup() should ignore a failure to probe vbe_simple.
It is supposed to ignore that failure. Could it be that there is a bug in vbe_find_next_device() that it should set *devp to NULL when it doesn't find anything?
The vbe_simple device exists on qemu-riscv64_smode_defconfig but cannot be probed.
How come this failure does not show in CI?
We currently lack tests to actually start a binary via the Linux legacy entry point.
It would be good if we had more tests like test/nokia_rx51_test.sh that booted up a full image. I feel like for platforms that are EBBR compliant it should be less of a problem to do so than it is for nokia_rx51 where part of the challenge is that we need the custom QEMU for it at all.
The EBBR/EFI part is covered by starting GRUB.
The missing part is booting non-EFI images.
Best regards
Heinrich
On Thu, Jan 12, 2023 at 01:01:55AM +0100, Heinrich Schuchardt wrote:
On 1/12/23 00:59, Tom Rini wrote:
On Thu, Jan 12, 2023 at 12:40:05AM +0100, Heinrich Schuchardt wrote:
On 1/12/23 00:29, Simon Glass wrote:
() Hi Heinrich,
On Wed, 11 Jan 2023 at 16:22, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 1/11/23 20:08, Karsten Merker wrote:
Hello,
it looks like U-Boot v2023.01 is currently broken for the riscv64 architecture on the qemu "virt" platform; the boot process of a riscv64 VM fails during FDT fixup:
-----8<----------8<----------8<----------8<----------8<----------8<-----
OpenSBI v1.1 ____ _____ ____ _____ / __ \ / ____| _ _ _| | | | |_ __ ___ _ __ | (___ | |_) || | | | | | '_ \ / _ \ '_ \ ___ | _ < | | | |__| | |_) | __/ | | |____) | |_) || |_ ____/| .__/ ___|_| |_|_____/|____/_____| | | |_|
Platform Name : riscv-virtio,qemu Platform Features : medeleg Platform HART Count : 4 Platform IPI Device : aclint-mswi Platform Timer Device : aclint-mtimer @ 10000000Hz Platform Console Device : uart8250 Platform HSM Device : --- Platform Reboot Device : sifive_test Platform Shutdown Device : sifive_test Firmware Base : 0x80000000 Firmware Size : 312 KB Runtime SBI Version : 1.0
Domain0 Name : root Domain0 Boot HART : 2 Domain0 HARTs : 0*,1*,2*,3* Domain0 Region00 : 0x0000000002000000-0x000000000200ffff (I) Domain0 Region01 : 0x0000000080000000-0x000000008007ffff () Domain0 Region02 : 0x0000000000000000-0xffffffffffffffff (R,W,X) Domain0 Next Address : 0x0000000080200000 Domain0 Next Arg1 : 0x0000000082200000 Domain0 Next Mode : S-mode Domain0 SysReset : yes
Boot HART ID : 2 Boot HART Domain : root Boot HART Priv Version : v1.12 Boot HART Base ISA : rv64imafdch Boot HART ISA Extensions : time,sstc Boot HART PMP Count : 16 Boot HART PMP Granularity : 4 Boot HART PMP Address Bits: 54 Boot HART MHPM Count : 16 Boot HART MIDELEG : 0x0000000000001666 Boot HART MEDELEG : 0x0000000000f0b509
U-Boot 2023.01+dfsg-1 (Jan 10 2023 - 03:18:09 +0000)
CPU: rv64imafdch_zicsr_zifencei_zihintpause_zba_zbb_zbc_zbs_sstc Model: riscv-virtio,qemu DRAM: 8 GiB Core: 31 devices, 15 uclasses, devicetree: board Flash: 32 MiB Loading Environment from nowhere... OK In: serial@10000000 Out: serial@10000000 Err: serial@10000000 Net: eth0: virtio-net#2 Working FDT set to ff7344b0 Hit any key to stop autoboot: 0
Device 0: QEMU VirtIO Block Device Type: Hard Disk Capacity: 102400.0 MB = 100.0 GB (209715200 x 512) ... is now current device Scanning virtio 0:1... Found /boot/extlinux/extlinux.conf Retrieving file: /boot/extlinux/extlinux.conf U-Boot menu 1: Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 2: Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 (rescue target) 3: Debian GNU/Linux bookworm/sid 6.0.0-6-riscv64 4: Debian GNU/Linux bookworm/sid 6.0.0-6-riscv64 (rescue target) 5: Debian GNU/Linux bookworm/sid 6.0.0-5-riscv64 6: Debian GNU/Linux bookworm/sid 6.0.0-5-riscv64 (rescue target) Enter choice: 1: Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 Retrieving file: /boot/initrd.img-6.1.0-1-riscv64 Retrieving file: /boot/vmlinux-6.1.0-1-riscv64 append: root=/dev/vda1 rw noquiet Moving Image from 0x84000000 to 0x80200000, end=815e5000 ## Flattened Device Tree blob at ff7344b0 Booting using the fdt blob at 0xff7344b0 Working FDT set to ff7344b0 Using Device Tree in place at 00000000ff7344b0, end 00000000ff738dea Working FDT set to ff7344b0 ERROR: fdt fixup event failed: -22 - must RESET the board to recover.
FDT creation failed! hanging...### ERROR ### Please RESET the board ###
-----8<----------8<----------8<----------8<----------8<----------8<-----
Software versions used:
- OpenSBI 1.1 (Debian package: opensbi 1.1-2)
- QEMU 7.2.0 (Debian package: qemu-system-misc 1:7.2+dfsg-1+b2)
- U-Boot v2023.01 (Debian package: u-boot-qemu 2023.01+dfsg-1)
The issue is independent from the kernel that gets booted. With U-Boot v2022.10 everything works without problems. I have used git bisect (with qemu-riscv64_smode_defconfig) to narrow down the specific change that triggers the issue and that has resulted in the following commit:
-----8<----------8<----------8<----------8<----------8<----------8<-----
commit a56f663f07073713042bb0fd08053aeb667e717b (HEAD) Author: Simon Glass sjg@chromium.org Date: Thu Oct 20 18:23:14 2022 -0600
vbe: Add info about the VBE device to the fwupd node At present we put the driver in the /chosen node in U-Boot. This is a bit strange, since U-Boot doesn't normally use that node itself. It is better to put it under the bootstd node. To make this work we need to copy create the node under /chosen when fixing up the device tree. Copy over all the properties so that fwupd knows what to do. Update the sandbox device tree accordingly. Signed-off-by: Simon Glass <sjg@chromium.org>-----8<----------8<----------8<----------8<----------8<----------8<-----
If you should happen to run Debian/unstable, the easiest way to reproduce the problem is as follows:
$ sudo apt install qemu-system-misc opensbi u-boot-qemu
You can then either manually set up a riscv64 VM image as described at https://wiki.debian.org/RISC-V#Setting_up_a_riscv64_virtual_machine or you can use a prebuilt VM image from the Debian Quick Image Baker as described at https://people.debian.org/~gio/dqib/:
$ wget -O riscv64-virt.zip https://gitlab.com/api/v4/projects/giomasce%2Fdqib/jobs/artifacts/master/dow... $ unzip -x riscv64-virt.zip $ cd artifacts
and boot the VM image with
$ qemu-system-riscv64 -smp 4 -nographic -machine virt -m 8G -bios /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.elf -kernel /usr/lib/u-boot/qemu-riscv64_smode/u-boot.bin -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-device,rng=rng0 -append "console=ttyS0 rw root=/dev/vda1 scsi_mod.use_blk_mq=0" -device virtio-blk-device,drive=hd0 -drive file=image.qcow2,format=qcow2,id=hd0 -device virtio-net-device,netdev=usernet -netdev user,id=usernet,hostfwd=tcp::22222-:22
Regards, Karsten
Thanks Karsten for reporting the issue.
Bisection points to Simon's patch:
a56f663f0707371 vbe: Add info about the VBE device to the fwupd node
In bootmeth_vbe_simple_ft_fixup() probing device vbe_simple fails because all fwupd related properties are missing in the QEMU device-tree.
The following change is enough to make QEMU boot again:
CONFIG_BOOTMETH_VBE=n
@Simon:
CONFIG_BOOTMETH_VBE should default to 'no' as only the sandbox provides the required data in the devicetree. Or bootmeth_vbe_simple_ft_fixup() should ignore a failure to probe vbe_simple.
It is supposed to ignore that failure. Could it be that there is a bug in vbe_find_next_device() that it should set *devp to NULL when it doesn't find anything?
The vbe_simple device exists on qemu-riscv64_smode_defconfig but cannot be probed.
How come this failure does not show in CI?
We currently lack tests to actually start a binary via the Linux legacy entry point.
It would be good if we had more tests like test/nokia_rx51_test.sh that booted up a full image. I feel like for platforms that are EBBR compliant it should be less of a problem to do so than it is for nokia_rx51 where part of the challenge is that we need the custom QEMU for it at all.
The EBBR/EFI part is covered by starting GRUB.
The missing part is booting non-EFI images.
OK. FWIW, the nokia_rx51 script boots the system a number of ways. While it would be great if this was part of pytest, that might be a lot harder than just making more simple script to deal with grabbing an image and ensuring the system boots in the right way. Once we've got a few of these, we can then see what a more general solution looks like.
On 1/12/23 01:04, Tom Rini wrote:
On Thu, Jan 12, 2023 at 01:01:55AM +0100, Heinrich Schuchardt wrote:
On 1/12/23 00:59, Tom Rini wrote:
On Thu, Jan 12, 2023 at 12:40:05AM +0100, Heinrich Schuchardt wrote:
On 1/12/23 00:29, Simon Glass wrote:
() Hi Heinrich,
On Wed, 11 Jan 2023 at 16:22, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 1/11/23 20:08, Karsten Merker wrote: > Hello, > > it looks like U-Boot v2023.01 is currently broken for the riscv64 > architecture on the qemu "virt" platform; the boot process of a > riscv64 VM fails during FDT fixup: > > -----8<----------8<----------8<----------8<----------8<----------8<----- > > OpenSBI v1.1 > ____ _____ ____ _____ > / __ \ / ____| _ _ _| > | | | |_ __ ___ _ __ | (___ | |_) || | > | | | | '_ \ / _ \ '_ \ ___ | _ < | | > | |__| | |_) | __/ | | |____) | |_) || |_ > ____/| .__/ ___|_| |_|_____/|____/_____| > | | > |_| > > Platform Name : riscv-virtio,qemu > Platform Features : medeleg > Platform HART Count : 4 > Platform IPI Device : aclint-mswi > Platform Timer Device : aclint-mtimer @ 10000000Hz > Platform Console Device : uart8250 > Platform HSM Device : --- > Platform Reboot Device : sifive_test > Platform Shutdown Device : sifive_test > Firmware Base : 0x80000000 > Firmware Size : 312 KB > Runtime SBI Version : 1.0 > > Domain0 Name : root > Domain0 Boot HART : 2 > Domain0 HARTs : 0*,1*,2*,3* > Domain0 Region00 : 0x0000000002000000-0x000000000200ffff (I) > Domain0 Region01 : 0x0000000080000000-0x000000008007ffff () > Domain0 Region02 : 0x0000000000000000-0xffffffffffffffff (R,W,X) > Domain0 Next Address : 0x0000000080200000 > Domain0 Next Arg1 : 0x0000000082200000 > Domain0 Next Mode : S-mode > Domain0 SysReset : yes > > Boot HART ID : 2 > Boot HART Domain : root > Boot HART Priv Version : v1.12 > Boot HART Base ISA : rv64imafdch > Boot HART ISA Extensions : time,sstc > Boot HART PMP Count : 16 > Boot HART PMP Granularity : 4 > Boot HART PMP Address Bits: 54 > Boot HART MHPM Count : 16 > Boot HART MIDELEG : 0x0000000000001666 > Boot HART MEDELEG : 0x0000000000f0b509 > > > U-Boot 2023.01+dfsg-1 (Jan 10 2023 - 03:18:09 +0000) > > CPU: rv64imafdch_zicsr_zifencei_zihintpause_zba_zbb_zbc_zbs_sstc > Model: riscv-virtio,qemu > DRAM: 8 GiB > Core: 31 devices, 15 uclasses, devicetree: board > Flash: 32 MiB > Loading Environment from nowhere... OK > In: serial@10000000 > Out: serial@10000000 > Err: serial@10000000 > Net: eth0: virtio-net#2 > Working FDT set to ff7344b0 > Hit any key to stop autoboot: 0 > > Device 0: QEMU VirtIO Block Device > Type: Hard Disk > Capacity: 102400.0 MB = 100.0 GB (209715200 x 512) > ... is now current device > Scanning virtio 0:1... > Found /boot/extlinux/extlinux.conf > Retrieving file: /boot/extlinux/extlinux.conf > U-Boot menu > 1: Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 > 2: Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 (rescue target) > 3: Debian GNU/Linux bookworm/sid 6.0.0-6-riscv64 > 4: Debian GNU/Linux bookworm/sid 6.0.0-6-riscv64 (rescue target) > 5: Debian GNU/Linux bookworm/sid 6.0.0-5-riscv64 > 6: Debian GNU/Linux bookworm/sid 6.0.0-5-riscv64 (rescue target) > Enter choice: 1: Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 > Retrieving file: /boot/initrd.img-6.1.0-1-riscv64 > Retrieving file: /boot/vmlinux-6.1.0-1-riscv64 > append: root=/dev/vda1 rw noquiet > Moving Image from 0x84000000 to 0x80200000, end=815e5000 > ## Flattened Device Tree blob at ff7344b0 > Booting using the fdt blob at 0xff7344b0 > Working FDT set to ff7344b0 > Using Device Tree in place at 00000000ff7344b0, end 00000000ff738dea > Working FDT set to ff7344b0 > ERROR: fdt fixup event failed: -22 > - must RESET the board to recover. > > FDT creation failed! hanging...### ERROR ### Please RESET the board ### > > -----8<----------8<----------8<----------8<----------8<----------8<----- > > Software versions used: > - OpenSBI 1.1 (Debian package: opensbi 1.1-2) > - QEMU 7.2.0 (Debian package: qemu-system-misc 1:7.2+dfsg-1+b2) > - U-Boot v2023.01 (Debian package: u-boot-qemu 2023.01+dfsg-1) > > The issue is independent from the kernel that gets booted. With > U-Boot v2022.10 everything works without problems. I have used > git bisect (with qemu-riscv64_smode_defconfig) to narrow down the > specific change that triggers the issue and that has resulted in > the following commit: > > -----8<----------8<----------8<----------8<----------8<----------8<----- > > commit a56f663f07073713042bb0fd08053aeb667e717b (HEAD) > Author: Simon Glass sjg@chromium.org > Date: Thu Oct 20 18:23:14 2022 -0600 > > vbe: Add info about the VBE device to the fwupd node > > At present we put the driver in the /chosen node in U-Boot. This is a bit > strange, since U-Boot doesn't normally use that node itself. It is better > to put it under the bootstd node. > > To make this work we need to copy create the node under /chosen when > fixing up the device tree. Copy over all the properties so that fwupd > knows what to do. > > Update the sandbox device tree accordingly. > > Signed-off-by: Simon Glass sjg@chromium.org > > -----8<----------8<----------8<----------8<----------8<----------8<----- > > If you should happen to run Debian/unstable, the easiest way to > reproduce the problem is as follows: > > $ sudo apt install qemu-system-misc opensbi u-boot-qemu > > You can then either manually set up a riscv64 VM image as described at > https://wiki.debian.org/RISC-V#Setting_up_a_riscv64_virtual_machine > or you can use a prebuilt VM image from the Debian Quick Image > Baker as described at https://people.debian.org/~gio/dqib/: > > $ wget -O riscv64-virt.zip https://gitlab.com/api/v4/projects/giomasce%2Fdqib/jobs/artifacts/master/dow... > $ unzip -x riscv64-virt.zip > $ cd artifacts > > and boot the VM image with > > $ qemu-system-riscv64 -smp 4 -nographic -machine virt -m 8G -bios /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.elf -kernel /usr/lib/u-boot/qemu-riscv64_smode/u-boot.bin -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-device,rng=rng0 -append "console=ttyS0 rw root=/dev/vda1 scsi_mod.use_blk_mq=0" -device virtio-blk-device,drive=hd0 -drive file=image.qcow2,format=qcow2,id=hd0 -device virtio-net-device,netdev=usernet -netdev user,id=usernet,hostfwd=tcp::22222-:22 > > Regards, > Karsten
Thanks Karsten for reporting the issue.
Bisection points to Simon's patch:
a56f663f0707371 vbe: Add info about the VBE device to the fwupd node
In bootmeth_vbe_simple_ft_fixup() probing device vbe_simple fails because all fwupd related properties are missing in the QEMU device-tree.
The following change is enough to make QEMU boot again:
CONFIG_BOOTMETH_VBE=n
@Simon:
CONFIG_BOOTMETH_VBE should default to 'no' as only the sandbox provides the required data in the devicetree. Or bootmeth_vbe_simple_ft_fixup() should ignore a failure to probe vbe_simple.
It is supposed to ignore that failure. Could it be that there is a bug in vbe_find_next_device() that it should set *devp to NULL when it doesn't find anything?
The vbe_simple device exists on qemu-riscv64_smode_defconfig but cannot be probed.
How come this failure does not show in CI?
We currently lack tests to actually start a binary via the Linux legacy entry point.
It would be good if we had more tests like test/nokia_rx51_test.sh that booted up a full image. I feel like for platforms that are EBBR compliant it should be less of a problem to do so than it is for nokia_rx51 where part of the challenge is that we need the custom QEMU for it at all.
The EBBR/EFI part is covered by starting GRUB.
The missing part is booting non-EFI images.
OK. FWIW, the nokia_rx51 script boots the system a number of ways. While it would be great if this was part of pytest, that might be a lot harder than just making more simple script to deal with grabbing an image and ensuring the system boots in the right way. Once we've got a few of these, we can then see what a more general solution looks like.
There is a patch series for TPM measurements when booting via bootm.
Here too a test would require booting some binary that provides feedback after being launched by U-Boot.
I guest we are only talking about tests on the sandbox and on QEMU.
Best regards
Heinrich
On Thu, Jan 12, 2023 at 01:16:43AM +0100, Heinrich Schuchardt wrote:
On 1/12/23 01:04, Tom Rini wrote:
On Thu, Jan 12, 2023 at 01:01:55AM +0100, Heinrich Schuchardt wrote:
On 1/12/23 00:59, Tom Rini wrote:
On Thu, Jan 12, 2023 at 12:40:05AM +0100, Heinrich Schuchardt wrote:
On 1/12/23 00:29, Simon Glass wrote:
() Hi Heinrich,
On Wed, 11 Jan 2023 at 16:22, Heinrich Schuchardt xypron.glpk@gmx.de wrote: > > On 1/11/23 20:08, Karsten Merker wrote: > > Hello, > > > > it looks like U-Boot v2023.01 is currently broken for the riscv64 > > architecture on the qemu "virt" platform; the boot process of a > > riscv64 VM fails during FDT fixup: > > > > -----8<----------8<----------8<----------8<----------8<----------8<----- > > > > OpenSBI v1.1 > > ____ _____ ____ _____ > > / __ \ / ____| _ _ _| > > | | | |_ __ ___ _ __ | (___ | |_) || | > > | | | | '_ \ / _ \ '_ \ ___ | _ < | | > > | |__| | |_) | __/ | | |____) | |_) || |_ > > ____/| .__/ ___|_| |_|_____/|____/_____| > > | | > > |_| > > > > Platform Name : riscv-virtio,qemu > > Platform Features : medeleg > > Platform HART Count : 4 > > Platform IPI Device : aclint-mswi > > Platform Timer Device : aclint-mtimer @ 10000000Hz > > Platform Console Device : uart8250 > > Platform HSM Device : --- > > Platform Reboot Device : sifive_test > > Platform Shutdown Device : sifive_test > > Firmware Base : 0x80000000 > > Firmware Size : 312 KB > > Runtime SBI Version : 1.0 > > > > Domain0 Name : root > > Domain0 Boot HART : 2 > > Domain0 HARTs : 0*,1*,2*,3* > > Domain0 Region00 : 0x0000000002000000-0x000000000200ffff (I) > > Domain0 Region01 : 0x0000000080000000-0x000000008007ffff () > > Domain0 Region02 : 0x0000000000000000-0xffffffffffffffff (R,W,X) > > Domain0 Next Address : 0x0000000080200000 > > Domain0 Next Arg1 : 0x0000000082200000 > > Domain0 Next Mode : S-mode > > Domain0 SysReset : yes > > > > Boot HART ID : 2 > > Boot HART Domain : root > > Boot HART Priv Version : v1.12 > > Boot HART Base ISA : rv64imafdch > > Boot HART ISA Extensions : time,sstc > > Boot HART PMP Count : 16 > > Boot HART PMP Granularity : 4 > > Boot HART PMP Address Bits: 54 > > Boot HART MHPM Count : 16 > > Boot HART MIDELEG : 0x0000000000001666 > > Boot HART MEDELEG : 0x0000000000f0b509 > > > > > > U-Boot 2023.01+dfsg-1 (Jan 10 2023 - 03:18:09 +0000) > > > > CPU: rv64imafdch_zicsr_zifencei_zihintpause_zba_zbb_zbc_zbs_sstc > > Model: riscv-virtio,qemu > > DRAM: 8 GiB > > Core: 31 devices, 15 uclasses, devicetree: board > > Flash: 32 MiB > > Loading Environment from nowhere... OK > > In: serial@10000000 > > Out: serial@10000000 > > Err: serial@10000000 > > Net: eth0: virtio-net#2 > > Working FDT set to ff7344b0 > > Hit any key to stop autoboot: 0 > > > > Device 0: QEMU VirtIO Block Device > > Type: Hard Disk > > Capacity: 102400.0 MB = 100.0 GB (209715200 x 512) > > ... is now current device > > Scanning virtio 0:1... > > Found /boot/extlinux/extlinux.conf > > Retrieving file: /boot/extlinux/extlinux.conf > > U-Boot menu > > 1: Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 > > 2: Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 (rescue target) > > 3: Debian GNU/Linux bookworm/sid 6.0.0-6-riscv64 > > 4: Debian GNU/Linux bookworm/sid 6.0.0-6-riscv64 (rescue target) > > 5: Debian GNU/Linux bookworm/sid 6.0.0-5-riscv64 > > 6: Debian GNU/Linux bookworm/sid 6.0.0-5-riscv64 (rescue target) > > Enter choice: 1: Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 > > Retrieving file: /boot/initrd.img-6.1.0-1-riscv64 > > Retrieving file: /boot/vmlinux-6.1.0-1-riscv64 > > append: root=/dev/vda1 rw noquiet > > Moving Image from 0x84000000 to 0x80200000, end=815e5000 > > ## Flattened Device Tree blob at ff7344b0 > > Booting using the fdt blob at 0xff7344b0 > > Working FDT set to ff7344b0 > > Using Device Tree in place at 00000000ff7344b0, end 00000000ff738dea > > Working FDT set to ff7344b0 > > ERROR: fdt fixup event failed: -22 > > - must RESET the board to recover. > > > > FDT creation failed! hanging...### ERROR ### Please RESET the board ### > > > > -----8<----------8<----------8<----------8<----------8<----------8<----- > > > > Software versions used: > > - OpenSBI 1.1 (Debian package: opensbi 1.1-2) > > - QEMU 7.2.0 (Debian package: qemu-system-misc 1:7.2+dfsg-1+b2) > > - U-Boot v2023.01 (Debian package: u-boot-qemu 2023.01+dfsg-1) > > > > The issue is independent from the kernel that gets booted. With > > U-Boot v2022.10 everything works without problems. I have used > > git bisect (with qemu-riscv64_smode_defconfig) to narrow down the > > specific change that triggers the issue and that has resulted in > > the following commit: > > > > -----8<----------8<----------8<----------8<----------8<----------8<----- > > > > commit a56f663f07073713042bb0fd08053aeb667e717b (HEAD) > > Author: Simon Glass sjg@chromium.org > > Date: Thu Oct 20 18:23:14 2022 -0600 > > > > vbe: Add info about the VBE device to the fwupd node > > > > At present we put the driver in the /chosen node in U-Boot. This is a bit > > strange, since U-Boot doesn't normally use that node itself. It is better > > to put it under the bootstd node. > > > > To make this work we need to copy create the node under /chosen when > > fixing up the device tree. Copy over all the properties so that fwupd > > knows what to do. > > > > Update the sandbox device tree accordingly. > > > > Signed-off-by: Simon Glass sjg@chromium.org > > > > -----8<----------8<----------8<----------8<----------8<----------8<----- > > > > If you should happen to run Debian/unstable, the easiest way to > > reproduce the problem is as follows: > > > > $ sudo apt install qemu-system-misc opensbi u-boot-qemu > > > > You can then either manually set up a riscv64 VM image as described at > > https://wiki.debian.org/RISC-V#Setting_up_a_riscv64_virtual_machine > > or you can use a prebuilt VM image from the Debian Quick Image > > Baker as described at https://people.debian.org/~gio/dqib/: > > > > $ wget -O riscv64-virt.zip https://gitlab.com/api/v4/projects/giomasce%2Fdqib/jobs/artifacts/master/dow... > > $ unzip -x riscv64-virt.zip > > $ cd artifacts > > > > and boot the VM image with > > > > $ qemu-system-riscv64 -smp 4 -nographic -machine virt -m 8G -bios /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.elf -kernel /usr/lib/u-boot/qemu-riscv64_smode/u-boot.bin -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-device,rng=rng0 -append "console=ttyS0 rw root=/dev/vda1 scsi_mod.use_blk_mq=0" -device virtio-blk-device,drive=hd0 -drive file=image.qcow2,format=qcow2,id=hd0 -device virtio-net-device,netdev=usernet -netdev user,id=usernet,hostfwd=tcp::22222-:22 > > > > Regards, > > Karsten > > Thanks Karsten for reporting the issue. > > Bisection points to Simon's patch: > > a56f663f0707371 > vbe: Add info about the VBE device to the fwupd node > > In bootmeth_vbe_simple_ft_fixup() probing device vbe_simple fails > because all fwupd related properties are missing in the QEMU device-tree. > > The following change is enough to make QEMU boot again: > > CONFIG_BOOTMETH_VBE=n > > @Simon: > > CONFIG_BOOTMETH_VBE should default to 'no' as only the sandbox provides > the required data in the devicetree. Or bootmeth_vbe_simple_ft_fixup() > should ignore a failure to probe vbe_simple.
It is supposed to ignore that failure. Could it be that there is a bug in vbe_find_next_device() that it should set *devp to NULL when it doesn't find anything?
The vbe_simple device exists on qemu-riscv64_smode_defconfig but cannot be probed.
How come this failure does not show in CI?
We currently lack tests to actually start a binary via the Linux legacy entry point.
It would be good if we had more tests like test/nokia_rx51_test.sh that booted up a full image. I feel like for platforms that are EBBR compliant it should be less of a problem to do so than it is for nokia_rx51 where part of the challenge is that we need the custom QEMU for it at all.
The EBBR/EFI part is covered by starting GRUB.
The missing part is booting non-EFI images.
OK. FWIW, the nokia_rx51 script boots the system a number of ways. While it would be great if this was part of pytest, that might be a lot harder than just making more simple script to deal with grabbing an image and ensuring the system boots in the right way. Once we've got a few of these, we can then see what a more general solution looks like.
There is a patch series for TPM measurements when booting via bootm.
Here too a test would require booting some binary that provides feedback after being launched by U-Boot.
I guest we are only talking about tests on the sandbox and on QEMU.
Well, for CI, whatever can be run through QEMU / sandbox, yes. Real hardware would also be good, but of course depends on the lab. And, I'm not sure off-hand what we can/can't emulate in QEMU for sifive unleashed for example, that might be helpful here.
On Thu, Jan 12, 2023 at 8:18 AM Tom Rini trini@konsulko.com wrote:
On Thu, Jan 12, 2023 at 01:16:43AM +0100, Heinrich Schuchardt wrote:
On 1/12/23 01:04, Tom Rini wrote:
On Thu, Jan 12, 2023 at 01:01:55AM +0100, Heinrich Schuchardt wrote:
On 1/12/23 00:59, Tom Rini wrote:
On Thu, Jan 12, 2023 at 12:40:05AM +0100, Heinrich Schuchardt wrote:
On 1/12/23 00:29, Simon Glass wrote: > () Hi Heinrich, > > On Wed, 11 Jan 2023 at 16:22, Heinrich Schuchardt xypron.glpk@gmx.de wrote: > > > > On 1/11/23 20:08, Karsten Merker wrote: > > > Hello, > > > > > > it looks like U-Boot v2023.01 is currently broken for the riscv64 > > > architecture on the qemu "virt" platform; the boot process of a > > > riscv64 VM fails during FDT fixup: > > > > > > -----8<----------8<----------8<----------8<----------8<----------8<----- > > > > > > OpenSBI v1.1 > > > ____ _____ ____ _____ > > > / __ \ / ____| _ _ _| > > > | | | |_ __ ___ _ __ | (___ | |_) || | > > > | | | | '_ \ / _ \ '_ \ ___ | _ < | | > > > | |__| | |_) | __/ | | |____) | |_) || |_ > > > ____/| .__/ ___|_| |_|_____/|____/_____| > > > | | > > > |_| > > > > > > Platform Name : riscv-virtio,qemu > > > Platform Features : medeleg > > > Platform HART Count : 4 > > > Platform IPI Device : aclint-mswi > > > Platform Timer Device : aclint-mtimer @ 10000000Hz > > > Platform Console Device : uart8250 > > > Platform HSM Device : --- > > > Platform Reboot Device : sifive_test > > > Platform Shutdown Device : sifive_test > > > Firmware Base : 0x80000000 > > > Firmware Size : 312 KB > > > Runtime SBI Version : 1.0 > > > > > > Domain0 Name : root > > > Domain0 Boot HART : 2 > > > Domain0 HARTs : 0*,1*,2*,3* > > > Domain0 Region00 : 0x0000000002000000-0x000000000200ffff (I) > > > Domain0 Region01 : 0x0000000080000000-0x000000008007ffff () > > > Domain0 Region02 : 0x0000000000000000-0xffffffffffffffff (R,W,X) > > > Domain0 Next Address : 0x0000000080200000 > > > Domain0 Next Arg1 : 0x0000000082200000 > > > Domain0 Next Mode : S-mode > > > Domain0 SysReset : yes > > > > > > Boot HART ID : 2 > > > Boot HART Domain : root > > > Boot HART Priv Version : v1.12 > > > Boot HART Base ISA : rv64imafdch > > > Boot HART ISA Extensions : time,sstc > > > Boot HART PMP Count : 16 > > > Boot HART PMP Granularity : 4 > > > Boot HART PMP Address Bits: 54 > > > Boot HART MHPM Count : 16 > > > Boot HART MIDELEG : 0x0000000000001666 > > > Boot HART MEDELEG : 0x0000000000f0b509 > > > > > > > > > U-Boot 2023.01+dfsg-1 (Jan 10 2023 - 03:18:09 +0000) > > > > > > CPU: rv64imafdch_zicsr_zifencei_zihintpause_zba_zbb_zbc_zbs_sstc > > > Model: riscv-virtio,qemu > > > DRAM: 8 GiB > > > Core: 31 devices, 15 uclasses, devicetree: board > > > Flash: 32 MiB > > > Loading Environment from nowhere... OK > > > In: serial@10000000 > > > Out: serial@10000000 > > > Err: serial@10000000 > > > Net: eth0: virtio-net#2 > > > Working FDT set to ff7344b0 > > > Hit any key to stop autoboot: 0 > > > > > > Device 0: QEMU VirtIO Block Device > > > Type: Hard Disk > > > Capacity: 102400.0 MB = 100.0 GB (209715200 x 512) > > > ... is now current device > > > Scanning virtio 0:1... > > > Found /boot/extlinux/extlinux.conf > > > Retrieving file: /boot/extlinux/extlinux.conf > > > U-Boot menu > > > 1: Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 > > > 2: Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 (rescue target) > > > 3: Debian GNU/Linux bookworm/sid 6.0.0-6-riscv64 > > > 4: Debian GNU/Linux bookworm/sid 6.0.0-6-riscv64 (rescue target) > > > 5: Debian GNU/Linux bookworm/sid 6.0.0-5-riscv64 > > > 6: Debian GNU/Linux bookworm/sid 6.0.0-5-riscv64 (rescue target) > > > Enter choice: 1: Debian GNU/Linux bookworm/sid 6.1.0-1-riscv64 > > > Retrieving file: /boot/initrd.img-6.1.0-1-riscv64 > > > Retrieving file: /boot/vmlinux-6.1.0-1-riscv64 > > > append: root=/dev/vda1 rw noquiet > > > Moving Image from 0x84000000 to 0x80200000, end=815e5000 > > > ## Flattened Device Tree blob at ff7344b0 > > > Booting using the fdt blob at 0xff7344b0 > > > Working FDT set to ff7344b0 > > > Using Device Tree in place at 00000000ff7344b0, end 00000000ff738dea > > > Working FDT set to ff7344b0 > > > ERROR: fdt fixup event failed: -22 > > > - must RESET the board to recover. > > > > > > FDT creation failed! hanging...### ERROR ### Please RESET the board ### > > > > > > -----8<----------8<----------8<----------8<----------8<----------8<----- > > > > > > Software versions used: > > > - OpenSBI 1.1 (Debian package: opensbi 1.1-2) > > > - QEMU 7.2.0 (Debian package: qemu-system-misc 1:7.2+dfsg-1+b2) > > > - U-Boot v2023.01 (Debian package: u-boot-qemu 2023.01+dfsg-1) > > > > > > The issue is independent from the kernel that gets booted. With > > > U-Boot v2022.10 everything works without problems. I have used > > > git bisect (with qemu-riscv64_smode_defconfig) to narrow down the > > > specific change that triggers the issue and that has resulted in > > > the following commit: > > > > > > -----8<----------8<----------8<----------8<----------8<----------8<----- > > > > > > commit a56f663f07073713042bb0fd08053aeb667e717b (HEAD) > > > Author: Simon Glass sjg@chromium.org > > > Date: Thu Oct 20 18:23:14 2022 -0600 > > > > > > vbe: Add info about the VBE device to the fwupd node > > > > > > At present we put the driver in the /chosen node in U-Boot. This is a bit > > > strange, since U-Boot doesn't normally use that node itself. It is better > > > to put it under the bootstd node. > > > > > > To make this work we need to copy create the node under /chosen when > > > fixing up the device tree. Copy over all the properties so that fwupd > > > knows what to do. > > > > > > Update the sandbox device tree accordingly. > > > > > > Signed-off-by: Simon Glass sjg@chromium.org > > > > > > -----8<----------8<----------8<----------8<----------8<----------8<----- > > > > > > If you should happen to run Debian/unstable, the easiest way to > > > reproduce the problem is as follows: > > > > > > $ sudo apt install qemu-system-misc opensbi u-boot-qemu > > > > > > You can then either manually set up a riscv64 VM image as described at > > > https://wiki.debian.org/RISC-V#Setting_up_a_riscv64_virtual_machine > > > or you can use a prebuilt VM image from the Debian Quick Image > > > Baker as described at https://people.debian.org/~gio/dqib/: > > > > > > $ wget -O riscv64-virt.zip https://gitlab.com/api/v4/projects/giomasce%2Fdqib/jobs/artifacts/master/dow... > > > $ unzip -x riscv64-virt.zip > > > $ cd artifacts > > > > > > and boot the VM image with > > > > > > $ qemu-system-riscv64 -smp 4 -nographic -machine virt -m 8G -bios /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.elf -kernel /usr/lib/u-boot/qemu-riscv64_smode/u-boot.bin -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-device,rng=rng0 -append "console=ttyS0 rw root=/dev/vda1 scsi_mod.use_blk_mq=0" -device virtio-blk-device,drive=hd0 -drive file=image.qcow2,format=qcow2,id=hd0 -device virtio-net-device,netdev=usernet -netdev user,id=usernet,hostfwd=tcp::22222-:22 > > > > > > Regards, > > > Karsten > > > > Thanks Karsten for reporting the issue. > > > > Bisection points to Simon's patch: > > > > a56f663f0707371 > > vbe: Add info about the VBE device to the fwupd node > > > > In bootmeth_vbe_simple_ft_fixup() probing device vbe_simple fails > > because all fwupd related properties are missing in the QEMU device-tree. > > > > The following change is enough to make QEMU boot again: > > > > CONFIG_BOOTMETH_VBE=n > > > > @Simon: > > > > CONFIG_BOOTMETH_VBE should default to 'no' as only the sandbox provides > > the required data in the devicetree. Or bootmeth_vbe_simple_ft_fixup() > > should ignore a failure to probe vbe_simple. > > It is supposed to ignore that failure. Could it be that there is a bug > in vbe_find_next_device() that it should set *devp to NULL when it > doesn't find anything?
The vbe_simple device exists on qemu-riscv64_smode_defconfig but cannot be probed.
> > How come this failure does not show in CI?
We currently lack tests to actually start a binary via the Linux legacy entry point.
It would be good if we had more tests like test/nokia_rx51_test.sh that booted up a full image. I feel like for platforms that are EBBR compliant it should be less of a problem to do so than it is for nokia_rx51 where part of the challenge is that we need the custom QEMU for it at all.
The EBBR/EFI part is covered by starting GRUB.
The missing part is booting non-EFI images.
OK. FWIW, the nokia_rx51 script boots the system a number of ways. While it would be great if this was part of pytest, that might be a lot harder than just making more simple script to deal with grabbing an image and ensuring the system boots in the right way. Once we've got a few of these, we can then see what a more general solution looks like.
There is a patch series for TPM measurements when booting via bootm.
Here too a test would require booting some binary that provides feedback after being launched by U-Boot.
I guest we are only talking about tests on the sandbox and on QEMU.
Well, for CI, whatever can be run through QEMU / sandbox, yes. Real hardware would also be good, but of course depends on the lab. And, I'm not sure off-hand what we can/can't emulate in QEMU for sifive unleashed for example, that might be helpful here.
QEMU 'sifive_u' machine emulates the SiFive Unleashed board, and can boot the real world firmware U-Boot SPL & Proper out of the box.
Regards, Bin
Hi Heinrich,
On Wed, 11 Jan 2023 at 16:22, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 1/11/23 20:08, Karsten Merker wrote:
Hello,
it looks like U-Boot v2023.01 is currently broken for the riscv64 architecture on the qemu "virt" platform; the boot process of a riscv64 VM fails during FDT fixup:
-----8<----------8<----------8<----------8<----------8<----------8<-----
[..]
@Simon:
CONFIG_BOOTMETH_VBE should default to 'no' as only the sandbox provides the required data in the devicetree. Or bootmeth_vbe_simple_ft_fixup() should ignore a failure to probe vbe_simple.
I sent a patch here:
https://patchwork.ozlabs.org/project/uboot/patch/20230112165020.822157-1-sjg...
Regards, Simon
participants (5)
-
Bin Meng -
Heinrich Schuchardt -
Karsten Merker -
Simon Glass -
Tom Rini