OrangePi 6 Plus Review: The New Frontier for ARM64 SBC Performance
So after our previous reviews (that started mainly around RISC-V since we are really interested in this new architecture) of SBC, we continue to review what’s available these days in the world of small, versatile computers. Today this is going to be about the OrangePi 6 Plus, following our previous review of the OrangePi 5 ultra board.
This is NOT a super small, credit card format SBC. We are talking about something that’s definitely larger, and that comes directly with an integrated heatsink.

At the bottom there’s a wealth of ports, and it’s where you will install the necessary wireless module if you want Wifi and Bluetooth.

Now let’s dive into what you can do with this.
Ports
Here is what you can get from the top of the device. Note that most of it will be hidden from view as the board comes pre-installed with the heatsink that covers the SOC and the memory chips.

And the bottom view.

You can tell just from the format that you should have higher expectations from the hardware.
Specs of the OrangePi 6 Plus
In a table format:
| Component | Specification |
|---|---|
| SoC | CIX CD8180 / CD8160 (12-core 64-bit) |
| CPU Architecture | 4× Cortex-A720 (High-perf) + 4× Cortex-A720 (Main) + 4× Cortex-A520 (Efficiency) |
| GPU | Arm Immortalis-G720 MC10 (Ray Tracing & 8K Decoding support) |
| NPU (AI) | Up to 45 TOPS (System-wide); ~30 TOPS Dedicated NPU |
| RAM | 16GB / 32GB / 64GB LPDDR5 (128-bit) |
| Storage | 2× M.2 2280 slots (PCIe 4.0 x4 NVMe), 1× MicroSD (TF) slot |
| Networking | Dual 5GbE (5000Mbps) Ethernet ports |
| Wireless | M.2 Key-E (2230) slot for Wi-Fi 6E/7 & Bluetooth 5.4 |
| Video Output | 1× HDMI 2.1 (8K@60Hz), 1× DP 1.4, 2× USB-C (DP Alt Mode), 1× eDP |
| USB Ports | 2× USB 3.0 Type-A, 2× USB 2.0 Type-A, 2× Full-function USB Type-C |
| Camera (MIPI) | 2× 4-lane MIPI CSI interfaces |
| Expansion | 40-pin GPIO header (UART, I2C, SPI, PWM, etc.) |
| Audio | 3.5mm Headphone/Mic jack, 2× Speaker headers, 1× Analog MIC header |
| Power Supply | 100W Dual USB Type-C PD (20V/5A) |
| Dimensions | 115mm × 100mm |
As you can see from the specs, this is no joke. 16GB RAM by default, 12-cores processor, with a powerful GPU (Immortalis G720), and a NPU that has a claimed performance up to 30 TOPS. Not just that, but there’s numerous ports on this SBC, with 2 full sized M2 2280 slots! You can tell that the IO is not going to be a joke here.
If you are wondering about the SOC itself, we have more info about what to expect from CIX.
| Feature | Specification |
|---|---|
| SoC Model | CIX CD8180 / CD8160 (Codename: CIX P1) |
| Architecture | Armv9.2-A (64-bit) |
| Total CPU Cores | 12 Cores (Tri-cluster configuration) |
| Big Cores | 4× Cortex-A720 @ Up to 2.8 GHz (Performance) |
| Medium Cores | 4× Cortex-A720 @ Up to 2.4 GHz (Mainstream) |
| Little Cores | 4× Cortex-A520 @ 1.8 GHz (Efficiency) |
| L3 Cache | 12MB Shared L3 Cache |
| GPU | Arm Immortalis-G720 MC10 |
| Graphics Features | Hardware Ray Tracing, Vulkan 1.3, OpenGL ES 3.2, OpenCL 3.0 |
| NPU (AI Engine) | Arm-China Zhouyi: 30 TOPS (Dedicated); ~45 TOPS (Total System AI) |
| AI Precision | INT4, INT8, INT16, FP16, TF32 |
| VPU (Video) | Linlon V8: 8K@60fps Decode (AV1/H.265/VP9), 8K@30fps Encode (H.265) |
| Memory Interface | 128-bit LPDDR5 / LPDDR5X (Up to 5500 MT/s) |
| Memory Bandwidth | Up to 96 GB/s (Theoretical peak) |
| PCIe Support | PCIe Gen4 (Supports x8, x4, and x2 configurations) |
| System Security | Integrated Security Engine (Standard Arm SystemReady / ACPI support) |
2.8Ghz ARM Big Cores processors! That’s no joke, this is way beyond the typical frequency we see for small boards where things are usually below 2 Ghz. The memory interface also has a huge bandwidth, and we get full PCI4 with 8 lanes! This means that this board could probably be attached to an external GPU (eGPU) and be able to drive it (provided adequate software support).
About the NPU, the usual problem on Linux is that there is poor software support, and it’s certainly not in the mainline either. To leverage the 30 TOPS of dedicated AI power, you cannot simply use standard versions of PyTorch or TensorFlow out of the box. You must use the NeuralONE AI SDK. This also means that the NPU cannot use regular weights, and need to compile them into a different format to make them work. On paper, the NPU is highly versatile and supports the following data types: INT4, INT8, INT16, FP16, BF16, and TF32. The board has extensive documentation on a bunch of embedded models for vision detection, automation, such as YOLOv8 (Vision), ResNet50, OpenPose, and DeepLabv3.
Now let’s jump into the actual user experience.
Software Support
Desktop Experience
Debian Bookworm
There is a Debian Bookworm (12) image available at the time of writing. I was actually waiting for a 24.04 Ubuntu image to be made available, and that was the plan at some point according to my OrangePi contact, but they had to shift priorities apparently and now there is no ETA for the Ubuntu image. So instead of waiting, I decided to go ahead and review what’s possible with this Debian image. As you know, Debian Bookworm is not that new anymore (the base is from Mid-2023), and is now superseded by Debian Trixie (released in 2025). This Debian image comes with two kernels available, 6.1 and 6.6. The 6.6 kernel is also from 2023, and it’s not surprising you don’t get a more recent kernel, since the Linux support for various parts of the boards, not being upstreamed and mainlined, is very likely to be stuck on an older version. This is usually what causes headaches down the road: maybe some general functionality can be upstreamed, but will the NPU have working drivers for a more recent kernel? Your guess is as good as mine.

