As the open source Zephyr RTOS continues to grow in popularity, with most of the leading semiconductor vendors supporting the project as members, the open RISC-V ISA also sees ever-increasing adoption in real-world use cases, including at those same major semicon players. One of Zephyr’s claims to fame has always been its structuredness and configurability, which mirrors very well the modular and extendible nature of the RISC-V ISA. The latest 3.6.0 release features a lot of RISC-V related updates, strengthening the claim of Zephyr as the best choice of OS for emerging platforms with the open ISA.
Antmicro has been supporting the project since the introduction of RISC-V to Zephyr in 2017, picking up the mantle of lead maintainers of the RISC-V port in 2018. Antmicro has been contributing their experience with developing real RISC-V implementations and products to the RTOS, and aligning the interests of other Linux Foundation projects like the RISC-V International and CHIPS Alliance with Zephyr.
Within the Zephyr Project, Antmicro’s RISC-V maintenance covers both making and reviewing contributions to the codebase, including routine maintenance activities such as bug fixes and minor API updates, more involved work like the addition of new boards, drivers, features and targets up to participating in major upgrades to Zephyr RTOS, such as the recent switch to the Hardware Model v2. Below, Antmicro will cover key recent developments in the Zephyr port for RISC-V as well as providing a list of bug fixes, code cleanups and general housekeeping activities, where Antmicro was joined by a number of fellow RISC-V and Zephyr members, most notably Microchip, Meta and Nordic Semiconductor (who spearheaded the HWMv2 effort in general).
Key recent developments: HWMv2, new RISC-V platforms
In early 2024, Zephyr RTOS adopted the new HWMv2, which required a considerable amount of cross-community effort in transitioning the previous hardware models across many architectures to the new specification. HWMv2 provides for clearer and more unified descriptions of a board’s SoC, CPU cluster, variants and revisions, as well as a better grouping of SoCs by series, families and architectures.
HWMv2 has also helped enable better coverage of more complex boards, including those which incorporate RISC-V, by adding support for multi-core SoCs and multi-SOC boards, as well as more advanced use cases. To enable the switch to HWMv2, Antmicro had to port over a number of platforms based on the SiFive SoCs.
As the RISC-V ecosystem continues to expand, so does Zephyr’s support of RISC-V targets, now including the Starfive VisionFive2 RISC-V SBC (#69814) and the Beagleboard BeagleV-Fire (#66389). These are popular, low-cost and widely available RISC-V platforms with many potential commercial applications thanks to their wide array of I/O, as well as – in the case of BeagleV-Fire, on-board reconfigurable FPGA fabric.
With the addition of support for the Auto Update feature on the PolarFire SoC, Zephyr gained the ability of writing an FPGA bitstream to the SPI flash that connects to the system controller. The Zephyr FPGA Manager was originally developed by Antmicro, allowing users to control FPGA chips from directly within Zephyr.
More flexible RISC-V support, virtual targets
By introducing the CONFIG_PLIC_SHELL command, it is now possible to get the hit count of each interrupt controller’s IRQ line. This adds an interactive way of interacting with and debugging the PLIC, i.e. getting statistics about interrupts that were triggered and so on.
A particularly helpful feature introduced recently was the provision of PLIC driver support edge interrupts, which lets the user configure them from the devicetree.
By linking code and data blocks, e.g. the vector table, into tightly coupled memory, Zephyr can now selectively put parts of the final Zephyr build into faster memories that are present on a particular SoC.
Zephyr now supports SoCs that do not number their harts (or cores) sequentially from 0, which is permitted by the RISC-V specification. The removal of this limitation means that more RISC-V SoCs can be supported by Zephyr.
On the simulation front, one of the most exciting new additions to Zephyr has been the inclusion of a virtual RISC-V SoC, contributed by Meta and designed to work with our Renode simulation framework, allowing for comprehensive testing of Zephyr-based applications in CI. The virtual RISC-V SoC can be extended easily with the addition of peripherals or custom extensions in Renode, and was created for the purposes of testing hardware configurations that only exist in custom boards that exercise the flexibility of RISC-V but cannot be directly contributed to the Zephyr tree.
Bug fixes, code cleanup, and general housekeeping efforts
In addition, a considerable amount of work was undertaken in terms of routine maintenance of the port, including housekeeping tasks and code cleanup, as described below.
- General cleanup of the Microchip’s PolarFire SoC, including making the devicetree sources align with Linux #66082
- IRQ #67829 and header cleanups #67450 along with arch_cpu_idle #67432
- PMP is now enabled #70890 on the default revision of the SiFive HiFive 1 board.
- Small fixes #70214 and #70225 in the YAML file that Twister (the Zephyr testing framework) uses. This was accompanied by a new requirement of using proper architecture names #70225 to avoid the need for similar future bugfixes.
- The board name conventions used by ITE RISC-V platforms were unified #67723
- Two changes #67791 and #66429 were made with our dts2repl tool in mind, which also required all RISC-V CPU nodes in Zephyr to declare compatible strings and ISA extension strings, These changes also can be used later by other tools to, e.g. enable required RISC-V ISA extensions.
Numerous bug fixes were also carried out, including:
- andes_v5: fix missing header in PMA driver and the MPU padding issue in linker.ld #68265
- arch: riscv:disable interrupts before wfi #70372
- arch: riscv: fix hangup of multicore boot #65000
- boards: riscv: stamp_c3: Update systimer configuration #66922
- drivers: intc: plic:Fix memory-mapped register offset calculation #65283
- drivers:intc_plic: fix plic PLIC_TRIG_LEVEL define mistake #67301
- drivers: interrupt_controller:intc_plic: get_plic_dev_from_irq was rewritten #65807
- drivers: plic: fix compilation warning when PLIC_SHELL is enabled on 64bit platform #67193
- dts: opentitan: update plic interrupt count to match spec #70123
- linker: Fallback to Kconfig when defining ROM region #67849
- linker: riscv:Align .last_section #63857
- nrf54h: fix VPR core dependencies #68918
- qemu_riscv32_xip alignment #62975
- RISC-V clic update #66759
- risc-v: drivers: intc_plic: enabled interrupts to be handled by all cores #65922
- riscv: linker:Fallback to Kconfig when defining ROM region #68457
Driving Zephyr and RISC-V forwards in 2024
Thanks to its flexibility, Zephyr can be used to cover a variety of scenarios, running on both co-processors, main CPUs and in heterogeneous setups. To broaden the use cases of the RTOS with RISC-V to tackle complex scenarios, Antmicro is pursuing efforts such as implementing Zephyr as a RISC-V Linux bootloader, as well as enabling co-design of Zephyr-based AI solutions with our open source Kenning machine learning framework through Kenning Zephyr Runtime. Antmicro is also working on improving the ease of use of Zephyr in soft RISC-V CPUs and SoCs through enhancing Zephyr’s capabilities to support the modularity of the ISA.
If you would like to learn more about Antmicro’s recent work – which includes a large dose of RISC-V and Zephyr – you can watch Antmicro’s talks from the Zephyr Developer Summit:
- Automated, simulation-based flow for low-cost FPGA-accelerated devices with Zephyr on BeagleV-Fire
- Warp Pipe: library for simulation-driven development of PCIe devices based on Zephyr
- Generate, develop and visualize Zephyr platforms and apps with Antmicro’s Visual System Designer and Renode
Follow Antmicro’s social media for more information about upcoming and future Zephyr-related talks or meet the team at Zephyr or RISC-V industry events to see how both technologies can be used together to enable software-driven, future-proof products.