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

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

[Juliana Sims]

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

[bug#64907] [PATCH 1/2] gnu: Add u-boot-rvvm.

[Juliana Sims]

* gnu/packages/bootloaders.scm (%u-boot-rvvm-support-patch, u-boot-rvvm): New
symbol.
* gnu/packages/patches/u-boot-rvvm-support.patch: New patch.
---
 gnu/packages/bootloaders.scm                  | 23 +++++++
 .../patches/u-boot-rvvm-support.patch         | 67 +++++++++++++++++++
 2 files changed, 90 insertions(+)
 create mode 100644 gnu/packages/patches/u-boot-rvvm-support.patch

diff --git a/gnu/packages/bootloaders.scm b/gnu/packages/bootloaders.scm
index 38eb1d104f..5f12d324e8 100644
--- a/gnu/packages/bootloaders.scm
+++ b/gnu/packages/bootloaders.scm
@@ -18,6 +18,7 @@
 ;;; Copyright © 2022 Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
 ;;; Copyright © 2021 Stefan <stefan-guix@vodafonemail.de>
 ;;; Copyright © 2022, 2023 Maxim Cournoyer <maxim.cournoyer@gmail.com>
+;;; Copyright © 2023 Juliana Sims <juli@incana.org>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -645,6 +646,15 @@ (define %u-boot-rk3399-enable-emmc-phy-patch
   ;; https://lists.denx.de/pipermail/u-boot/2021-November/466329.html
   (search-patch "u-boot-rk3399-enable-emmc-phy.patch"))
 
+(define %u-boot-rvvm-support-patch
+  ;; Patch to support NVMe and RVVM board properly in U-Boot
+  ;; - Enables NVMe PCI support & booting from it
+  ;; - Enables framebuffer driver, passes it as EFI FB
+  ;; - Enables Realtek RTL8169 driver
+  ;; - Get rid of DHCP boot, it is confusing and not helpful
+  ;; https://github.com/LekKit/patches-misc/blob/ef2bb2bc6e37f87f3af4f9d9c8b69f76408620a7/uboot/uboot_rvvm_support.patch
+  (search-patch "u-boot-rvvm-support.patch"))
+
 (define u-boot
   (package
     (name "u-boot")
@@ -1173,6 +1183,19 @@ (define-public u-boot-qemu-riscv64
 (define-public u-boot-qemu-riscv64-smode
   (make-u-boot-package "qemu-riscv64_smode" "riscv64-linux-gnu"))
 
+(define-public u-boot-rvvm
+  (let ((base (make-u-boot-package "qemu-riscv64_smode" "riscv64-linux-gnu"
+               #:append-description
+               "This U-Boot is built for @code{rvvm}.  It is also compatible
+with @code{qemu}, but adds patches from the @code{rvvm} authors.")))
+    (package
+      (inherit base)
+      (name "u-boot-rvvm")
+      (source (origin
+                (inherit (package-source base))
+                (patches (cons %u-boot-rvvm-support-patch
+                               (origin-patches (package-source base)))))))))
+
 (define-public u-boot-sandbox
   (let ((base (make-u-boot-package
                "sandbox" #f             ;build for the native system
diff --git a/gnu/packages/patches/u-boot-rvvm-support.patch b/gnu/packages/patches/u-boot-rvvm-support.patch
new file mode 100644
index 0000000000..1e62a2d61d
--- /dev/null
+++ b/gnu/packages/patches/u-boot-rvvm-support.patch
@@ -0,0 +1,67 @@
+Patch to support NVMe and RVVM board properly in U-Boot
+ - Enables NVMe PCI support & booting from it
+ - Enables framebuffer driver, passes it as EFI FB
+ - Enables Realtek RTL8169 driver
+ - Get rid of DHCP boot, it is confusing and not helpful
+
+Applies cleanly over U-Boot 2023.4
+Reuses QEMU virt board config, build like this:
+ make qemu-riscv64_smode_defconfig
+ CROSS_COMPILE=riscv64-linux-gnu- make
+
+Resulting firmware works fine on both RVVM and QEMU
+
+diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
+index 48ca4ff4..faa17f33 100644
+--- a/arch/riscv/Kconfig
++++ b/arch/riscv/Kconfig
+@@ -15,7 +15,7 @@ config TARGET_MICROCHIP_ICICLE
+ 	bool "Support Microchip PolarFire-SoC Icicle Board"
+ 
+ config TARGET_QEMU_VIRT
+-	bool "Support QEMU Virt Board"
++	bool "Support QEMU/RVVM Virt Boards"
+ 
+ config TARGET_SIFIVE_UNLEASHED
+ 	bool "Support SiFive Unleashed Board"
+diff --git a/board/emulation/qemu-riscv/Kconfig b/board/emulation/qemu-riscv/Kconfig
+index 6114e1b8..7c25825a 100644
+--- a/board/emulation/qemu-riscv/Kconfig
++++ b/board/emulation/qemu-riscv/Kconfig
+@@ -29,6 +29,7 @@ config BOARD_SPECIFIC_OPTIONS # dummy
+ 	def_bool y
+ 	select GENERIC_RISCV
+ 	select SUPPORT_SPL
++	imply OPTIMIZE_INLINING
+ 	imply AHCI
+ 	imply SMP
+ 	imply BOARD_LATE_INIT
+@@ -50,7 +51,12 @@ config BOARD_SPECIFIC_OPTIONS # dummy
+ 	imply SCSI_AHCI
+ 	imply AHCI_PCI
+ 	imply E1000
++	imply RTL8169
+ 	imply NVME
++	imply NVME_PCI
++	imply VIDEO
++	imply VIDEO_SIMPLE
++	imply NO_FB_CLEAR
+ 	imply PCI
+ 	imply PCIE_ECAM_GENERIC
+ 	imply SCSI
+diff --git a/include/configs/qemu-riscv.h b/include/configs/qemu-riscv.h
+index 20135f56..821251a3 100644
+--- a/include/configs/qemu-riscv.h
++++ b/include/configs/qemu-riscv.h
+@@ -19,9 +19,9 @@
+ 
+ #define BOOT_TARGET_DEVICES(func) \
+ 	func(QEMU, qemu, na) \
++	func(NVME, nvme, 0) \
+ 	func(VIRTIO, virtio, 0) \
+-	func(SCSI, scsi, 0) \
+-	func(DHCP, dhcp, na)
++	func(SCSI, scsi, 0)
+ 
+ #include <config_distro_bootcmd.h>
+ 
-- 
2.41.0

[bug#64907] [PATCH 2/2] gnu: Add opensbi-rvvm.

[Juliana Sims]

* gnu/packages/firmware.scm (opensbi-rvvm): New symbol.
* gnu/packages/patches/opensbi-rvvm-lowram-fdt.patch: New patch.
---
 gnu/packages/firmware.scm                     | 32 +++++++++++++++++++
 .../patches/opensbi-rvvm-lowram-fdt.patch     | 21 ++++++++++++
 2 files changed, 53 insertions(+)
 create mode 100644 gnu/packages/patches/opensbi-rvvm-lowram-fdt.patch

diff --git a/gnu/packages/firmware.scm b/gnu/packages/firmware.scm
index ff5afbcbe1..728050b43a 100644
--- a/gnu/packages/firmware.scm
+++ b/gnu/packages/firmware.scm
@@ -9,6 +9,7 @@
 ;;; Copyright © 2020, 2021, 2022 Marius Bakke <marius@gnu.org>
 ;;; Copyright © 2021 Petr Hodina <phodina@protonmail.com>
 ;;; Copyright © 2022, 2023 Maxim Cournoyer <maxim.cournoyer@gmail.com>
+;;; Copyright © 2023 Juliana Sims <juli@incana.org>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -43,6 +44,7 @@ (define-module (gnu packages firmware)
   #:use-module (gnu packages base)
   #:use-module (gnu packages bash)
   #:use-module (gnu packages bison)
+  #:use-module (gnu packages bootloaders)
   #:use-module (gnu packages check)
   #:use-module (gnu packages cmake)
   #:use-module (gnu packages compression)
@@ -567,6 +569,36 @@ (define-public opensbi-qemu
     (description
      "This package contains OpenSBI firmware files for use with QEMU.")))
 
+(define-public opensbi-rvvm
+  (let ((base opensbi-generic))
+    (package
+      (inherit base)
+      (name "opensbi-rvvm")
+      (source (origin
+                (inherit (package-source base))
+                (patches (cons
+                          ;; Allows opensbi to work on systems with <32M of RAM
+                          ;; https://github.com/LekKit/patches-misc/blob/cc40906fbf1de9ae466304157f2bf7b8cc909cbe/opensbi/opensbi_lowram_fdt.patch
+                          (search-patch "opensbi-rvvm-lowram-fdt.patch")
+                          (origin-patches (package-source base))))))
+
+      (arguments
+       (substitute-keyword-arguments (package-arguments base)
+         ((#:make-flags flags)
+          #~(cons (string-append "FW_PAYLOAD_PATH="
+                                 #$(file-append u-boot-rvvm
+                                                "/libexec/u-boot.bin"))
+                  (delete "FW_PAYLOAD=n"
+                          #$flags)))))
+      (inputs (cons u-boot-rvvm
+                    (package-inputs base)))
+      (description (string-append (package-description base)
+                    "
+
+This package contains OpenSBI firmware files for use with
+@code{rvvm}.  In particular, it adds support for low-RAM systems and builds a
+@code{fw_payload.bin} file using @code{u-boot-rvvm-riscv64}.")))))
+
 (define-public seabios
   (package
     (name "seabios")
diff --git a/gnu/packages/patches/opensbi-rvvm-lowram-fdt.patch b/gnu/packages/patches/opensbi-rvvm-lowram-fdt.patch
new file mode 100644
index 0000000000..c9e27020f0
--- /dev/null
+++ b/gnu/packages/patches/opensbi-rvvm-lowram-fdt.patch
@@ -0,0 +1,21 @@
+Authored-by: LekKit <github.com/LekKit>
+
+Allows OpenSBI to work on devices with <32M of RAM,
+by moving FDT into page alignment zone before the kernel.
+This also allows running kernels that are >32M in size.
+
+Applies cleanly onto OpenSBI 1.2
+
+diff --git a/platform/generic/objects.mk b/platform/generic/objects.mk
+index 136853e..104a063 100644
+--- a/platform/generic/objects.mk
++++ b/platform/generic/objects.mk
+@@ -32,7 +32,7 @@ else
+   # This needs to be 2MB aligned for 64-bit system
+   FW_JUMP_ADDR=$(shell printf "0x%X" $$(($(FW_TEXT_START) + 0x200000)))
+ endif
+-FW_JUMP_FDT_ADDR=$(shell printf "0x%X" $$(($(FW_TEXT_START) + 0x2200000)))
++FW_JUMP_FDT_ADDR=$(shell printf "0x%X" $$(($(FW_TEXT_START) + 0x100000)))
+ FW_PAYLOAD=y
+ ifeq ($(PLATFORM_RISCV_XLEN), 32)
+   # This needs to be 4MB aligned for 32-bit system
-- 
2.41.0

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

[Ludovic Courtès]

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

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

[Vagrant Cascadian]

[-- Attachment #1: Type: text/plain, Size: 2404 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

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

[Vagrant Cascadian]

[-- Attachment #1: Type: text/plain, Size: 1489 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

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

[Juliana Sims]

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

[bug#64907] [PATCH 1/2] gnu: Add u-boot-rvvm.

[Vagrant Cascadian]

[-- Attachment #1: Type: text/plain, Size: 3396 bytes --]

On 2023-07-27, Juliana Sims wrote:
> * gnu/packages/bootloaders.scm (%u-boot-rvvm-support-patch, u-boot-rvvm): New
> symbol.
> * gnu/packages/patches/u-boot-rvvm-support.patch: New patch.
...
> diff --git a/gnu/packages/patches/u-boot-rvvm-support.patch b/gnu/packages/patches/u-boot-rvvm-support.patch
> new file mode 100644
> index 0000000000..1e62a2d61d
> --- /dev/null
> +++ b/gnu/packages/patches/u-boot-rvvm-support.patch
> @@ -0,0 +1,67 @@
> +Patch to support NVMe and RVVM board properly in U-Boot
> + - Enables NVMe PCI support & booting from it
> + - Enables framebuffer driver, passes it as EFI FB
> + - Enables Realtek RTL8169 driver
> + - Get rid of DHCP boot, it is confusing and not helpful
> +
> +Applies cleanly over U-Boot 2023.4
> +Reuses QEMU virt board config, build like this:
> + make qemu-riscv64_smode_defconfig
> + CROSS_COMPILE=riscv64-linux-gnu- make
> +
> +Resulting firmware works fine on both RVVM and QEMU
> +
> +diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> +index 48ca4ff4..faa17f33 100644
> +--- a/arch/riscv/Kconfig
> ++++ b/arch/riscv/Kconfig
> +@@ -15,7 +15,7 @@ config TARGET_MICROCHIP_ICICLE
> + 	bool "Support Microchip PolarFire-SoC Icicle Board"
> + 
> + config TARGET_QEMU_VIRT
> +-	bool "Support QEMU Virt Board"
> ++	bool "Support QEMU/RVVM Virt Boards"
> + 
> + config TARGET_SIFIVE_UNLEASHED
> + 	bool "Support SiFive Unleashed Board"

This seems unecessary, unless this is pulling from a patch submitted to
upstream u-boot that is likely to be merged.


> +diff --git a/board/emulation/qemu-riscv/Kconfig b/board/emulation/qemu-riscv/Kconfig
> +index 6114e1b8..7c25825a 100644
> +--- a/board/emulation/qemu-riscv/Kconfig
> ++++ b/board/emulation/qemu-riscv/Kconfig
> +@@ -29,6 +29,7 @@ config BOARD_SPECIFIC_OPTIONS # dummy
> + 	def_bool y
> + 	select GENERIC_RISCV
> + 	select SUPPORT_SPL
> ++	imply OPTIMIZE_INLINING
> + 	imply AHCI
> + 	imply SMP
> + 	imply BOARD_LATE_INIT
> +@@ -50,7 +51,12 @@ config BOARD_SPECIFIC_OPTIONS # dummy
> + 	imply SCSI_AHCI
> + 	imply AHCI_PCI
> + 	imply E1000
> ++	imply RTL8169
> + 	imply NVME
> ++	imply NVME_PCI
> ++	imply VIDEO
> ++	imply VIDEO_SIMPLE
> ++	imply NO_FB_CLEAR
> + 	imply PCI
> + 	imply PCIE_ECAM_GENERIC
> + 	imply SCSI

I *think* all of these options could be done by passing #:configs ...

For example, how the u-boot-qemu-arm changes an option:

(define-public u-boot-qemu-arm
  (make-u-boot-package "qemu_arm" "arm-linux-gnueabihf"
                       #:configs '("# CONFIG_FIT_SIGNATURE is not set")))


> +diff --git a/include/configs/qemu-riscv.h b/include/configs/qemu-riscv.h
> +index 20135f56..821251a3 100644
> +--- a/include/configs/qemu-riscv.h
> ++++ b/include/configs/qemu-riscv.h
> +@@ -19,9 +19,9 @@
> + 
> + #define BOOT_TARGET_DEVICES(func) \
> + 	func(QEMU, qemu, na) \
> ++	func(NVME, nvme, 0) \
> + 	func(VIRTIO, virtio, 0) \
> +-	func(SCSI, scsi, 0) \
> +-	func(DHCP, dhcp, na)
> ++	func(SCSI, scsi, 0)
> + 
> + #include <config_distro_bootcmd.h>
> + 
> -- 
> 2.41.0

I would just leave the DHCP in; it surely cannot hurt *that* much... or?

... at which point, if all my other suggestions are accepted, the NVME
part might be the only patch to upstream sources, and you could fix it
with a snippet or phase or a one-line patch. :)

live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

[bug#64907] [PATCH 2/2] gnu: Add opensbi-rvvm.

[Vagrant Cascadian]

[-- Attachment #1: Type: text/plain, Size: 2096 bytes --]

On 2023-07-27, Juliana Sims wrote:
> * gnu/packages/firmware.scm (opensbi-rvvm): New symbol.
> * gnu/packages/patches/opensbi-rvvm-lowram-fdt.patch: New patch.
...
> diff --git a/gnu/packages/firmware.scm b/gnu/packages/firmware.scm
> index ff5afbcbe1..728050b43a 100644
> --- a/gnu/packages/firmware.scm
> +++ b/gnu/packages/firmware.scm
...
> @@ -567,6 +569,36 @@ (define-public opensbi-qemu
>      (description
>       "This package contains OpenSBI firmware files for use with QEMU.")))
>  
> +(define-public opensbi-rvvm
> +  (let ((base opensbi-generic))
> +    (package
> +      (inherit base)
> +      (name "opensbi-rvvm")
> +      (source (origin
> +                (inherit (package-source base))
> +                (patches (cons
> +                          ;; Allows opensbi to work on systems with <32M of RAM
> +                          ;; https://github.com/LekKit/patches-misc/blob/cc40906fbf1de9ae466304157f2bf7b8cc909cbe/opensbi/opensbi_lowram_fdt.patch
> +                          (search-patch "opensbi-rvvm-lowram-fdt.patch")
> +                          (origin-patches (package-source base))))))

As discussed elsewhere, maybe try the unpatched opensbi-generic.


> +
> +      (arguments
> +       (substitute-keyword-arguments (package-arguments base)
> +         ((#:make-flags flags)
> +          #~(cons (string-append "FW_PAYLOAD_PATH="
> +                                 #$(file-append u-boot-rvvm
> +                                                "/libexec/u-boot.bin"))
> +                  (delete "FW_PAYLOAD=n"
> +                          #$flags)))))
> +      (inputs (cons u-boot-rvvm
> +                    (package-inputs base)))
> +      (description (string-append (package-description base)

So my main question is if you can use rvvm with an unmodified
opensbi-generic, passing opensbi-generic and the u-boot-rvvm as
commandline arguments? I know this can be done with qemu...

If it really isn't possible, then just drop the low-ram patch if that
still works.

Thanks!


live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

[bug#64907] [PATCH 2/2] gnu: Add opensbi-rvvm.

[Eva Kurchatova]

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