By ByteBot
RISC-V crossed 25% global market share in 2026 — a milestone that felt aspirational just four years ago. This week, a detailed technical critique titled “RISC-V: They Should Have Known Better” hit the top of Hacker News with over 200 points and nearly 300 comments. The critique lands at exactly the wrong moment: almost every RISC-V board you can buy today won’t be compatible with the binary standard that Ubuntu, Android, and Red Hat are already building toward.
The RVA23 Gap: RISC-V’s Binary Compatibility Problem
RISC-V International ratified the RVA23 Application Profile to solve binary fragmentation across application processors. The profile mandates a specific set of extensions — Vector (V), Hypervisor (H), bit-manipulation (B), and others — so that a binary compiled for one RVA23-compliant chip runs on any other without recompilation. The Android RISC-V ABI baseline is RVA23. Ubuntu has committed to RVA23 as its targeting baseline. This is real, meaningful progress.
The problem: nearly no consumer hardware meets it. The VisionFive 2, the most popular RISC-V SBC on the market, runs SiFive U74 cores implementing RV64GC — not RVA23. The Banana Pi BPI-F3 and Lichee Pi 4A are in the same boat. As Dmitry.GR documents bluntly: “approximately none of the currently available RISC-V SBCs are actually RVA23 compliant.” The RVA23 profile exists on paper; the hardware ecosystem hasn’t caught up. Developers buying these boards today may find themselves on hardware that future OS releases quietly drop.
Optional Everything Is Optional Compatibility
The root cause is architectural. RISC-V’s base specification makes almost everything optional: multiply and divide (M), atomics (A), floating-point (F/D), compressed instructions (C), and even CSR access (Zicsr). Each optional extension splits RISC-V into two incompatible groups. The community defends this as a feature — future architects won’t inherit today’s mistakes, unlike ARM and x86 with their decades of legacy baggage. That argument holds for the architecture’s long-term trajectory. It does not hold for developers who need to ship software today.
The fragmentation goes deeper than extension mismatches. Two extensions can assign the same opcode to different operations depending on which extensions are active. Upgrading to a chip that supports more extensions can silently corrupt registers in binaries built for chips with fewer extensions — no exception, no trap, no warning. Meanwhile, the primary mechanism for detecting optional features at runtime is CSRs. Specifically, the misa register. The catch: CSRs are in the optional Zicsr extension. And misa can legally return all zeroes even when implemented. The only way to detect optional features is itself optional. GCC 12.x surfaced this problem when it made Zicsr explicitly optional, breaking builds across projects that assumed CSR access was always present.
Where RISC-V Works — and Where It Doesn’t
The fragmentation problem is severe in the consumer SBC and general-purpose application processor space. However, it’s mostly a non-issue in two areas that represent most of RISC-V’s current volume: embedded MCUs and custom silicon. When building an IoT sensor or an AI accelerator on RISC-V, you control the full hardware/software stack. The extension set is fixed and documented for your specific chip. Binary portability across chips is irrelevant — you’re not shopping for pre-built binaries. This is where RISC-V wins cleanly against ARM Cortex-M licensing costs.
Nevertheless, RISC-V’s interrupt handling performance is weaker in embedded scenarios. ARM Cortex-M0 handles interrupt entry/exit in approximately 27 cycles. RISC-V requires around 44 cycles in typical configurations — over 60% more overhead for the most latency-critical embedded operation. For many use cases this doesn’t matter. For hard real-time systems, it does. Enterprise RISC-V server silicon — Ventana Veyron V2, Alibaba T-Head — is targeting RVA23+ from the start, making the enterprise server path considerably cleaner than the consumer SBC path.
Related: WASI 0.3.1 and the Component Model: What Developers Need to Know
What Developers Should Do Right Now
RVA23 is genuine progress. The ecosystem is moving toward it, and the hardware will eventually follow. However, “moving toward” and “already there” are two different things, and the consumer hardware market is firmly in the former category. Developers evaluating RISC-V boards for projects that will run mainstream OS distributions should verify RVA23 compliance explicitly — don’t assume it. For embedded or custom silicon projects where you own the full stack, RISC-V remains a strong choice. For everything else, the fragmentation problem is real and unsolved in the hardware you can buy today.
Key Takeaways
- RISC-V’s 25% market share milestone is real — and so is the fragmentation problem arriving alongside it
- Nearly every consumer RISC-V SBC available today (VisionFive 2, Banana Pi BPI-F3) does not meet the RVA23 profile that Android and Ubuntu now target
- The “optional everything” design creates genuine runtime incompatibilities: same opcodes mean different things on different RISC-V chips, and feature detection at runtime is unreliable
- RISC-V works well for embedded MCUs and custom silicon where you own the full stack; for consumer SBCs, verify RVA23 compliance before buying
- Enterprise RISC-V server chips target RVA23+ from the start — the enterprise path is cleaner than the hobbyist path right now
