RISC-V has been supported in the upstream Linux kernel since 2017. But without a common hardware baseline, ensuring compatibility across builds and distros hasn’t been easy. The ecosystem was in need of a compelling, clearly defined hardware target – something both software and hardware teams could rally around to produce silicon capable of running stable, enterprise-grade software.
This target arrived in October 2024 with the ratification of the application-class RVA23 Profile – RISC-V-speak for a baseline configuration, similar to microarchitecture feature levels in x86. The culmination of years of progress, RVA23 brings together the work done to shape the ISA and standardize key extensions such as vector, bit manipulation and hypervisor.
↫ James De Vile at RISC-V International’s blog
Such a standard, stable baseline is incredibly welcome, and RISC-V working to have everything part of the upstream Linux kernel is crucial. Having to deal with out-of-tree patches and drivers and specific builds for specific boards is a nightmare – look at Linux on ARM – and hinders adoption of RISC-V.
I don’t know that having a standard microarchitecture profile will stop bad out of tree drivers that never get upstreamed. And it immediately writes off any existing RV64 silicon (like the P550) because none of it is compatible with the new profile.
I am very curious about RISC-V (I know it’s 5, but I always think and say VEE in my head) and I understand that the licensing is broadly open and people/companies can implement it in a million ways, and I wonder how well that will translate to creating computers a consumer could use. Is it so fragmented that a specific board will have to have a specific distro(s) or very specific versions of othe OSes or is it possible to create distros that will run across a broad number of boards?
I’m not an engineer or coder, just a user, so it intrigues me.
It translates the same as ARM. RISCV SoCs are the same amount of mess (replace ARM execution unit wirh riscv and you get basically what is on the market). Optional extensions mean nothing is supported anywhere and nothing is standarized beyond primitive OpenSBI, which doesn’t even compare to PC BIOS features from 386 era.
@iskios
While the state of things varies from vendor to vendor, things are better in RISC-V land. For example, HiFive, one of the most active RISC-V companies has upstream mainline Linux kernel support for pretty much all their hardware. However, not all RISC-V vendors do as great a job (eg. Allwinner). Still, the culture in RISC-V is more open than with ARM where we have vendors like Qualcomm, Rockchip, MediaTek, Apple, and….Allwinner.
And the adoption of OpenSBI in RISC-V is far more common than anything equivalent in ARM. This provides a standardized boot process, device discovery, some hardware abstraction, and drivers for simple hardware. This does not mean that you can boot to a full OS without drivers though (as you maybe can on an x86 with BIOS or UEFI). You still need hardware drivers (see paragraph one). Something like the PC BIOS assumes you are booting something like a PC. So the BIOS allows you to interact with the keyboard and screen for example. OpenSBI does not assume a keyboard or screen are even present and you need drivers for those if they are.
Finally, RISC-V uses “device trees” which is basically a static hardware description that the kernel uses to load drivers. I believe most ARM systems do as well. This means that the kernel has to be aware of a given ARM SoC and have a device tree for it. On x86, there is ACPI which dynamically discovers hardware instead.
While BIOS, UEFI, and ACPI in the x86 world are usually highly proprietary, the do make it a lot easier to bootstrap an operating system on any old x86 which is why folks like @pikaczex have the opinion that RISC-V is no better than ARM.
What this article calls out is that the RISC-V ISA is still evolving and, to this point, each new generation of RISC-V chip has implemented a new set of RISC-V extensions. This limits the “universality” of compiled RISC-V software (eg. a Linux distro) as, to be broadly compatible, you have to leave our useful extensions supported by newer hardware. With the RVA23 profile, the feature set is similar to what we fin d on x86 and ARM64 and so this seems like a reasonable target for distros to target for forward compatibility. However, as @thejpster says above, the issue at the moment though is that pretty much none of the popular RISC-V hardware in the market supports the full RVA23 spec yet.
In short, my view is that the situation in RISC-V land is quite a bit better than with ARM. Your hardware is much more likely to be supported in the mainline kernel if it is RISC-V than if it is ARM. However, you will still need support for each board to be added before it works in your distro of choice.