OrangePi is fairly famous by now as an alternative manufacturer for Raspberry Pi-like mini-computer boards, usually based on ARM processors (but not only). Very recently they announced the upcoming availability of a new board, the OrangePi RV2, based on a new RISC-V SOC (the Ky X1, with 8 cores running at 1.6 Ghz).

I had already reviewed more than a year ago the Starfive Vision 2 board using a different SOC - and while it was showing some promise, the software support was lacking (and things have unfortunately not evolved a lot since then).

Can we expect better from the OrangePi RV2 ?

Specs

The board is fairly small, much more than the Starfive Vision 2, and very close to the size of the Raspberry Pi.

The model I received for review was a 4GB one. What I like about the specs is the numerous options for storage (one eMMC and two NVME M2 slots!), the 2 Gigabit Ethernet ports (so that you can turn it into a router), the 4 USB ports (suffient to connect keyboard, mouse, and something else), on top of what you usually get from this kind of boards.

Here’s the back view:

The Ky X1 processor appears to be the same as the Key Stone K1 chip from the chinese company SpacemiT.

If that’s the case, then the specs should be as follows:

• SpacemiT Key Stone K1 (X60) @1.6GHz
• SoC: Octa-Core RISC-V (RV64GC) 64-bit
• NPU: 2.0 TOPS (AI from RlSC-V Core)
• GPU: Imagination BXE-2-32 @819MHz
• 32KB SLC (OpenGL ES3.2)
• VPU: H.264/H.265 decoder up to 4Kp60, H.265 encoder up to 4Kp30

This GPU is a mobile CPU, so you can’t expect OpenGL support. You get OpenGLES 3.x support and Vulkan support (1.3), at least on paper.

Key features of X60 core

• RVA22 64-bit RISC-V processor
• 2 TOPS @ INT8 AI computing power compliant with RISC-V IME extensions
• RISC-V Vector 1.0 standard, providing 256-bit vector computing bandwidth
• INT8/16/32/64 integer data types
• BF16/FP16/FP32/FP64 floating point data types
• Frequency: 2.0 GHz at 22nm
• SPECint2006 / GHz puts it at 33% faster than a A55 core (SpacemiT LLVM Compiler, so expect cherry-picking!)
• 3.66 DMIPS / MHz (SpacemiT LLVM Compiler)
• 5.14 CoreMarks / MHz (SpacemiT LLVM Compiler)
• Multi-core, multi-cluster processor
• 8-stage dual-issue in-order execution
• Dual cache structure of Cache + TCM
• Supports dual-issue of scalar and vector read/write instructions
• Supports intra-cluster and inter-cluster coherence

While the cores can go to 2.0Ghz, the OrangePi RV2 SOC is clocked at 1.6 Ghz (probably for stability reasons and to allow for passive cooling).

For the price, the amount of features that you get is impressive. The NVME drives are PCI2 lanes, so you can get in theory up to 1GB/s in transfer speed. In practice I have seen read and write speeds in the 700 to 800 MB/s range, which is what you would expect in reality. That’s much, much faster than working with a SD card.

Of course, the usefulness of such a board depends entirely on the quality of the software support. This is where we are going next.

Proper Software Support

A Full Ubuntu Experience

I’ll cut the chase and give you the answer. The software support is GREAT. You get an Ubuntu image that is crazy simple to get running. The one thing that is a potential issue is that you have to trust a third party repo from Huawei:

To install Ubuntu, you use dd or Balena Etcher to image a micro-SD card first, and then you get some helper scripts (using ncurses) that make it super easy to image either a eMMC chip, or a NVME drive that’s attached to the board (I don’t recommend using a micro-SD card as the main media).

Since you can have an eMMC, and 2 NVME drives attached at the same time on the board, the amount of storage you can add on this single board is great.

In my case I used an eMMC card (64Gb), and the process to transfer the Ubuntu image to the eMMC drive took only about 5 minutes. I then rebooted after removing the micro-SD card, and lo and behold, it booted directly on the eMMC drive. Smooth!

This time around, unlike the Starfive Vision 2, you have an actual, full-featured Ubuntu distribution which a very large selection of packages already compiled for RISC-V. You don’t exactly get EVERYTHING, though. For example, Firefox is missing from the repositories, and Thunderbird as well - but you get Chromium (without sandbox, so no extensions, sadly), which works very well - and is fast enough to use for normal browsing - and yes, Youtube works, and works well enough. Don’t expect 4k decoding, but watching videos at 1080p is not an issue. You get Wifi, Bluetooth connectivity, and using BT speakers is a good way to get sound from this board.

