The Orange Pi RV2 RISC-V SBC

Although I’ve spent many years looking at SBCs, so far nearly all of them have been ARM-based, and this is the first time I’ve had a proper look at a RISC-V system.

And this one is both quite usable and remarkably compact:

Disclaimer: OrangePi sent me an RV2 evaluation board and a 64GB eMMC free of charge (for which I thank them), and this article follows my review policy.

RISC-V is heralded by many as “the next big thing” since it is an open and royalty-free ISA, but it has been a sort of red-haired stepchild for a long time, in the sense that it has always been much slower and gotten less overall industry support than ARM.

However, things have been changing over recent years. The original emphasis on low-power, low-end devices has been shifting towards beefier SoCs as companies like Ventana Micro Systems and SiFive started working on high-performance RISC-V processors, and countries like China, India, and even the EU are investing heavily in RISC-V to reduce reliance on proprietary architectures.

And given the current geopolitical situation, well… RISC-V might come to enjoy even more popularity. So even though OrangePi reached out way before the US tariff wars began, I can’t help but feel it was timely.

The review unit I got came with a very nice and compact USB-C GaN charger (rated at 5V/5A) and has the following specs:

• 8-core Ky X1 64-bit RISC-V CPU, with 2 TOPS NPU
• 4 GB of LPDDR4 RAM
• MicroSD (TF) Card Slot
• A bottom eMMC socket (I also received a 64GB eMMC module for that, which was very useful)
• 2 PCIe 2.0 M.2 M-keyed slots, one on top that you can use for (short) NVMe SSDs (but that you can’t boot from) and a full-sized one on the bottom (which you can indeed boot from)
• HDMI 1.4 (1080p@60), and a MIPI DSI port for display
• An onboard Wi-Fi 5 + BT 5.0/BLE AP6256 module that connects to the system via SDIO3.0 (this will be relevant later)
• 3.5mm audio input/output jack
• 3 USB 3.0 host ports + 1 USB 2.0 that can do either device or host mode and an extra-4-pin USB header on the PCB, next to a 3-pin header for a UART (which is a nice touch compared to some of the proprietary setups I’ve had to deal with recently)
• And, of course, a 26-pin GPIO port and a usual amount of MIPI/CSI connectors.

The RV2 is passively cooled, and one of the first things I noticed was that it gets noticeably warm to the touch when under load.

Placing a small copper heatsink on the Ky X1 dropped the idle temperature from 58^oC to 49^oC, so I would definitely advise you to do the same if you get one.

Under 100% load across all 8 cores and with the heatsink, I got up to 64^oC over around 30m of heat soaking without any throttling, which is good for a passively cooled system–and I didn’t notice any throttling during my tests with this setup.

The RV2 spent most of its time idling at 3W, which is… OK but feels like it could be lower given that it is on par with the lowest values I got for RK3588 boards (which are much more powerful).

On the plus side, I couldn’t get it to go past 5.2W under maximum CPU load (generated by a little Go program that hogged all cores), so I’d say it is reasonably low-power (although, as we’ll see later, you are not getting a lot of performance per watt).

I would ordinarily use Armbian if this were an ARM board, but that was obviously not an option here.

What made the board interesting to me was the recent availability of official Ubuntu images, which is actually even better.

Installing it was trivial–I just flashed the image to a Micro-SD card and it booted, and I then used orangepi-config to copy it to eMMC. Orange Pi’s documentation is quite good, and the process was straightforward.

I also flashed it (later) to an NVMe drive connected to my laptop via USB and it just worked, which is a much nicer experience than dealing with Rockchip’s Windows flashing utilities.

The Ubuntu desktop image “just worked”, too, including, impressively, smooth animations in GNOME, working video playback (both via VLC and the browser), and a Chromium build that reported fairly good hardware acceleration–compositing, WebGL, and video decoding are all hardware-backed, which is more than I expected from RISC-V at this point, although like on RK3588 systems, there’s no real way to use the GPU via RDP or other more exotic means I’m used to on other devices.

There is a lot of additional software available (including a set of third-party software options available via orangepi-config), and I found it interesting to see that there are RISC-V builds of Plex as part of the software selection:

So I’d say that if you want a desktop experience, the basics are commendably workable on RISC-V already.

But since my board only came with 4GB of RAM, the experience wasn’t the best (it took around a full minute to boot from the eMMC and felt a little laggy). The lack of RAM felt a little unfair to the rest of the hardware, so I decided to install the server version for most of my testing.

Considering it runs kernel 6.6.63 (on Ubuntu) and has ample CPU performance when compared to most home gateways, it seems like a great board for building a gigabit router with stateful firewall capabilities–so I installed OpenWRT on it, this time using what I lovingly refer to as my “cursed eMMC adapter”:

Like the Ubuntu image, the OpenWRT one is also very complete - even Docker is installed, as well as a lot of useful networking utilities, including mwan3 for multi-WAN setups (which I actually have been looking at lately).

However, Wi-Fi wasn’t working for me in the OpenWRT image:

root@OpenWrt:~# dmesg | grep -i wlan
[    3.548243] ky-wlan rf-pwrseq:wlan-pwrseq: error -ENXIO: IRQ index 0 not found
[    3.552874] ky-wlan rf-pwrseq:wlan-pwrseq: get platform irq failed, try to get gpio irq

I did a little investigation and it seems that the current OpenWRT image is missing the dhd kernel module that is present in Ubuntu, and possibly other parts of the SDIO stack:

orangepi@ubuntu:~# dmesg | grep dhd
[    7.553302] [dhd] _dhd_module_init: in Dongle Host Driver, version 101.10.591.84.37 (20241009-2)(2bc03d3)
               drivers/net/wireless/bcmdhd compiled on Feb 17 2025 at 20:37:11

[    7.553347] [dhd] dhd_wlan_init_gpio: WL_HOST_WAKE=-1, oob_irq=72, oob_irq_flags=0x1
[    7.553360] [dhd] dhd_wlan_init_gpio: WL_REG_ON=-1
[    7.553366] [dhd] dhd_wifi_platform_load: Enter
[    7.553373] [dhd] Power-up adapter 'DHD generic adapter'
[    7.553480] [dhd] wifi_platform_set_power = 1, delay: 200 msec
[    7.553490] [dhd] ======== PULL WL_REG_ON(-1) HIGH! ========

orangepi@ubuntu:~# dmesg | grep rf-pwrseq
[    7.553501] ky-rf-pwrseq rf-pwrseq: turn power on
[    7.554594] ky-rf-pwrseq rf-pwrseq: check voltage: 1800000

I suppose that other bits of the stack might be missing as well, but iw and the usual tooling is present, so this might just be an oversight since OpenWRT is supposed to do wireless…

I’ve reached out to OrangePi regarding this since the RV2 is pretty much the perfect size for a travel router, and even if the SDIO Wi-Fi isn’t amazingly performant it does work well enough for that–I’ll update this post when I hear back from them.

This is, of course, the elephant in the room. RISC-V has long had a stigma of lower performance and higher power consumption when compared to ARM CPUs, but we’re now at a point where people are developing x86 emulators, and considering the Ky X1 has 8 cores I had high expectations.

As it happens, I had a bit of a challenge getting sbc-bench to work, since calibration is finicky and even the server image produced “system too busy” warnings. The current git version failed to build cpuminer and the bundled version that OrangePi provides is too old, so I decided not to use the results.

Regarding I/O, and considering the machine only has PCIe 2.0, using the eMMC or NVMe was, as expected, slower than on previous boards I tested–but I actually don’t think that is a problem given that a few years ago, you couldn’t even think of having a system like this.

Regarding AI, ollama isn’t supported on RISC-V and my board had only 4GB of RAM, so jumping through the hoops of installing ky-ort only to be unable to run useful models wasn’t an option.

So to get a better feel for the system I tried running some of my own apps and services (network and IoT services written in Python and Go), and although speed was more than adequate for development and testing, I got the best overall performance in things that exploited multi-core parallelism, in which the Ky X1 could leverage its 8 cores to good effect.

But simple single-core tests like Dave Cheney’s classic Fibonacci example didn’t fare very well in comparison with ARM boards.

However, since my own numbers are meaningless for actual data I will direct you to Phoronix’s excellent benchmark post, which pegs the RV2 at about half the performance of a Raspberry Pi 4–which is about what it felt like when I ran my things on it:

But, as you can see from Michael’s results, the RV2 seems to be almost twice as fast as older RISC-V platforms.

Network performance was one aspect I could test thoroughly. The RV2 can do wire-speed routing at around 941Mbps across both built-in wired interfaces, works well with the USB 3.2 WP-UT5 5GbE adapter I recently tested, and was almost able to saturate the Wi-Fi connection at 5GHz, although it is bottlenecked by the SDIO interface and figures will always vary based on your access point.

I want to like the RV2–it is, after all, a good RISC-V board for me to experiment with, and (considering what I have learned about previous generations), I think it is also a good starting point for getting into what is the only interesting alternative ISA right now.

While I can’t wholeheartedly justify the Orange Pi RV2 purely on a performance-per-dollar basis when compared to the vast array of more performant ARM-based SBC currently available or even against the increasingly affordable low-end N-series Intel machines that are driving down prices in the mini-PC market, it carves out a different kind of value.

As a way to dip a toe into the waters of RISC-V, it’s actually a remarkably competent and accessible board. It’s easy to forget what the original Raspberry Pi was when it first launched; yet, look how far it’s come.

The RV2 feels like it’s at a similar inflection point for RISC-V, and as a “first” RISC-V machine, I can’t really fault it.

Tack on an NVMe, and the RV2 can act as a build/CI server for other RISC-V targets (Go builds in particular work perfectly fine and, as usual, are much less hassle than anything else), and I’m very curious to see if something like Haiku or Plan9 can be made to run on it.

But what I most liked was the smoothness of installing software on a completely “new” architecture for me. Given that RISC-V is (at least on paper) free of the encumbrances of ARM and proprietary hardware and that flashing new images is trivial and requires no special software, this is likely to be my go-to tinkering board for testing those claims…