Porting an Automotive Operating System to RISC-V

RISC-V in Automotive

RISC-V is an open instruction set architecture (ISA) based on reduced instruction set computer (RISC) principles. RISC-V has a growing ecosystem, supported by companies including NVIDIA and Qualcomm, and open-source groups, positioning it as a viable alternative to traditional proprietary architectures.

Equipped to be a major player in the automotive industry, RISC-V’s extensible architecture enables automotive-specific specialisations and optimisations to be integrated, ensuring the hardware meets the use case.

The unified architecture of RISC-V enables it to scale from simple sensors to high-performance autonomous driving systems on chips (SoCs). For example, a car might use RISC-V microcontrollers and powerful RISC-V-based SoCs in advanced driver assistance systems (ADAS), leveraging the same instruction set and tooling across very different compute needs.

RISC-V allows for multiple processing units all to use the same base ISA with different extensions, depending on the unit's purpose. Resulting in a chiplet architecture made up of graphics processing units (GPUs), neural processing units (NPUs) and central processing units (CPUs), all of which are based on RISC-V.

In addition, the open nature allows for multi-sourcing. For instance, an automotive supplier can source RISC-V chips from multiple vendors such as Infineon and SiFive, mitigating risks associated with supply chain shortages and reducing dependency on a single vendor. As a result, RISC-V is on the brink of transforming the automotive industry.

It may have already started. Infineon announced the release of an automotive microcontroller family based on RISC-V. This will be part of Infineon’s well-established AURIX microcontroller brand, with a virtual prototype already available. NVIDIA, one of the leading companies in the automotive industry, already shipped one billion RISC-V cores in 2024.

Porting Software

RISC-V, as a new ISA, requires software to be ported to support it. This work is being undertaken by an extensive community, including companies, working groups, and open-source community members. Due to RISC-V’s clear alignment with free and open-source software (FOSS) ideals, there has been a highly enthusiastic community response, including support for RISC-V added to the Linux kernel in 2017.

However, many components, both FOSS and proprietary, still do not support RISC-V.

Codethink Trustable and Reproducible Linux (CTRL) is Codethink's own safety-oriented platform development kit (PDK) used in automotive and industrial projects. Due to the clear benefits of RISC-V’s use in automotive and its alignment with FOSS principles, Codethink added RISC-V support to CTRL to demonstrate porting a large mature software project to RISC-V.

CTRL is built upon the foundation of Freedesktop SDK, which already supports RISC-V. Therefore, it is well placed to answer the question: how hard is it to port a Linux-based OS to a RISC-V target?

CTRL to RISC-V

Adding support for a new ISA can be more involved than just adding an additional target. Therefore, the porting of CTRL is a phased adoption of RISC-V, broken into three parts:

• Supporting RISC-V target compilation in the build environment
• Building CTRL for RISC-V and running on a virtual target
• Adding support for actual RISC-V hardware target

Updating the build container to add support for RISC-V targets means ensuring all tools in the container support the RISC-V ISA, mirroring any additional dependencies for the RISC-V versions of the tooling, and adding the RISC-V container build as an optional, manual step as part of the containers' continuous development (CD) pipeline. This was fairly straightforward; the only challenges centred on components that didn’t produce releases for RISC-V, including OpenTofu and Jsonnet. For this initial implementation, these components could be excluded from the RISC-V container as they were not required for the later stages of porting CTRL.

The second stage of RISC-V adoption requires the support of virtual targets, which are crucial in automotive as they align with “shift-left” strategies from software-defined vehicles (SDV). Using a virtual target enables shorter cycle times and easier debugging during RISC-V porting. Since CTRL already supports both Aarch64 and x86_64 QEMU virtual targets, it is a logical extension to support the qemu-system-riscv64 target.

When porting to the QEMU RISC-V target, the main challenges faced were related to intricacies in the UEFI boot stage. UEFI expects the next-stage binary, in this case, grub2, to be named bootriscv64, which differs significantly from the x86 and Aarch64 naming patterns (bootaa64 and bootx64). Further on this front, the default edk2 vars meant that the UEFI stage was not attempting to run the grub2 binary. The final QEMU command used to run CTRL for reference was:

1
2
3
4
5

qemu-system-riscv64 -nographic -M virt -m 2G -smp 4 \
    object rng-random,id=rng0,filename=/dev/urandom -device virtio-rng-pci,rng=rng0 \
    nic user,model=virtio,hostfwd=tcp::2222-:22 \
    drive if=pflash,format=raw,file=edk2-riscv-code.fd,readonly=true \
    drive format=raw,file=riscv_image/disk.img

After porting to the virtual target, and confirming all the expected functionality was present, CTRL was ported to the RISC-V hardware target, the Banana Pi BPI-F3. This board was chosen as it is readily available and widely supported throughout the RISC-V ecosystem, containing a SpacemiT K1 octa-core RISC-V processor. The process was made up of three main steps:

1. Building the bootloader components (OpenSBI and U-boot)
2. Building the BPI-F3 Linux kernel
3. Constructing a flashable image for an SD card

Although the sources for the BPI-F3 versions of OpenSBI, U-boot and the Linux kernel are easy to find and construct, they are maintained in forked repositories, rather than being upstreamed to official open-source repositories. This is a common pattern among RISC-V hardware, and other architectures as well, that is detrimental to the industry. By maintaining these sources separately, these sources will eventually drift from the upstream, meaning they lag behind in functionality, and the patches applied will be tested less, increasing the chances of bugs.

Challenges Encountered

Throughout this work, there were two issues common across all stages.

The first issue is the comparatively poor performance of the currently available RISC-V hardware when compared to Arm and x86. Since CTRL is built with Apache BuildStream, which is primarily aimed at native compilation, CTRL had to be compiled on RISC-V hardware. For a full build of CTRL, with every component built from source, this took over 24 hours on the Milk-V Pioneer hardware. BuildStream has in-built caching of components, which supported a significantly quicker rebuilding process and reduced the time to around 2 hours for full kernel rebuilds.

The second recurring issue is that, since RISC-V is still relatively new compared to other architectures, many projects still do not produce RISC-V releases as standard, and some do not even support RISC-V. Luckily, all of the core components required for CTRL did have RISC-V support. It is important to note that the Linux Foundation have also produced a course on porting software projects.

Conclusions

So, how hard is it to port a Linux-based OS to a RISC-V target?

The answer for us was: trivial. A single Codethink engineer completed all three stages described above in under a week. The move to RISC-V has never been easier. Although hardware may still be under development and some software dependencies may not yet support RISC-V, there is considerable value in adding support for a new ISA sooner rather than playing catch-up later.