Full-Fat, Kernel-Ready: Why RISC-V Linux Needs Everyone Upstream

With the RISC-V software stack now maturing at pace, the cost of skipping the upstream has never been higher. I talk to the Linux leaders working to ensure code hits the kernel before silicon hits shelves.

By James De Vile, Editor, RISC-V International

Open instruction sets and open-source software have always shared a common DNA. That relationship is entering a new chapter – one defined by scale, maturity, and real-world deployment. With enterprise-grade Linux now booting cleanly on RISC-V silicon, we’re witnessing the convergence of two powerful ecosystems with shared values, accelerating momentum towards the platform’s readiness for general-purpose computing.

This is a space dominated by the big three commercial vendors: Red Hat, SUSE and Canonical. Red Hat’s developer preview of RHEL 10 for SiFive’s HiFive Premier P550 board, and Canonical’s upcoming Ubuntu build targeting RVA23, both demonstrate how mature Linux on RISC-V has become. These efforts reflect a shared vision: to make RISC-V a first-class citizen in the enterprise Linux ecosystem.

Consider a hypothetical enterprise running AI inference workloads on the edge. Today, using Ubuntu or RHEL on a board such as the P550, that organization can now develop, containerize, and deploy workloads in a familiar Linux environment – powered by RISC-V. It gets all the same enterprise-grade tooling, but on a power-efficient platform with flexible silicon options.

Linux distributions (distros) may compete on pricing, performance, service level agreement (SLA) coverage, and the quality of support (as well as, of course, the nuances of user experience and interface design) but at their heart lies the same kernel – a master recipe for a Linux operating system, maintained by Linus Torvalds and his team of dedicated custodians. The ‘tree’ is the primary source code repository for the Linux kernel; it’s where all new features and major development happen, and new releases (mainline, stable and long-term support [LTS]) live.

And change happens fast. On average, 8,300 new lines of code are added, 2,400 are removed and 2,100 modified within the Linux kernel every single day. And that number increases year on year. This January, the Linux kernel celebrated its source code surpassing 40 million lines of code.

Merrily Up The Stream

The process of getting your code accepted into the Linux tree is called ‘upstreaming’. Once upstreamed, that code – be it a driver, security module, power or memory management subroutine – becomes part of all future versions of Linux, no matter the distro. For every new release, this code will be automatically rebuilt and retested for free by the community, reducing long-term technical debt and maintenance costs. The aim is to ensure that when a user installs their chosen Linux distro on your hardware, it just works.

“It’s far faster and cheaper to get your code merged upstream than it is to keep it out of the tree”, says Greg Kroah-Hartman, Linux Foundation fellow and maintainer of the -stable Linux branch, as well as many aspects of the Linux subsystem. “It’s not just a case of it being ‘best practice’ – working out-of-tree will cost you a lot more money.”

This is by no means a new missive. RISC-V International CEO Andrea Gallo recalls a keynote by Ari Jaaksi in the early 2000s, discussing Nokia’s first Linux-based Internet tablet, the Nokia 770.

“Nokia had used a fixed version of the Linux kernel and WebKit browser, and then spent a year doing internal development”, he recalls. “When they finally attempted to realign with the latest upstream kernel, they were faced with hundreds of changes, massive retesting, and painful integration.”

This experience, said Jaaksi, led Nokia to embrace an upstream-first mentality from then on. It was a turning point in the company’s open source strategy and a cautionary tale for others: if you’re building on open source, the only way is upstream.

What Makes Upstreaming Critical for RISC-V?

Upstreaming RISC-V support into widely used open-source projects – not only the Linux kernel but also GCC (GNU Compiler Collection), OpenOCD (Open On-Chip Debugger), Quick Emulator (QEMU), and beyond – is critical to the architecture’s success. By contributing code directly to these mainline projects, the RISC-V community ensures that developers can rely on familiar, well-maintained tools without the overhead of custom patches or forks.

The benefits of upstreaming to RISC-V are clear:

• • Simplified development: RISC-V support is built into standard toolchains, eliminating the need for patched or vendor-specific versions.
  • Reduced fragmentation: Developers and vendors converge on a shared codebase, improving compatibility and reducing duplication of effort.
  • Improved stability: Upstream code is subject to rigorous testing, continuous integration, and long-term maintenance from the broader open source community.
  • Accelerated adoption: With upstream support in place, onboarding new developers and deploying across platforms becomes faster and more scalable.

Yet two decades since companies such as Nokia warned of the dangers of out-of-tree development, motivating hardware vendors to move away from patched downstream toolchains and engage with upstream development remains a surprisingly tough sell.

