© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
demo site
(Get the code!)
FYI - the qemu spec for these file-format is here
https:/
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:/
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-
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:/
That way we'd have upstream "in the boat" from day #1