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-server-riscv64+unmatched.img.xz
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
