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:

The Orange Pi RV2
The Orange Pi RV2

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 .

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.

Hardware

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.
All the ports, neatly laid out
All the ports, neatly laid out

Thermals

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 58oC to 49oC, 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 64oC 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.

Power Consumption

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).

Software

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.

Ubuntu Desktop

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 GNOME desktop experience on the [RV2] is quite smooth

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:

The main `orangepi-config` options

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.

OpenWRT

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”:

Despite the looks, it works just fine
Despite the looks, it works just fine

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).

Logging in from a Linux client
Logging in from a Linux client

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.

Performance

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:

Phoronix's geometric mean of all their benchmarks
Phoronix's geometric mean of all their benchmarks

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

Networking

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 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.

Conclusion

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 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…

Notes For Recent Weeks

This was a bit of an eventful week–at work and otherwise. I seem to be energized by constant context switching, so a peak of project work actually resulted in me needing to “relax” more thoroughly and do a lot more hobby stuff than usual at the expense of sleep (I’ve slept an average of 6h/night over the past month…)

Solar

I have a couple of portable 30W solar panels that were put to good use during , so of course I went and ordered another (60W) one, taking advantage of the fact that modern panels have USB-C PD support, which is handy to charge some devices a bit more efficiently (like this 145W/25000mAh one, which can charge a MacBook Pro from zero to full and still have ~30% capacity to spare).

I’ve been playing around with various combinations and I can charge a bunch of stuff throughout the day–mostly for science and understanding of limitations, but also because it’s a fun thing to do even though it doesn’t really add up to meaningful savings.

But since I found myself using that powerbank for charging stuff away from an outlet more than a few times now, I am strongly considering getting another one and making a little game out of seeing how far I can go with regularly charging things from solar only over Summer.

3D Printing

However, I managed to break off the rubber port cover of the new solar panel while testing it, so I went and designed myself a new one–and actually improved the fit a bit, since the DC port wasn’t plugged in the original:

I wish I could do this more often, really
I wish I could do this more often, really

The end result is pretty decent, if you’ll excuse the usual TPU stringing (which I later removed with a hot gun):

Black TPU photography is a dark art
Black TPU photography is a dark art

Coding

I’ve been using GitHub Copilot extensively over the past month and found it has improved massively, so after some experimentation I’ve settled on a workflow that is quite productive (and will write a separate note about).

I had a hand at doing several things, some of which were spurred by my desire to have better free CAD software with parametric design (and no, please don’t talk to me about , I abhor its UX, and yes, I keep trying it every release):

And I’ve been doing that on a very nice little machine I will be posting about soon.

My Quest For Home Automation, Part 6

This weekend, I finally migrated my home automation setup off the 4 it’s been running on for the last four years and into an LXC container managed by on my .

I’ve been meaning to do this for a while, and things finally fell into place yesterday when I had a bit of time to spare.

Previous Installments

In case you haven’t been following along for the past seven years, here’s a brief summary of the major milestones so far:

Why

It’s mostly about consolidation and cleanup, since I now have one less power plug and Ethernet port in use on my server closet.

Being able to backup everything consistently and migrate the setup to any machine I want (as long as it has an USB port for my coordinator) is just icing on the cake.

Although hasn’t really improved substantially over the past few years (in fact, the Home app has only gotten worse, and most of my unscheduled interactions are via Siri), homebridge and zigbee2mqtt satisfy my relatively simple needs for home automation rather well.

I’ve written about that at length over the years, so the list above should give you a good idea of the finer points of my setup.

But, in short, everything operates 99% on the LAN (with no devices calling home to anyone or relying on outside services to work) while allowing me to do the occasional remote action securely without any new software on our phones, and I quite like it that way.

I also wanted to do a general cleanup of the whole thing from scratch, including renaming all my accessories using a slightly different convention (including renaming them directly in zigbee2mqtt to make sure names are consistent throughout the stack) and removing redundant accessories, since (for instance) I no longer have the need to have as many temperature sensors around the house now that all my have been -enabled by the addition of modules.

Finally, I was having some trouble keeping things up to date, mostly due to JavaScript packaging vagaries. Every update I wanted to make eventually led to me having to either upgrade NodeJS or fiddle with the latest fashion in package management, so it was time to go back to a Docker-based setup for consistency with the rest of what I’m running–although I am not doing automated updates for this stack.

Why both homebridge and zigbee2mqtt don’t have sensible alternatives written in something like Go I have no idea. Even Java would have been better.