One major change from my experience with the StarFive Vision 2, is that you can do proper updates of this distro with apt update and apt upgrade, as you would expect. You also get a recent kernel (6.63), and the session runs on Wayland. The only drawback for the desktop experience is the limit in terms of output resolution - it only supports resolutions up to Full HD, so my nice Ultra Wide Screen gets a stretched picture. Currently there are no plans to support screens higher than Full HD (after I contacted OrangePi to confirm).

GPU Still Missing in Action?

Let me start by saying I am not aware enough about the whole Linux graphics driver stack to make some good observations about what’s actually going on. But it looks that the board is not using any kind of hardware acceleration. Mesa reports that it is using softpipe, i.e. software-based OpenGL/ES support.

Running glxgears shows a very, very poor framerate, that seems to indicate that the whole thing is running in software, once again.

I have compiled gl4es in the hope of being able to run more OpenGL applications, and it fails to display anything in my various experiments. After a few discussions with Ptitseb (the developer of gl4es and Box64), it seems like if there is a GPU driver, it’s possible that it does not have any OpenGL or GLES support, and potentially only vulkan. I can’t seem to be able to confirm that, since vulkaninfo leads to a segmentation fault. Yeah, the GPU situation is cloudy at best, and I have not been able to confirm that the acceleration is working in any way to make OpenGL or OpenGLES applications run well.

Applications

I installed and tried bunch of things:

Chromium is installed by default and works well enough. As mentioned before it’s not sandboxed, so you cannot install extensions, and it’s a relatively older version (122)

Since Chromium does not support extensions, this causes one issue on the GNOME desktop: you typically install GNOME extensions via the browser and an extensions that links gnome-shell and the extensions. There is actually a workaround that I had no idea existed - a program called gnome-extensions-manager (if my memory serves right) which takes care of managing extensions for GNOME outside of the browser. Very cool.

MPV: probably the best option for video playback. VLC launches, but does not display the video feed properly for some reason. Avoid Gnome-MPV as well, it seems to completely lack GPU support as the CPU goes into full crazy mode for the exact same video that worked fine in MPV.

ClawsMail: a very good email client that most people don’t know about, but that works very well on hardware with limited resources.

• Xournal: works great to take notes on PDF.
• Foliate: a very good ebook reader, that works flawlessly on this board as well.
• Lollipop: a good audio player that works in GNOME.
• Gnome-Web (also known as Epiphany): it works OK, but is much slower than the already provided Chromium.
• KDenLive: it works, it launches, but it’s way too slow to be usable, unfortunately. This is really pushing this board too far. This should be obvious, but don’t use this kind of board if you plan to do video editing. I tried Shotcut as well, and while it launched faster, it was also unusable.
• OpenShot: the only video editing application that actually worked! It’s going to be slow, but if you have to make very simple edits, you can live with it. It constantly pushes the CPU to its limits (100% on all cores) which tells me that there is probably very little GPU support going on.

• VSCodium: If you really need to code, this is a good option, and it’s fast enough to be usable. I tested a couple of extensions as well and everything worked (at least for Python). Note that it’s not available from the repositories, but you can get it from a third party source (where they have builds for all kinds of architectures).

• Yt-dlp: the infamous tool to download youtube videos and audio works just fine here - as expected, it’s a Python program after all. Do not use the version from the Ubuntu repos, it’s obsolete, so your best option is to use pipx instead to install the latest one.
• Libreoffice: Libreoffice works fine (but the interface is a little strange). I tried Writer and Calc and they are usable while a little on the slow side.

• Digikam works surprising well, while it takes a while to load. I’m not sure if the board would handle very large RAW pictures, but it looks like it might perform fairly well.

• Gimp: working flawlessly. I used it to edit some of the pictures in this review. The only problem is that it does not support AVIF for some reason, so I had to export the pictures to AVIF format separately.

• Weechat, the infamous IRC client, works very well, as expected - after all, it’s a terminal based program.

I also tried WINE and installed mIRC (the well known IRC client that is still around!) and while it was slow, it worked. The only issue is that I could not connect to servers in the end, because the drop-down list was not showing properly inside the mIRC client in the end.

Anyway, close enough and WINE works, albeit slowly on this kind of hardware.

You can also install a few other applications that are not part of the main repos using the orangepi-config terminal tool. Not everything works as expected, but here’s what it looks like.

Kind of funny that they make it easy to install Radarr and Sonarr which are basically used to pirate media content!

On desktop, one of the modern ways to install distro-independant applications is to use Flatpak. Sadly, while on paper Flatpak could support more than just X86_64 architecture, right now there is no support for riscv_64. So, if you were expecting to use this board by relying on Flatpak as a main source, you are out of luck. And this is a shame, because it’s really a self inflicted problem. There is no technical reason for Flatpak not to support just every architecture out there, but Flathub and the like have decided that there’s just x86_64 that matters.

