[bug#64907,0/2] gnu: Add rvvm support packages.

Hello,

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.

The RVVM author claims faster execution than QEMU. 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.

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.

Thanks,
Juli

Juliana Sims (2):
  gnu: Add u-boot-rvvm.
  gnu: Add opensbi-rvvm.

 gnu/packages/bootloaders.scm                  | 23 +++++++
 gnu/packages/firmware.scm                     | 32 +++++++++
 .../patches/opensbi-rvvm-lowram-fdt.patch     | 21 ++++++
 .../patches/u-boot-rvvm-support.patch         | 67 +++++++++++++++++++
 4 files changed, 143 insertions(+)
 create mode 100644 gnu/packages/patches/opensbi-rvvm-lowram-fdt.patch
 create mode 100644 gnu/packages/patches/u-boot-rvvm-support.patch


base-commit: 35c8d631d2bd63c64e863b5509f29fdcb7f856e6
  

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