U-Boot v2023.01 broken on riscv64 qemu virt platform: "fdt fixup event failed"

Heinrich Schuchardt xypron.glpk at gmx.de
Thu Jan 12 01:01:59 CET 2023

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:
>>>> @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:
after extraction.

Best regards


>>> 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

More information about the U-Boot mailing list