Genode on RISC-V - an Update
RISC-V support on Genode has been around for five years by now. Our initial RISC-V port to the base-hw kernel reached back to the privileged ISA specification 1.7 while the current stable version is already at 1.11. Therefore, we have experienced quite a big part of the RISC-V evolution and generally appreciate the direction RISC-V is heading.
Unfortunately not much real hardware, besides SiFive and FPGA versions, had been around at the time of our development efforts and we had to rely on the Spike emulator. Emulators have the disadvantage that they often don't emulate things like caches or TLBs of real hardware. So an operating system running on an emulator usually is not complete. Additionally, the Spike emulator does not offer any peripheral hardware, making it suitable for proof of concept work only. Therefore, Genode's RISC-V development had been on a hold for a while.
The situation changed when Genode Labs received a MiG-V development kit from Hensoldt Cyber. The board features an ASIC version RISC-V logic-encrypted processor that implements privileged ISA specification 1.10 and user level ISA 2.1. Additionally, the SoC offers many peripherals like Ethernet, I2C, SPI, flash memory, and JTAG making it suitable for real-world Genode workloads.
In order to support MiG-V, Genode's RISC-V implementation had to be bumped from privileged ISA version 1.9.1 to 1.10. During the course of this work, we also wanted to replace the Spike emulator and instead take advantage of Qemu's RISC-V support. Since all Genode-supported CPU architectures can already be executed in Qemu by now, we welcomed the chance for consolidation.
ISA 1.10 update
The update to ISA 1.10 went straight forward. Next to some additional exceptions (like load and store access faults), the biggest change with ISA 1.10 is the replacement of the "Supervisor Page-Table Base Register" (sptbr) with the "Supervisor Address Translation and Protection" (satp) register. Whereas sptbr already marked an improvement because it merged the page-table base pointer and the address space ID into one register - making atomic address space switching easy (please refer to this article of why this is important), satp additionally allows us to enable paging and configure the page table format in one single operation. With ISA 1.9.1, this operation had to be performed by the machine mode (M-mode) implementation, which meant paging had to be enabled before entering supervisor mode (S-mode) for the first time and initial page tables for S-mode were required. This also implied that S-mode could not change the page-table format from the one configured by machine mode.
Machine mode implementation
A new ISA also requires an update of the machine-mode implementation. Machine mode handles the boot loading of the platform, receives all traps/exceptions/interrupts, and implements the "Supervisor Binary Interface" (SBI). SBI is meant to hide platform specific hardware differences from S-mode. For example, an SBI call is used by Genode in order to program the timer. What hardware is used and how the timer is programmed is transparently handled by the machine mode implementation - relieving Genode from board-specific knowledge. Whereas MiG-V offers it's own OpenSBI compliant machine-mode implementation, the switch to Qemu made it possible to remove our old Berkeley Boot Loader machine implementation because Qemu (>=4.2.1) offers OpenSBI firmware when using the
-bios default
switch. This way, it became possible to unify the SBI interface between Qemu and MiG-V.
Genode integration
We have split the RISC-V Genode implementation into two parts. First, the generic ISA 1.10 and the Qemu board support can be found within mainline Genode - starting with release 21.02. The MiG-V support has been moved into a separate repository that will also contain future RISC-V SoCs. The motivation behind this separation can be found at Norman's Genodians article under "A new home for board support".
Future
In the next step, we want to implement RISC-V's interrupt controller support (PLIC) in order to enable peripherals. As for Qemu, since we chose the virt platform as a target machine, VIRTIO support comes to mind.