Ubuntu mandated RVA23 as the minimum supported RISC-V baseline starting with Ubuntu 25.10, and two signals this month confirm the mandate has teeth. SpacemiT shipped the K3, a 60 TOPS RISC-V SBC running mainline Ubuntu 26.04 without a board-support-package fork. SiFive shipped the Performance P570 Gen 3 and led the announcement not with clock speed but with mandatory RVA23 vector semantics, the same distinction that determines whether an embedded Linux distribution can build once and run everywhere or must maintain per-board forks per vendor. The constraint being removed is not processor performance. It is toolchain maintenance: the BSP-fork obligation that makes RISC-V embedded Linux teams dependent on vendor release schedules for kernel patches, security fixes, and driver upstreaming. The portability argument for staying on Arm just got materially weaker.
The BSP tax and why it never went away
The RISC-V architecture has always allowed vendors to implement ISA extensions optionally. That flexibility is a feature for silicon designers and a recurring maintenance problem for software teams. A board with optional vector extensions requires an OS image that detects the hardware, branches to vector-accelerated code paths when available, and carries fallback paths for boards that lack them. Multiply that across Zifencei, Sstc, hypervisor support, and a dozen other extensions and you get the BSP-maintenance tax: every embedded Linux team targeting RISC-V has historically maintained vendor-specific kernel forks and distro customizations that diverge from mainline the moment a peripheral driver merges upstream on a different SoC.
ARM solved the same problem in the early AArch64 era when SBSA and PSCI imposed a firmware and ISA floor that let distros ship one kernel image across heterogeneous platforms. The RISC-V community understood the analogy. The solution, profiles, was obvious. What was missing was ratification and a distro willing to enforce it.
RVA23, ratified by RISC-V International in 2024, changes the algebra by making vector instructions, hypervisor support, and several previously optional extensions mandatory for any SoC claiming profile compliance. A software build targeting RVA23 can ship one kernel, one distro image, one set of vector-optimized binaries. Canonical moved first: Ubuntu 25.10 made RVA23 the minimum baseline, moving RVA20 boards to long-term maintenance mode under Ubuntu Pro without new feature investment, a gated platform policy rather than an advisory.
Why now and not three years ago
Three conditions converged in 2024 and 2025 that did not exist earlier.
The standard reached ratification. RVA23 was in development since 2022 but did not clear RISC-V International's ratification process until 2024. Before ratification, committing silicon to an unratified profile was a program risk. After ratification, it was an engineering decision.
A major distro enforced it. The RISC-V portability story has been told since 2018. What changed is that Canonical's decision to gate new platform support on RVA23 compliance created a direct business consequence for SoC vendors: ship a non-compliant chip and your customers cannot run mainline Ubuntu on it going forward. That constraint forced SpacemiT, SiFive, and StarFive to treat profile compliance as a tape-out requirement, not a checkbox.
Sufficient RVA23-compliant silicon now ships in production. Embedded World 2026 in March confirmed the vocabulary has shifted from aspirational to operational at the SoC vendor tier. Andes Technology reported over one million consumer units shipped on RVA23-capable cores. SpacemiT's K3 is production-qualified on mainline Ubuntu 26.04. SiFive's P570 Gen 3 delivered a 21x AI workload improvement over its first-generation baseline, and the mechanism is the mandatory vector pipeline, not a bolt-on accelerator. The compliance floor is shipping hardware, not roadmap.
Who benefits
The primary beneficiary is embedded Linux teams doing edge AI designs at 1 to 60 TOPS on a constrained budget. The SpacemiT K3 proposal (60 TOPS INT4, 8 RISC-V cores, Ubuntu 26.04 mainline, no BSP fork required) was not commercially available two years ago. Mainline kernel support means security patches land on the upstream schedule. It means the Yocto and Buildroot communities can target the platform without board-specific layers. It means software teams stop writing BSP maintenance into project plans.
Toolchain maintainers benefit directly. The Yocto Project 6.0 release in May ships SPDX 3.0 SBOM generation as a default output. Pairing that with mandatory-profile RISC-V silicon means teams building EU Cyber Resilience Act-compliant connected devices can run a reproducible build stack without a vendor relationship gating their kernel patches.
The open ecosystem grows more valuable as compliance convergence reduces the variant space. A vector optimization merged into the mainline kernel now benefits every RVA23 board instead of sitting stranded in a vendor fork.
Who is exposed
The exposed category is Arm Cortex-A licensees selling into the embedded Linux market below 2 GHz single-core. NXP's i.MX family, Renesas RZ family, and ST's STM32MP series have all relied on an implicit assumption: RISC-V fragmentation costs exceed the switching costs from their platforms. That assumption erodes as RVA23 compliance converges mainline support.
Arm faces a structural question in this tier. Royalties from mid-market embedded application processors are a material revenue line. Qualcomm's decision to ship its first RISC-V module (the QCC74xM, at $13.12 EVK and under $3 per module, priced to displace ESP32) signals that even Arm's own licensees are hedging the embedded IoT tier with RISC-V. When Qualcomm, which pays Arm royalties as a licensee and competes with ESP32 as a product vendor, decides the RISC-V play is worth shipping at cost parity, the competitive calculus has already shifted.
Jon Peddie Research, surveying the landscape in late April, put it plainly: RISC-V is becoming the connective tissue of AI hardware, appearing as safety monitors, management processors, and always-on inference cores across chiplets and SoCs that use other ISAs for their primary compute. That role does not threaten Arm's high-performance compute moat. It does reclaim the territory Arm's licensing model priced as defensible.
What builders should do now
If your next embedded Linux design targets 1.5 GHz or below and BSP maintenance is a line item in your project plan, evaluate RVA23-compliant SoCs against your shortlist before your next tape-in review. The cost is two to three engineer-weeks of benchmarking. The upside is removing a recurring maintenance obligation that has no terminal date on most Arm platforms. The test is concrete: track whether the SoC vendor's peripheral driver patches land upstream within two mainline kernel cycles. On a fully RVA23-compliant SoC with no proprietary peripheral stack, that test is now verifiable rather than aspirational.
If you are a platform vendor at the embedded Linux tier and your next SoC roadmap does not include an RVA23 variant, the customer renewal conversation just got harder.
What could break this
Two things could slow or reverse the shift.
The BSP problem reappears at the peripheral layer. RVA23 profile compliance governs the core ISA. Vendors who ship proprietary peripheral controllers (custom Ethernet MACs, closed display engines, bespoke USB stacks) outside the profile still require out-of-tree kernel patches, which recreates the fragmentation the profile was intended to remove. If silicon vendors treat RVA23 compliance as a marketing checkbox while keeping their peripheral stack proprietary, the maintenance advantage collapses upstream.
Arm could respond with contractual leverage. If Arm's licensing terms for next-generation Cortex-A profiles include provisions requiring major distro vendors to maintain Arm-first build paths (a negotiation Arm's current market position enables), the Ubuntu move matters less for the customer segments Arm prioritizes. RISC-V's mainline path is strongest in the independent embedded Linux market. If Arm protects Android and server, which it almost certainly will, the exposed tier is narrower than the broad framing implies.
Inside 24 months, either NXP, Renesas, or ST announces an RVA23-compliant RISC-V variant of an existing Cortex-A MPU family, or at least one of the three quietly exits the sub-1.5 GHz embedded Linux tier. The falsification test is not abstract: track whether the top three RVA23-certified SoC vendors land peripheral driver patches upstream within two kernel cycles each. If they do, the BSP tax is gone and the Arm pricing assumption in this market segment does not survive the next embedded Linux design cycle.