RISC-V Embedded Linux: What’s Real, What’s Not

Ask two engineers whether RISC-V embedded Linux is real, and you will often get two opposite answers. One will show you a board that costs under twenty dollars booting mainline Linux. The other will note that no mass-market phone, set-top box, or industrial gateway on sale today uses a RISC-V application processor.

Both statements are correct. RISC-V is ready in some layers of the software stack and not ready in others, so the accurate answer depends on which layer you are asking about.

What actually became real

The foundational layers now work in production, not only in demonstrations. In August 2025, Debian 13 (“trixie”) shipped with riscv64 as an official release architecture, the first Debian release to support RISC-V as a first-class port, with more than seventeen thousand source packages building for it. Ubuntu and Fedora also provide working RISC-V images, and openEuler has invested heavily in RVA23 server support.

The RVA23 profile, ratified in 2024, defines a single application-processor baseline for distributions, toolchains, and the mainline kernel to target, and it makes the vector and hypervisor extensions mandatory rather than optional.

The toolchain is now complete for most work. GCC and LLVM both support RVA23 and the ratified vector extension (RVV 1.0). Zephyr and FreeRTOS have stable RISC-V ports, OpenOCD supports the common debug probes, and GDB works as expected. In hardware, several boards run mainline Linux directly, which is covered in detail below. If you stay on these mainline-supported parts, you avoid the most common problem with early RISC-V hardware, which is a kernel that is not upstream.

Why now, and what the share numbers hide

Two forces explain why RISC-V momentum is stronger now than in earlier years. The first is supply and design sovereignty. Because the instruction set is an open standard that no single company or country controls, vendors and governments are adopting it to reduce dependence on one supplier. Much of the newest hardware and software comes from this push: the SpacemiT and Sophgo SoCs are from Chinese vendors, and the openEuler distribution has invested heavily in RVA23 server support.

The second force is automotive. Industry groups now treat automotive as the proving ground for production-grade RISC-V, and the certification work has started. SiFive’s automotive processor IP ships with ISO 26262 functional-safety packages at ASIL-B and ASIL-D and is compliant with the ISO/SAE 21434 cybersecurity standard. This is real progress, and it is also still early, because certifying processor IP is not the same as a fleet of certified vehicles in production.

The widely repeated claim that RISC-V reached about 25 percent market share needs care. That figure counts RISC-V cores shipped across every category, and most of that volume is microcontrollers and small control cores embedded inside other chips, such as the RISC-V cores NVIDIA ships inside its GPUs, rather than Linux-capable application processors. The number is a real sign of adoption, but it does not mean a quarter of the application processors you would build an embedded Linux product on are RISC-V. For that specific use, the honest count is much smaller.

What is still immature

The part of embedded Linux that decides whether you can ship a product is not the instruction set. It is the board support package: the specific kernel, device trees, bootloader, and vendor drivers for your exact SoC and its image sensor interface, GPU, video codecs, and power management, maintained for the life of the product.

On RISC-V this layer is still immature. For the newest high-performance SoCs, the BSP is often not upstream at launch, and the work to upstream and maintain it is happening now rather than years ago. Industry groups such as RISE are funding mainline BSP work for the SpacemiT K1 boards and the first RVA23-class parts. This is useful progress, but the fact that it is still in progress describes the current state accurately.

The mobile market gives the clearest measure. In 2024, Google removed RISC-V support from the Android Common Kernel and said it was not ready to provide a single supported Generic Kernel Image for the architecture, while stating that Android would continue to support RISC-V through AOSP. In plain terms, a very well-resourced software organisation could not yet make RISC-V a tier-1 kernel target. This is not a judgement on the instruction set. It measures how much work the surrounding software and vendor ecosystem still requires.

Where performance really sits

On performance, the accurate statement includes both strengths and limitations. High-end RISC-V application cores such as SiFive’s P-series and Ventana’s Veyron are narrowing the difference with Arm Neoverse, and RISC-V is already strong in fixed-function and accelerator roles, which is why it ships in large volumes as control cores inside other chips.

However, the fastest Arm and x86 cores still lead in single-thread performance in 2026, and Arm holds most of the smartphone and established embedded markets. For a typical embedded Linux product, current RISC-V application SoCs perform like mid-range Arm parts from a few generations earlier. That is enough for many products and not enough for others.