You can burn the image directly on the NVME drive - no need to boot on a MicroSD card this time around. Note that at the beginning, my OrangePi did not boot, but I could see from the BIOS (yes, this board comes with a BIOS-like interface!) that everything was supposed to be seen by the SBC. Turns out that the firmware required an update to be able to boot on this Linux kernel, and after imaging the latest firmware on a USB stick and booting on it, a few minutes later, things worked as expected.
In any case, we get a GNOME desktop after boot. And everything works pretty much as you’d expect. Once thing that is immediately apparent when you start with the desktop is how snappy everything is. SBC boards like the Raspberry Pi 4 provide a good desktop experience but have some general sluggishness to them. On this board, this is pretty much like having a X86_64 experience. It recognized immediately my Ultra Wide Display and supported the 3440 x 1440 resolution without a hitch. Everything from navigating the desktop and settings is very fast. You get Chromium by default (and Firefox ESR in the repos) and the browser experience is very clean and fast, too. This board has absolutely no problem to play Youtube streams, even at 4k. This thing is FAST!
A quick look at vulkaninfo shows that we have working Vulkan drivers on this board! This is something that was initially very exciting, but it turns out that there are some limitations. More on that later.

Turns out the Vulkan driver is limited to some early 1.3 version. You have options to upgrade Mesa, by using Debian backports - it gets you to a 25.07 Mesa version, where you don’t rely anymore on the proprietary driver - no, this time you get Panfrost, which means a more robust driver potentially… except that you are stuck on the 6.6 Linux Kernel, and Panfrost requires a more recent kernel to work properly (6.10+ apparently). So the solution would be to move to a more recent kernel, right? Do the Debian backports have it? Yes. Problem is, moving away from 6.6 will break a lot of patches that are necessary for the hardware of this board to work. Such as HDMI out at resolutions higher than 1080p, and NPU support! So, it’s a major trade-off.
Getting Bluetooth to work
Even though bluetooth shows in the GNOME desktop controls, and that it could see some of my peripherals, it could not connect to any of my external audio devices. But I don’t give up so fast. Turns out there’s an issue with a missing pipewire dependency to allow for bluetooth audio to work. Here’s how you can get it done:
sudo apt install libspa-0.2-bluetooth pipewire-audio-client-libraries
Afterwards you can launch bluetoothctl from the command line, and you can execute the following commands one by one
power on
agent on
default-agent
scan on
After the scan is activated you should see bluetooth device popping up in the terminal. Note the ID of the bluetooth device you want to connect, and then:
pair <device id>
trust <device id>
connect <devic_id>
Once this is fixed, things work as expected. And now I get audio!
Compiling OBS
OBS is not available as flatpak for arm64, and not in the repos either. This means, that you are in for a compilation from sources. This is not the thing that scares me. But in our situation, it’s a little more convoluted that I expected. First, turns out that OBS did not like the fact that the Cmake was relatively old. So I had to get one of the recent Cmake binaries. Thanksfully they have arm64 binaries already available on their website, so that was easy.