“Today, many RISC-V vendors are running out-of-tree Linux kernel forks with large sets of custom patches,” says Jeffrey ‘Jefro’ Osier-Mixon, Distinguished Community Architect at Red Hat and Outreach Committee Chair at RISE. “In some cases, systems rely on kernels that are over two years old, maintained with hundreds of out-of-tree drivers that never made it upstream.”

And woe betide anyone attempting to install a different distro on that hardware, adds Steve Wanless, Red Hat Enterprise Linux (RHEL) Business Strategist. “The OS doesn’t know what hardware it’s running on, can’t obtain correct hardware configuration, starts receiving unexpected interrupts, and the whole thing crashes – often in a very inelegant and difficult-to-diagnose way.”

Freedom to Innovate in Silicon

This kind of fragmentation undermines the stability and portability that open ecosystems rely on. RISC-V International exists to protect these same values – minimize divergence, promote long-term consistency, and ensure that innovation doesn’t come at the cost of compatibility.

“You need the freedom to innovate in silicon – introducing features in newer revisions or versions of the standard – but you also need to extend the standard in a way that’s accepted”, says Gordan Markuš, Director of Silicon Alliances at Canonical. “Only then can the software ecosystem deliver the right tools, plugins, and mechanisms to support your additions. For Linux distros to meaningfully support what you’re building, following the upstream process is essential – especially when it comes to areas like the kernel or low-level system interfaces.”

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.

The RVA23 Profile: A Common Ground

More than a spec sheet, RVA23 is a trusted foundation – and when developers trust that their code will run as intended and the spec won’t shift, they’re empowered to contribute upstream – knowing their work will still matter long after the next release cycle.

“With moving targets like RVA20 and RVA22, developers didn’t know where to aim”, explains Yuning Liang, Founder and CEO of DeepComputing. “RVA23 has given DeepComputing a standardized test platform for everything – distros, runtimes, frameworks, libraries, apps. It means RISC-V is no longer a moving target, and enables the hardware guys to do their upstreaming as early as possible. Then, the downstream becomes so much easier.”

“We’ve seen with other ISAs how important standardization can be”, says Wanless. “For us, having a clear, predictable set of specifications to design against makes all the difference. In the RISC-V world, it’s the same idea: we design for a profile, upon which platforms such as the upcoming RISC-V Server Platform can be built.”

Currently under member review, the RISC-V Server Platform is a specification for a standardized set of hardware and software capabilities that operating systems and hypervisors can rely on being present in a RISC-V server.

Red Hat’s commitment to building on RVA23 – and later the RISC-V Server Platform – is reassuring. The developer preview of RHEL 10 is much more than a bare-bones port: it’s a full-featured release engineered to align RVA23 with the same rigorous standards as RHEL on commercial ISAs. From SELinux to systemd, container support to cloud-native toolchains, the goal is clear: parity.

Canonical’s upcoming RVA23-targeted Ubuntu release is also eagerly awaited by the community. It ensures that users of Ubuntu Server and Desktop will soon experience the same polished experience on RISC-V as they do on other architectures.

“We’ve been building Ubuntu for RVA20 and RV64GC since 2021, initially supporting SiFive Unmatched boards”, explains Markuš. “RVA20 has served both developers and enterprises well, but to reach a broader enterprise audience and embrace new developers, we knew we had to move to RVA23. If you look at what comes as standard with other architectures and what RVA23 promises, it’s highly competitive.”

While RVA23 hardware won’t arrive until later this year at the earliest, Canonical made the bold decision to move to RVA23 earlier this year. The first RVA23 long-term supported (LTS) release, Ubuntu 26.04, is due April 2026.

“The move to RVA23 has required major engineering effort”, says Markuš. “Teams across Canonical – server, foundations, OpenStack, infrastructure management, and more – are all contributing. All to ensure that when platform builders release new hardware, the software is already available in Ubuntu.”

Fostering Hardware-Software Collaboration

By aligning with open source’s deeply rooted culture of collaboration, RISC-V has prompted would-be competitors to set aside their differences and unite around a shared goal: growing the ecosystem.

Of course, these companies vary on more than just price and service level. Each plays a unique role in what we all know to be a highly complex ecosystem. Red Hat, as a large multinational subsidiary of IBM, is as methodical as it is risk-averse in targeting the data center market with only open source software.

“The reason it takes Red Hat two years to turn open source components – many of which already have their own roadmaps – into a Red Hat product is because of the rigour we apply to productization,” explains Jefro. “RHEL must adhere to fixed schedules and deeply integrated QA pipelines curated by Red Hat to meet enterprise expectations.”

