On 1/12/23 00:29, Simon Glass wrote:
() Hi Heinrich,
On Wed, 11 Jan 2023 at 16:22, Heinrich Schuchardt <xypron.g...@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 <s...@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 <s...@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/download?job=convert_riscv64-virt
$ 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