Next, OBS would complain of a too old FFmpeg version. Not too surprising for something that depends so heavily on it. So I had to go for a full FFmpeg compilation. Here’s what I did to save you time:
git clone https://github.com/FFmpeg/FFmpeg.git
cd ffmpeg
git checkout release/7.1 # in order to have a stable release, not the master branch in itself
./configure --prefix=/usr/local --enable-shared --disable-static --enable-gpl --enable-libx264 --enable-libx265
make -j$(nproc)
sudo make install
Finally, compiling OBS is a game of cat and mouse, you need to basically give up one extension after the other as new errors arise. Most of the things you need to remove are not critical (NVENC, not relevant on non-nvidia hardware, browser support, not really our thing either) and at the end you get a fairly long series of command.
git clone https://github.com/obsproject/obs-studio.git
cd obs-studio
# remove the obs-browser plugin from the obs folder root directlroy
mv plugins/obs-browser plugins/obs-browser.bak
# from the obs root folder
git submodule update --init --recursive
# a couple of exports to avoid the compilation to fail because of FFmpeg warnings
export CFLAGS="-Wno-error=deprecated-declarations"
export CXXFLAGS="-Wno-error=deprecated-declarations"
# since the flags can be ignored, we also edit the following file from the root directory
echo 'target_compile_options(obs-ffmpeg PRIVATE "-Wno-error=deprecated-declarations")' >> plugins/obs-ffmpeg/CMakeLists.txt
# use the path to the cmake version you just downloaded
<path_to_newer_cmake_binary>/cmake -DCMAKE_PREFIX_PATH=/usr/local -DFFMPEG_INCLUDE_DIR=/usr/local/include -DPKG_CONFIG_PATH=/usr/local/lib/pkgconfig -DENABLE_AJA=OFF -DUNIX_STRUCTURE=1 -DENABLE_GIO=OFF -DENABLE_VPL=OFF -DENABLE_QSV11=OFF -DENABLE_BROWSER=OFF -DENABLE_WEBRTC=OFF -DENABLE_NATIVE_NVENC=OFF -DCMAKE_COMPILE_WARNING_AS_ERROR=OFF ..
make -j$(nproc)
sudo make install
It took a little while, but it worked!
I must admit, I did not expect that it would go so well in the end. Now, thanks to this, you will get a lot of videos from the board in action that no other site reviewing that board has been able to offer.
Noise and Temperature
The board is very quiet by default. Even when the fan is activated, you barely hear it, at least under fairly typical conditions. Things change when you push the board to its full power, for example a long compilation time. In such conditions, the fan becomes louder with a woosh kind of sound. You will definitely hear it when doing benchmarks, and in my case, when running LLMs, for example.