So how’s the overall desktop experience? Honestly, surprisingly NOT BAD! If I did not have my X86 laptops at hand, I could see myself using this and not bitching every 5 seconds about how slow things are. I mean, things are relatively slow, but it’s crossed the usable threshold, the one where you don’t need to go and make a coffee to wait for an application to launch.

Temperature Control

You know that quite a few SBC these days require extensive passive cooling solutions (heat sinks) or active cooling ones (fans!) - well this OrangePi RV2 does not. Not even a heat sink is needed. Even at full load, compiling for more than 30 minutes, the temperature stays very stable somewhere between 75 and 80C (it’s spring in Japan right now, and the ambient temperature is between 15C and 20C when I run these tests).

And as far as I could confirm, there does not seem to be any throttling occurring at such temperatures.

Power Draw

I don’t have proper equipment to measure this, so I have to rely on other folks online who have shared such observations. I have seen a few different numbers, and it looks that at idle, you should expect between 2W and 3W power draw from this board. This is in line with the idle power consumption of the Raspberry Pi 4B, if you needed some kind of baseline. I expect the board will require more power as you add more peripherals. If you have 2 NVME drives + one eMMC, and also use the GPIO pins for additional physical applications, I would expect the power draw to increase quite a bit. But idle power is what matters, on average, because most of the time your system will be idling as that will be a good estimator for your monthly electricity bill.

Gaming

As mentioned before, our main problem here is that we don’t have GPU acceleration. It will severely limit the number of games you can expect to run, at this stage in April 2025. But you can still have some fun with more ancient games.

I tried for example:

Chocolate Doom: works fine, at a good framerate. But that’s expected. The same goes for Freedoom.

Scummvm: it works as expected. That’s not surprising since it’s very lightweight - I could play Day of the Tentacle (the DOS CD version) and it worked and looked great.

Looks like Freeciv worked without a hitch as well (once you install both the freeciv client and the freeciv-server package.):

Unfortunately, Openttd does not launch, and complains that SDL2 cannot create a surface (Wayland issue related, maybe?). So that one is out.

There’s also the almost unlimited potential of emulators (at least older systems that don’t require proper GPU acceleration) while I did not test them this time around.

But let’s be honest here. If you were to buy a board to power a home arcade system, I would recommend you get a ARM64 board instead. The Raspberry Pi has great support in that regard, because of its mainstream appeal. Right now, trying to game on any of the current RISC-V boards is asking for a lot of pain.

There’s however something interesting to explore. Since the M2 ports are PCI lanes, you could try to attach a real GPU (probably an AMD one) with a M2 to PCI adapter (something like this, not affiliated). My limited knowledge in this area leads to be believe you may have to recompile some kernel modules and Mesa for it to work with a proper GPU, but then again I may be completely wrong. This approach works on Raspberry Pi thanks to the excellent work done by Jeff Geerling (it was not done overnight). There’s no reason why it should not be reapplicable to other non-ARM64 boards, for someone with a lot of time on their hands.

AI - LLM Performance

Since not everything is available in the repos, one of the options is to actually compile stuff by yourself. I compiled Ollama (after getting a more recent Go build for RISC-V), and it worked fine to serve very small (large) language models. This is running on CPU only - we don’t have vulkan or any other kind of acceleration. Since my board only has 4 GB of RAM, the type of models I could use was very limited, and in any case, the token generation was very slow (a couple of tokens per second, on qwen 0.5b). So technically, you can make it work.

OrangePi actually has a section in their documentation related to running LLMs (thanks Nils for finding this!) and they recommend to use a PC to convert the models to a proper format in order to increase the inference speed. From the numbers they provide, it does not look like you will be using this as a LLM server any time soon, but it looks much faster in the case of qwen2-0.5b compared to my own experience with Ollama as is. Probably something like 3 times faster.

Even with some optimization going on in the above numbers, this won’t be a board you can use to run large language models (LLMs), despite the enthusiastic advertising material. I do have to say that the performance on Phi-3 mini 3.8b and qwen2 1.5b is borderline acceptable - these models can’t do a lot, but they are decent in their category and could be used for things like RAG applications (for a single user).

For a board that runs just on a few watts of power, that’s not bad at all. If they can manage to 3x the token inference down the road, this may become a more interesting proposition. Note that the numbers above do not take in account prompt processing. Prompt processing is the Achilles’ heel of CPU-based solutions (even on the super powerful Mac studio) so the more complex and long your prompt, the longer you will have to wait for your first token. In the case of the OrangePi RV2, the other limiting factor is going to be the RAM. The model already takes a lot of the allocated RAM space, and long prompt processing takes a large amount of RAM as well. You’d want to have 16G or even more RAM ideally.