As one concrete example, at RISC-V Summit Europe 2026 the company DeepComputing demonstrated its DC-ROMA RISC-V laptop running a 7-billion-parameter DeepSeek model locally, without a GPU or a cloud connection, and it publishes a guide for installing DeepSeek-7B on its DC-ROMA RISC-V hardware. Current RISC-V hardware can run real workloads, even though it does not yet match the fastest Arm and x86 parts.

The boards you can actually buy today

RISC-V Linux boards now fall into three practical groups: inexpensive boards for learning and general Linux, boards with the ratified vector extension for AI and signal-processing experiments, and workstation-class boards for compiling and testing RISC-V software natively. The table below lists the boards most worth considering. Each runs a 64-bit, Linux-capable application processor.

A few practical points follow from the table. The StarFive JH7110 boards (VisionFive 2, Milk-V Mars) and the SpacemiT K1 boards (Banana Pi BPI-F3, Milk-V Jupiter) have mainline kernel support, which is the main reason to prefer them. The 64-core Sophgo SG2042 in the Milk-V Pioneer uses the older T-Head C920 core with a pre-ratification 0.7.1 vector unit rather than RVV 1.0, and its support is only partly upstream, so treat it as a specialist workstation rather than a general target.

On price, the VisionFive 2 Lite starts at about twenty dollars, and the Milk-V Jupiter board is about sixty dollars, while the Pioneer is a workstation-class board priced accordingly.

If your work is firmware rather than Linux, the RISC-V microcontrollers are already mature. The Espressif ESP32-C3 and ESP32-C6 ship in very high volumes with Wi-Fi and Bluetooth and the ESP-IDF toolchain, and the WCH CH32V series provides very low-cost RV32 parts for bare-metal work. The Microchip PolarFire SoC covers FPGA-backed and mixed designs.

What is usable today

• Learning, teaching, and prototyping the full embedded Linux stack on real silicon.
• The GCC and LLVM toolchains, including auto-vectorisation with RVV 1.0, plus Zephyr, FreeRTOS, OpenOCD, and GDB.
• Mainline-supported development boards: the JH7110 family (VisionFive 2, Milk-V Mars) and the SpacemiT K1 family (Banana Pi BPI-F3, Milk-V Jupiter).
• General-purpose distributions on those boards: Debian 13, Ubuntu, Fedora, and openEuler.
• Yocto and Buildroot builds through the actively maintained meta-riscv layer.
• Native RISC-V build and test runners, research platforms, and cost-sensitive niche products where you control the entire software stack yourself.

What is not usable yet

• A direct replacement for an Arm SoC in a shipping product that depends on a vendor BSP with tuned power management, camera, GPU, and codec support and years of maintenance.
• Long-lifecycle industrial and automotive products that need mature functional-safety certification (ISO 26262, IEC 61508). Certified RISC-V IP is appearing, such as SiFive’s ASIL-B and ASIL-D automotive cores, but full system certification and field history are still building.
• Android phones or wearables at tier-1 quality, because there is no supported Generic Kernel Image.
• Top-end single-thread performance equal to current Arm and x86 parts.
• Consistent support across every CI image, cloud runner, profiler, and specialised debugging tool, where RISC-V is still often a secondary target.
• Fully upstreamed, long-term-maintained BSPs for the newest high-performance SoCs at the time they launch.

A quick way to check RISC-V embedded Linux readiness

Two commands and one question tell you whether a RISC-V project will be straightforward or difficult. First, check what the CPU and kernel report on the target:

# techveda.org — on a RISC-V target: which extensions did the CPU and kernel report?
$ grep -m1 isa /proc/cpuinfo
isa : rv64imafdc_zicsr_zifencei_zba_zbb ...

The letters after rv64 are the extensions the kernel detects. A v means the ratified vector extension is present; RVA23-class parts add many more. Next, check that your build host has a cross toolchain:

# techveda.org — on the build host
$ riscv64-linux-gnu-gcc -dumpmachine
riscv64-linux-gnu

Then ask the question that predicts most of the effort: does your exact SoC have an upstream defconfig and device tree in the mainline kernel, or does it exist only in a vendor kernel fork? If it is in mainline, RISC-V embedded Linux is ready for that project today. If it is a vendor fork, you take on the same BSP maintenance work that early Arm SoCs required, and you should plan for it.

To build the board bring-up and BSP skills this depends on, our Embedded Linux and Yocto course covers this kernel, device tree, and image work directly.