In terms of temperature, the control is very good. At 100% usage even for long durations, while the fan becomes clearly noticeable, it maintains the temperature under 60 C (this is winter right now, and the temperature remained at 58 C). Kudos for the good engineering there. It’s as good as the custom cooling solution for my RTX3090.
Power Draw
I don’t have a way to measure the power draw currently, but based on reports from other publications it looks like we are looking at:
- 15W at idle, which is fairly high
- 30+W during usage - this is why they recommend to use the provided PSU with USB-C. Note that any charger that can provide 45W should do the trick as well.
So, if you are looking for something that has almost no footprint at idle, this is not it. At idle the OrangePi 5 Ultra consumes more than 3 times less, so that sound more like something you’d use for a server.
Benchmarks
A quick run at Geekbench 6 shows a very strong single core score, and an exceptional multi-core score.
Now the details in single score:
And in multi-core where we can see that the OrangePi 6 absolutely crushes what you can find on a Raspberry Pi 5.
Of course, this is a relatively cheap system that is not going to win the benchmark charts. But look at the results. On single core, we get a score equivalent to a i5-10500 running at a similar frequency (2.3 Ghz).

On multicore this is much more impressive, thanks to its twelve cores. And it gets very close, according to the bench, to what an AMD Ryzen 7 4800H (8 cores) can deliver.

This is clearly a powerhouse, CPU-wise. For a starting price at 199 USD for the 16GB version, this is a fantastic value proposition. We reviewed the OrangePi 5 Ultra a few months back and the price point is very close (around 160 USD), and unless you need something very small and fanless, the OrangePi 6 Plus is (very clearly) a better deal.
Gaming
Since we have both a fairly powerful SOC, and a working Vulkan driver, this means that we can expect Box64 to do some magic for us there. I compiled Box64 to make it possible to launch Steam, and for some reason there is some Vulkan related error that prevents Steam from launching. Too bad. I still have a GOG account with a few games that have Linux clients. I tried the following:
- Beholder 2
- Shadow Warrior 2013
- Oxenfree
- Day of the Tentacle Remastered
- Torchlight 2
And with some degree of success! Beholder 2 worked just fine, and are definitely playable on this board, while the framerate remains between the 20s and 30s FPS (here a little slower on this video because of software OBS capture).
Here’s Oxenfree’s Linux x86_64 client running in Full HD on the OrangePi 6 Plus, using Box64:
Torchlight 2 runs nicely too, at something like 20 to 30 FPS in Full HD.
Shadow Warrior refused to launch, complaining about the graphics drivers not being recent enough (turns out that Zink provides OpenGL support, and there is some issue to detect that the OpenGL version is properly supported… my guess). Day of the Tentacle crashes at start too, not sure why. When games work, the performance is not staggering but convincing for a somewhat small SoC at the end of the day. AMD and Intel are certainly ahead in terms of graphics performance on integrated chips, but they have much larger processors and much more expensive ones, too.
I also tried FOSS games or engines:
- GZDoom (compiled from source, the flatpak version sucks in performance!)
- Luanti (ex-Minetest)
- IOQuake3 (compiled from source)
- OAD (from Debian repos)
GZDoom works exceptionally well with the OpenGLES renderer at Full HD. It’s fast, responsive. Stable at 60 FPS on Full HD. And Doom is still as fun as it was in the days, or more so if you run Brutal Doom.
While I don’t have a sample video here, Quake 3 Arena with the IOQuake3 engine works perfectly, and runs at 60 fps on Full HD without a sweat.
Luanti (ex Minetest) works extremely well - I turned most of the details to the max at 1080p and it kept at a solid 60 FPS. Sure, that’s no AAA game, but it’s a good alternative to Minecraft.
0Ad works extremely well, even in full screen at my Ultra Wide screen resolution. I took a video at FUll HD, and while OBS does slow the framerate a little, you can still see it’s very smooth.
0ad has come a long way, I really need to revisit a recent version of the game to see how much it has changed!
Server use
This is a very capable board that would make a very powerful server. The Debian image comes with Docker, and as we have seen before during the OrangePi 5 Ultra review, the landscape of ready-to-use Docker Hub images is huge and can get you started with numerous server-side applications in no time. Since we have at least 16Gb of memory, very fast I/O (PCIe4!), and a very fast CPU, this SBC will be able to wonders with a wide variety of applications. The only problem is the power draw. It looks like we are stuck with 15W as an idle baseline, and that seems a bit too much for some light server use.
AI applications
This board comes with a very large repository (60 GB!) that you can install and sync automatically, with tons of applications and demos you can try out. There is a large part of their documentation dedicated to that part in their manual. And for what I could try, it seems to work as long as you follow their instructions.
In my case I like to work with LLMs for a range of applications, so I was interested to see how fast this board could run some small-ish models. One of the major limitations is that we don’t have working NPU support for llama.cpp (oh no!). I was thinking, “no worries, we have a vulkan driver so let’s use Vulkan instead”. I like to be optimistic sometimes. Turns out that the Vulkan driver is below the minimum Vulkan drivers specs required by llama.cpp recently, and I would need to go back to a end 2024 build to be able to compile for Vulkan support. Going back one year on llama.cpp… not an option, sorry (too many models would not be supported going back so far in time). So, we are left with using the raw power of the CPU. Which means it won’t be quiet - expect some good old noise fan in such use cases.
Anyway, I went for Qwen3 1.7b - downloaded the safetensors weights, then converted them to gguf, followed by a quantization step to make them IQ4_S. Running the model at this kind of quantization gives us about 14 tokens per second when doing inference. Definitely usable, very usable even, while this is a small model.
Ideally, you’d want to have a board that can run a 7b model with proper hardware acceleration and no fan usage. Not sure if having actual NPU support in the future would help for that or not. In other words, we are not there yet.
Existing Alternatives
As usual there is not a single vendor who can provide you with a CIX experience. This time the main competitor is Radxa, and they have two boards called Orion 6 that feature the same chip - one that is much bigger in footprint (mini-ITX size), and another one that is more similar to the OrangePi 6 Plus size (the Orion 6N). While I don’t have access to the Radxa ones, I can’t comment on how good their support is, but they are very likely to suffer from the same limitations, software wise.