If you are serious about LLMs, right now there’s not a lot of options out there that will beat the performance per dollar of a powerful Nvidia RTX GPU using CUDA, equipped with a large amount of VRAM. I wish it was not the case, but this is where we are on the market in early 2025.

Performance

The go-to suite to evaluate performance is Geekbench, because it can provide some comparison between the speed across different architectures. So, are we getting any closer to the performance of a Raspberry Pi with this board?

Single Core Performance

The single core performance clearly shows an advantage for the Raspberry Pi 4.

Seems like we are in a bad shape?

Multi-core performance

Things look much better now once we factor more cores in the equation.

Performance overview

As you can see, for parallel workloads, this board is pretty much as capable as a Raspberry Pi 4 (at the same frequency).

In short, single-core performance is clearly lower what you get from a Raspberry Pi 4, but the multi-core performance seems to be pretty much on par (8 cores help). This is kind of amazing to see so much value at this price point, and on a new architecture like RISC-V. For reference, the Starfive Vision 2 was only half the speed of the Raspberry Pi 4 in multi-cores workloads, so this is a massive improvement.

Server Use

You can use this board as a server, of course. You have a distro image just for the server use, too. You should be able to install quite a bunch of software, but the question is, can you rely on Docker? The answer is a little mixed. Yes, Docker works by itself. The problem is that on Docker Hub, there’s not that much software that includes additional binaries that support riscv64 architecture. It’s not nothing, however. You have PostgreSQL, Nextcloud, Wordpress, and very useful software like PiHole for example.

So the fairly important ones have some kind of support, but stride a little away from that and you will find that many images have no support. For example, if you wanted to try Ollama on this board (not that it would perform very well except for small models), then you are out of luck with a ready-to-use Docker image.

However, nothing prevents you from building your own Docker images (with a Dockerfile or a Docker compose file), so while it’s going to be a bit more work if you need to compile programs to include them in an image, there’s virtually nothing preventing from your doing just that. Sometimes what looks like an inconvenience is a great way to learn new things. What matters the most is the availability of base distro images, and in that sense you don’t really have a problem, since you get a great choice to start with:

• Alpine: https://hub.docker.com/_/alpine
• Ubuntu: https://hub.docker.com/_/ubuntu
• Debian: https://hub.docker.com/_/debian

In terms of web servers (which are kind of essential to orchestrate how your applications are going to be accessible) you also get the usual suspects:

• nginx: https://hub.docker.com/_/nginx
• traefik: https://hub.docker.com/_/traefik
• caddy: https://hub.docker.com/_/caddy

Still, it’s close to the bare minimum. For server use, either you rely on managing everything without Docker, using your usual package manager and something like Ansible, or you go the Docker way knowing that it will be a lot of additional work on your end as most software out there has no support for RISC-V architecture on Docker Hub. Still, I would expect things to improve on Docker Hub within a few years down the road as RISC-V becomes more popular, and more developers have access to such boards.

Alternatives

As usual, you should expect to see a SOC used in several hardware providers, and this SpacemiT K1 is no exception, as it’s already found in the Banana Pi BPI-F3 board. The specifications are fairly similar, but the board itself seems a bit bigger, and it has an option for 16GB RAM, which OrangePi does not provide right now. It also seems to be slightly more expensive, but comes with a few advantages: images for Armbian, Arch Linux and Fedora. I have no idea how good the support is for BananaPi, so you’ll probably have to look for reviews of that board if you are interested.

It also looks like in China there are some cheap laptops that use the same SOC - which is a good package to do development, I guess.

Verdict

This is an extremely fun SBC.

The first RISC-V board where I feel it fully enables you to do something useful with it in a very short time. It’s never going to be as easy as a Raspberry Pi (convenience in terms of support is what drives their business), but performance wise and software support wise, we are reaching very acceptable levels. Reducing the friction to such levels is going to drive more people to RISC-V, and I can see myself using this board as a mini-server instead of a ARM64-based board.

We still need more powerful integrated GPUs and proper software integration to do more and more heavy lifting - this part is still lacking, and I believe some responsibilities lies with Imagination Technologies. But we have come a long way with RISC-V, looking back at the past few years. This is very encouraging, and we are now in a phase where using them for serious little servers makes complete sense. The desktop itself is usable enough, too, for many kinds of applications. And from the Ubuntu base andd the fact that you have several ports for storage, it’s very easy to transform this board into a full fledged NAS. Right now, there is no OpenWRT distro for the OrangePi RV2, but that should be an ideal target to turn this hardware into a router as it features a double Ethernet port (just like the Banana Pi F3).

In any case, at this price point, this board is a no-brainer if you want to get into RISC-V.