Where this leaves embedded teams

The accurate position is neither of the two confident answers. RISC-V embedded Linux is mature enough that ignoring it is a mistake: the architecture is upstream, the tools are complete, and engineers who learn it now will be prepared as the silicon improves.

It is also early enough that using it in a shipping product, outside specific niches, means accepting BSP and maintenance work that the Arm ecosystem has already completed. The teams getting the most value today use RISC-V to build skills and prototypes on mainline-supported boards, and they track BSP maturity and long-term support, rather than benchmark results, as the signal for when it is ready for their products.

Key takeaways

• RISC-V embedded Linux is ready in the ISA, toolchain, distribution, and development-board layers: Debian 13 is official, RVA23 is a stable target, and GCC, LLVM, Zephyr, and FreeRTOS are complete.
• You can buy mainline-supported boards now: JH7110 boards (VisionFive 2, Milk-V Mars) for general Linux, SpacemiT K1 boards (Banana Pi BPI-F3, Milk-V Jupiter) for vector work, and the 64-core Milk-V Pioneer for native builds.
• The momentum has clear drivers: supply sovereignty and an open ISA, plus automotive, where functional-safety-certified RISC-V IP is now appearing.
• Treat the “25 percent market share” figure with care: it counts control cores and microcontrollers, not the application processors used for embedded Linux.
• It is still immature in the layer that decides products: production BSPs, long-term maintenance, functional-safety certification, and mobile support. Assess readiness per SoC: a mainline defconfig and device tree means it is ready now; a vendor kernel fork means you should plan for BSP work.

Frequently asked questions

Can I run mainline Linux on a RISC-V board today?
Yes. Boards built on the StarFive JH7110 (VisionFive 2, Milk-V Mars) and the SpacemiT K1 (Banana Pi BPI-F3, Milk-V Jupiter) run mainline Linux, and Debian 13, Ubuntu, and Fedora provide riscv64 images for them.

Which RISC-V board should I buy first?
For learning and general Linux, a StarFive VisionFive 2 or a Milk-V Mars is the best starting point, because both use the mainline-supported JH7110 SoC and are inexpensive. For vector and AI experiments, choose a SpacemiT K1 board such as the Banana Pi BPI-F3, which implements the ratified vector extension.

Is RISC-V used in production today?
Yes, but mostly as small control cores and microcontrollers rather than as the main application processor. RISC-V cores ship in very high volumes inside other chips, for example inside NVIDIA GPUs, and automotive vendors such as SiFive now offer functional-safety-certified RISC-V IP. Shipping products that run embedded Linux on a RISC-V application processor are still uncommon.

Is the RISC-V toolchain production-ready?
For most purposes, yes. GCC and LLVM support RVA23 and the ratified vector extension, and Zephyr, FreeRTOS, OpenOCD, and GDB all work. The remaining gaps are in specialised profilers and debuggers and in CI and cloud images that still treat RISC-V as a secondary target.

Why can’t I buy a RISC-V Android phone?
In 2024 Google removed RISC-V from the Android Common Kernel and said it was not ready to provide a single supported Generic Kernel Image, so there is no tier-1 kernel path for Android on RISC-V yet. Android still accepts RISC-V patches through AOSP, but vendors would have to maintain their own kernel support.

Should I move my embedded product from Arm to RISC-V now?
For most shipping products, not yet. The deciding factor is whether your exact SoC has an upstream, maintained BSP. If it only exists as a vendor kernel fork, you take on significant maintenance work. RISC-V is a strong choice today for learning, prototyping, and niches where you control the entire software stack yourself.

Further reading

• Phoronix: Debian 13 introduces official RISC-V support, still bound by slow hardware.
• Debian Wiki: RISC-V port status and supported hardware.
• Ubuntu: RISC-V profiles and why RVA23 is significant.
• The Register: Google pulls RISC-V support from the generic Android kernel.
• RISE Project: improving RISC-V support in the Yocto Project (mainline BSP work).
• RISC-V International: production readiness and automotive at Embedded World 2026.
• SiFive Automotive: ISO 26262 (ASIL-B/ASIL-D) and ISO/SAE 21434 certified RISC-V IP.
• Milk-V Mars: official hardware specification (JH7110).
• RISC-V development boards: 2026 buyer’s guide.
• DeepComputing: DC-ROMA RISC-V AI PC guide for installing DeepSeek-7B.