As expected, they also only provide a Debian Bookworm image under the Radxa OS nickname so this is no different from what you can get on the OrangePi 6 Plus. Price-wise, they are both available at around similar price points, so you could make you decision based on the best deal you can get.
Verdict
This is a very impressive SBC, with an exceptional value proposition. Its performance profile puts if far away from the toy category from what we have seen before in the SBC category, and puts it right into the desktop performance realm. It’s still relatively small so you could easily attach it behind a monitor and power a personal computer this way. As a Linux user, things are so fast that you’d be very surprised this is an ARM board running under the hood. For server use, you’d probably want to avoid this one, because of the fairly heavily baseline power consumption.
As usual, the pitfalls are always going to be the same. This time around you get an older Debian image (bookworm), with an older kernel (6.6), and some proprietary drivers that you have to live with. Ultimately if you want to upgrade the software running on your SBC that will mean breaking things, and there’s often a fairly long time (if ever) for some hardware components to be supported in newer distros. It’s not necessarily a deal breaker these days. This board is fast enough to compile software fairly quickly if needed. You have Flatpak as well providing some good coverage for a lot of application (even if performance may be sub-par). There are ongoing efforts to mainline the GPU found in the chip, so it could be that a year from now we are in a better place when it comes to proper hardware support beyond kernel 6.6.
In any case, this is a surprising new entry in terms of performance / price point. This puts the bar very high for future SBCs ARM64 SBCs. On a personal note, I’d like to see some serious hardware dedicated to running AI models (instead of large desktops chaining multiple GPUs), and maybe highly customized ARM64 SBCs are going to become one option at some point.
If you are interested in getting one, there are many resellers, but one of the most direct ones are on Aliexpress:
Since the difference of price between 16 GB and 32GB is so small currently, it would make total sense to go for the 32GB.
Note: we were provided with a review unit from OrangePi (more specifically the OrangePi 6 Plus 16GB version).