Canonical, meanwhile, is smaller and more agile in its approach. Traditionally, it has targeted its Ubuntu distro at home and small business users looking for an easy-in to the Linux world. Now, with Rivos on-side, it’s making waves in enterprise data center computing too.

“Canonical has been around for 20 years, yet we’re still a relatively small company” says Markuš. “We all want to see Linux succeed on RISC-V, and that means ensuring people have easy access to the best of what open source has to give. Obviously we’d like them to choose Ubuntu, but whatever distro they choose it’s still Linux, running on RISC-V hardware. That’s amazing, right?”

A Rising Tide Lifts All Boats

“The work we’re doing to bring Enterprise Linux to RISC-V will help to create a vibrant developer ecosystem for everyone” says Wanless. “A rising tide lifts all boats”.

It’s a fitting idiom; RISE is RISC-V’s software ecosystem cousin under the Linux Foundation, supported by a subset of RISC-V members and tightly integrated with our efforts. Its focus on upstream toolchains, runtimes, compilers and kernel testing has driven measurable, ecosystem-wide improvements. A key component of this is ensuring robust continuous integration (CI) support, which is crucial for seamless software development and deployment on RISC-V.

“RISE is a cornerstone to what we’re building”, says Gallo. “I see it as our open source software branch. It is instrumental in enabling foundational projects like Yocto, KernelCI… these are key parts of our ecosystem. My goal as CEO is to foster tighter alignment between RISC-V and RISE, to ensure hardware and software evolves in lock-step and enable a world-class developer experience.”

“Everything RISE does is open-sourced with the clear intention to upstream”, says Barna Ibrahim, vice chair of the RISE governing board and principal of business development at Rivos, Inc. “We ensure software support evolves alongside hardware innovation by fostering tight collaboration between hardware and software communities, from the start. By open-sourcing our work and actively engaging with ecosystem partners, we make sure software readiness is a priority, and not an afterthought.”

Ibrahim cites collaboration with open source software consultancy Igalia as a strong example of RISE’s ability to ensure toolchains evolve in lockstep with hardware.

“We expanded CI coverage beyond a QEMU config, adding multiple stage‑2 builds, targeting RVA20 in hardware and RVA23 in emulated environments”, she explains. “As a result, LLVM has already caught subtle bugs earlier, sped up feedback cycles, and set the stage for broader testing across spec variants.”

Canonical is a key voice in the RISE Linux Distro Integration Working Group, and RISE’s investments in language and runtime support have been incredibly helpful in turn, says Markuš. “RISE’s work on the Python ecosystem, for example, has been invaluable. Go (Golang), a language used extensively at Canonical, is another success – we were excited to see it ported and optimized for RISC-V.”

Building Long-Term Credibility

“To build long-term credibility, it’s essential to ensure the platform builds cleanly on all -rc and stable kernel releases, and to upstream all out-of-tree code” says Kroah-Hartman. “This isn’t optional. The Linux community shouldn’t be left guessing; active, transparent engagement with kernel maintainers must become the norm.”

Kroah-Hartman doesn’t mince words. He’s used to meeting regularly with hardware vendors targeting other ISAs, aligning on future design decisions, performance, and testing of new features to ensure that they work properly on their chips. Too rarely, he says, is that target RISC-V.

“If you’re a RISC-V hardware vendor and you’re not talking to us, you’re behind. It costs little and pays off enormously. To avoid repeating the early mistakes of other ISAs, the ecosystem must come together – now – to close the feedback loop and become a visible, reliable part of the upstream Linux community.”

Perspectives may differ in tone or conviction, but there’s a gentle through-line across these conversations: stepping too far from the upstream process – whether through patched kernels, closed loops, or bespoke toolchains – risks isolating innovation rather than enabling it. In contrast, upstreaming gives everyone a stake in progress. It’s not only about efficiency or elegance; it’s about aligning around shared infrastructure, creating fewer blockers and more builders.

“To me, all of this boils down to building trust” says Gallo. “Trust that we all have each others’ best interests at heart. Trust that the software will run, that the toolchains will be there, and that the community will show up to support and improve what’s been built. The work we’ve seen from Red Hat, Canonical, RISE, and countless others shows what’s possible when hardware and software evolve together.”

RISC-V’s role as a platform for fully fledged operating systems is a rapidly maturing reality, with RVA23 acting as both a catalyst and a common foundation. The momentum is undeniable – but momentum alone is not enough. To sustain it, we all need to swim upstream. It’s the clearest path to compatibility, the fastest route to scale, and the strongest signal to developers that RISC-V is ready for anything they can throw at it.