How

The actual process was pretty straightforward:

  • Backed up all my configuration and data.
  • Created an LXC container on with the original hostname and made sure my router updated its local DNS (after some finagling with DHCP), so that the Tasmota devices could connect immediately.
  • Configured to pass through the USB device for my controller.
  • Wrote up a docker-compose.yaml file to set up homebridge, zigbee2mqtt, mosquitto and node-red.
  • Restored the config for each in turn, doing minor tweaks as needed.
  • Renamed all my devices (this makes it easier to manage things on the Home app when HomeKit throws a fit).
  • Set up piku to manage some MQTT microservices like the plex-listener that powers my and my homelab homepage (which is now a variant of this little dashboard/homepage I hacked a while back).
  • Set up backups (both of the complete LXC filesystem and git versioning of the configurations)
  • Started cleaning up old flows, removing redundant accessories, etc.

The current filesystem layout is pretty straightforward:

.
|-- README.md
|-- docker-compose.yaml
|-- homebridge
|   |-- accessories
|   |-- auth.json
|   |-- backups (excluded from git)
|   |-- config.json
|   |-- lgtvKeyFile
|   |-- node_modules (excluded from git)
|   |-- package.json
|   |-- persist (contains bridge data and identifiers)
|   |-- startup.sh
|   `-- webostv
|-- mosquitto
|   |-- data
|   `-- log
|-- nodered
|   |-- flows.json
|   |-- flows_cred.json
|   |-- flows_home.json
|   |-- homekit-persist (contains data for Node-RED Homekit shims)
|   |-- itunes.db
|   |-- lib (excluded from git)
|   |-- metrics.db (14GB, _definitely_ excluded from git...)
|   |-- metrics.db-shm
|   |-- metrics.db-wal
|   |-- metrics.sql
|   |-- node_modules (excluded from git)
|   |-- nrchkb
|   |-- package-lock.json
|   |-- package.json
|   |-- projects 
|   |-- security.db
|   `-- settings.js
`-- zigbee2mqtt
    |-- configuration.yaml
    |-- coordinator_backup.json
    |-- database.db
    `-- state.json

Next Steps

Right now I’m still removing redundant devices, as well as planning replacing some Tasmota plugs with equivalents to improve the mesh coverage.

Another thing I will be doing is replacing some flows that do metric logging and MQTT transformations with Python microservices.

I no longer have a need to tweak them, so their behavior can be frozen and any changes better versioned in git ( does support git, but it’s just messy to do some things that way).

The Kingroon KP3S Pro (V1), Two Years Later

It’s been since I got myself one of the first iterations of the , so I thought I’d post a sort of cursory long-term review of what it’s been like to use it.

Read More...

The HomePod Mini

Since Alexa has changed the way it handles voice recordings and I don’t feel comfortable with their privacy disclaimers, I decided to retire the Echo Dot I have been using for years in my office and replace it with a HomePod Mini.

Read More...

A bit of a personal update

I have been mostly in “inbox zero” mode for the past few weeks, which generally meant checking stuff off my to-do list, trying to ignore the news, and using some fairly colorful language when I didn’t.

Read More...

Easter Break

Unusual, I know
I wasn’t aware rabbits lay eggs this high.

The Polyphemus Filament Dryer

I haven’t written about 3D printing in a while, but I have both kept at it and actually doing a bit of market research–I’ve been considering either building an MMU or getting a multi-material printer, but I haven’t made up my mind yet, and the tariff war isn’t helping.

Read More...

Cirque du Soleil

Bop
A bit of… light entertainment

AI Does Not Spark Joy

As an inveterate tinkerer, I have spent a lot of time messing with in my side projects, and… it hasn’t sparked a lot of joy.

Read More...

A Classical Evening

1-2-3 1-2-3 1-2-3
Strauss by the Vienna Johann Strauss Orchestra

The Chuwi Larkbox S

It’s been a little while since I last looked at regular mini-PCs, and considering that the market is flooded with cheap Intel N100 and N150 variants, you would think there isn’t a lot of diversity in the EUR 200 range.

Read More...

Notes on MCP

I’ve been playing with Anthropic’s MCP for a little while now, and I have a few gripes. I understand it is undergoing a kind of Cambrian explosion right now, but I am not very impressed with it. Maybe it’s echoes of TRON, but I can’t bring myself to like it.

Read More...

Archives3D Site Map