| Message ID | cover.1690488628.git.juli@incana.org |
|---|---|
| Headers | show |
| Series | gnu: Add rvvm support packages. | expand |
Hello, Juliana Sims <juli@incana.org> skribis: > These patches create specialized U-Boot and OpenSBI packages to use with RVVM by > applying RVVM's author's patches to those projects. Additionally, they build > this patched version of U-Boot into OpenSBI's `fw_payload.bin`, mimicking the > binary release from RVVM. Vagrant, Efraim: could you take a look? https://issues.guix.gnu.org/64907 I’ll take this as an opportunity to remove myself from the ‘embedded’ team, where I ended up unwillingly in 7cf606a5a0515b9a124fb58a06e3daa24a4a4e69. :-) Ludo’.
On 2023-07-27, Juliana Sims wrote: > These patches create specialized U-Boot and OpenSBI packages to use with RVVM by > applying RVVM's author's patches to those projects. Additionally, they build > this patched version of U-Boot into OpenSBI's `fw_payload.bin`, mimicking the > binary release from RVVM. It could be a lot of work over time to maintain a patched version of u-boot and/or opensbi, especially if those patches are not going to be merged upstream at some point... > The RVVM author claims faster execution than QEMU. How much faster? Knowing nothing about RVVM, When I asked on irc.libera.chat #riscv that was basically the question I got... So if going that route, would want to make sure the performance difference is significant. > As such, the ultimate goal of > these packages is to create a system service which will allow developers to > easily run Guix under RVVM for the purpose of development, much like > hurd-vm-service-type provides a way to run Hurd under Guix. However, that's a > larger project, and getting these packaged as they are will already prove > useful. Anyone wishing to use them can simply run: > > ``` > guix shell --pure rvvm opensbi-rvvm > rvvm /gnu/store/<hash>-opensbi-rvvm-<version>/fw_payload.bin -i <os>.img [...] > ``` > > I have tested these packages with the FreeBSD-13.2 RV64 raw disk image, so I > know they run successfully. > > It's worth noting that opensbi-generic works fine with RVVM. However, it does > not provide `fw_payload.bin` - only `fw_jump.bin` - so this version provides > more flexibility. That said, opensbi-rvvm is 5.3 MB compared to > opensbi-generic's 1.3 MB. Because of that, I'm ambivalent about adding it. I > leave the decision on whether or not to include it entirely up to others; > there's no sense in throwing away work I already did if it may be useful. If it requires patches, I am a bit concerned about long-term maintenence... If it does not require patches, that does not seem like a huge increase, or an alternate build that also ships the fw_payload.bin file. > It may be worth noting that RVVM also has patches for the Linux kernel. However, > upon inspection they seem to primarily be concerned with decreasing binary size, > which can be worked around if needed. The linux-libre-riscv64-generic package > should work just fine, but this has not been tested. Worked around how? live well, vagrant
On 2023-08-29, Vagrant Cascadian wrote: > On 2023-07-27, Juliana Sims wrote: >> These patches create specialized U-Boot and OpenSBI packages to use with RVVM by >> applying RVVM's author's patches to those projects. Additionally, they build >> this patched version of U-Boot into OpenSBI's `fw_payload.bin`, mimicking the >> binary release from RVVM. ... >> It's worth noting that opensbi-generic works fine with RVVM. However, it does >> not provide `fw_payload.bin` - only `fw_jump.bin` - so this version provides >> more flexibility. That said, opensbi-rvvm is 5.3 MB compared to >> opensbi-generic's 1.3 MB. Because of that, I'm ambivalent about adding it. I >> leave the decision on whether or not to include it entirely up to others; >> there's no sense in throwing away work I already did if it may be useful. > > If it requires patches, I am a bit concerned about long-term > maintenence... If it does not require patches, that does not seem like a > huge increase, or an alternate build that also ships the fw_payload.bin > file. Thinking a little more, from what I recall, the whole point of fw_jump.bin is so that you can dynamically specify the payload at runtime ... why do we need a separate fw_payload.bin created at build-time, if you can just pass a (potentially custom) payload at runtime? It has been a while since I have used these components for virtual riscv systems, so my memory may be a little rusty or recent usage may have changed... :) live well, vagrant
Hi Vagrant, > It could be a lot of work over time to maintain a patched version of > u-boot and/or opensbi, especially if those patches are not going to be > merged upstream at some point... I make a point of periodically updating and checking for the continued functionality of all new packages I submit to Guix. There is a fair bit of RISC-V work I would like to do over the next years so I would have no problem extending this personal policy to these packages as well. > How much faster? Knowing nothing about RVVM, When I asked on > irc.libera.chat #riscv that was basically the question I got... No idea, but having done a fair bit of RISC-V development on emulators, I'm willing to take anything I can get XD > Worked around how? So, that turn of phrase was pretty arbitrary, but the sentiment I wished to communicate is that I doubt most developers need Linux to be tiny. I don't even understand *why* Linux needs to be shrunk for rvvm; perhaps to minimize the disk space or memory given to it? If that's the case, then the work-around would be to give it more disk and memory from the host. > Thinking a little more, from what I recall, the whole point of > fw_jump.bin is so that you can dynamically specify the payload at > runtime ... why do we need a separate fw_payload.bin created at > build-time, if you can just pass a (potentially custom) payload at > runtime? As mentioned in the cover letter, you can drop the opensbi patch if you like. I didn't think to test opensbi-generic before packaging this patched version, and figured "waste not; want not." However, rvvm does not work with any version of u-boot currently in Guix. Hope this helps with any concerns. Let me know if I need to make any changes to the patch(es). Thanks, Juli
RVVM developer here. First of all, thanks for package support. There is v0.6 released which has stable networking and a lot of small features/fixes. The opensbi patch is not necessary at all. It is kinda an internal optimization patch I use because I like to optimize stuff, and when patches aren't getting accepted I put them in my repo. Generic OpenSBI works without a problem there. RVVM generally tries to be very compatible with QEMU, but some devices are different - for example instead of Virtio-blk, NVMe drives are emulated. This configuration is also possible on QEMU, so it's not like it's entirely incompatible - more like a minimal subset of it. The U-Boot patch is needed because, for some reason QEMU U-Boot config doesn't enable NVMe boot (however you can choose NVMe drives with QEMU, and they too won't work there). I believe this is an oversight on U-Boot side. I also enabled EFI framebuffer which is needed by Haiku OS guests. QEMU doesn't have an EFI framebuffer, but adding another feature into U-Boot doesn't hurt. It still works on QEMU afterwards. I also see mentions that I am purposely making RVVM incompatible with QEMU, and I want to remind you that this is not the case at all. The U-Boot issue is simply a lacking build option on their side, which affects some QEMU usecases too. It's more like QEMU U-Boot is incompatible with anything other than the default unconfigured QEMU Virt board. The real solution would be to reach upstream U-Boot and ask to enable NVMe boot hook, and options `VIDEO` `VIDEO_SIMPLE`. Example (notice it has other stuff enabled, not intended for upstream): https://github.com/LekKit/patches-misc/blob/master/uboot/uboot2024_rvvm_support.patch