please provide firmware file for riscv64

[Dimitri John Ledkov]

please provide firmware file for riscv64

I'm not sure which package should ship it, or what it should look like, but i want something like this:

qemu-system-riscv64 -machine virt -m 2048 -smp 4 -kernel /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.elf -device loader,file=/usr/lib/u-boot/qemu-riscv64_smode/uboot.elf,addr=0x80200000 -device virtio-blk-device,drive=vda -drive file=livecd.ubuntu-cpc.img,id=vda -device virtio-net-device,netdev=eth0 -netdev user,id=eth0

such that on riscv64 opensbi loader is available as firmware, with qemu smode uboot.elf.

I don't know how to write the appropriate qmeu/firmware/*.json for it.

[Heinrich Schuchardt (xypron)]

The QEMU source comes with bundled OpenSBI binaries ./pc-bios/opensbi-riscv*-generic-fw_dynamic.*

docs/system/riscv/virt.rst describes booting in S-mode without the -bios option only using -kernel. To my understanding the bundled OpenSBI binaries are used.

[Dimitri John Ledkov (xnox)]

That's not enough. The json file I'm asking for in this bug report would not only load generic opensbi but would also load our location for uboot.

A second json file would load opensbi and edk2 firmware with various options.

See the json files that we provide on x86 and arm64, that not only setup firmware but also the other pieces to get to UEFI with secureboot and enrolled keys, etc.

These json files are needed to be then consumed by libvirt which would also be able to expose them in virt-manager.

Ideally in virt-manger it would be able to start riscv64 VM to boot any extlinux.conf compatible image for example (i.e. the current cloud images, unleashed, and unmatched images we ship). A different option would then provide to boot into EDK2 once we have it.

[Christian Ehrhardt  (paelzer)]

FYI - the qemu spec for these file-format is here
https://gitlab.com/qemu-project/qemu/-/blob/v6.0.0/docs/interop/firmware.json

The only big case for it so far has been uefi which used to be a stressful manual file copy and selection which now can be done trivially by specifying a few features. Via those it will negotiate and find the right firmware file to load.
Some background on that in:
  https://bugzilla.redhat.com/show_bug.cgi?id=1728652

It also helps distro packaging which tends to not use all firmware from qemu source but e.g. an extra edk2. This way it can provide the paths which happen to be distro specific.

So to make sure I get it right, @xnox you want it to map
   qemu-system-riscv64 -machine virt
to realize "oh wait I have a fw file for that" and thereby instruct it to load our opensbi/uboot/edk2 from the right places - is that what you ask for?

If the above understanding of your request is true, then (so far) the right place has been the source for these firmware images. E.g. opensbi/uboot in this case - those source packages are the ones knowing which variants they place and at which path.

But TBH I've not seen this in use/discussion for uboot/riscv64 yet so far. There might be some code (in contrast to just a few descriptive json files) needed to fully work for this use case. If you think that is the case I'd recommend to file upstream bugs at https://gitlab.com/qemu-project/qemu/-/issues / https://gitlab.com/libvirt/libvirt/-/issues and link them from here).
That way we'd have upstream "in the boat" from day #1

[Heinrich Schuchardt (xypron)]

Such a firmware file should be in package u-boot-qemu (source package u-boot).