The Orange Pi 6 Plus

The Orange Pi 6 Plus breaks away from the common RK3588 trend with a powerful 12-core CIX P1 SoC and dual 5GbE ports, though it requires significant software tinkering to reach its full potential.
This was a long one–I spent a fair bit of time with the Orange Pi 6 Plus over the past few months, and what I expected to be a quick look at another fast ARM board turned into one of those test runs where the hardware looks promising on paper, the software is wonky in exactly the wrong places, and you end up diving far more into boot chains, vendor GPU blobs and inference runtimes than you ever intended.
Unlike most of the ARM boards I’ve reviewed until now, this one is not an RK3588 board: The Orange Pi 6 Plus uses the CIX P1 (CD8180/CD8160), with 12 CPU cores, a Mali G720 GPU, a dedicated NPU and a wild set of specs for the form factor. Boards like this promise everything at once–homelab, edge AI, dual 5GbE, low power–but they only matter if the software gets out of the way.
Disclaimer: Orange Pi supplied me with a 6 Plus free of charge, and, as usual, this article follows my review policy.
And, for a change, I decided to make sure the software did exactly that, and made it my concern from the start–i.e., I built my own OS images for it (a fork of orangepi-build) and went in a bit deeper than usual, spending around two months taking notes, benchmark logs and even Graphite telemetry as I went along.
Hardware
One of the reasons I wanted to test this board is that the SoC is the CIX P1, which Orange Pi bills as a 12-core part with a combined 45 TOPS across CPU, GPU and NPU. The machine I tested came with:
- CIX P1 (CD8180/CD8160), 4×Cortex-A520 plus 8×Cortex-A720 cores
- 16GiB of RAM (roughly 14GiB visible to Linux)
- dual Realtek RTL8126 5GbE
- Realtek RTL8852BE Wi-Fi and Bluetooth card
- Mali G720 / Immortalis-class GPU
- A three-core Zhouyi NPU
And if you’ve been paying attention to all my homelab testing, those two 5GbE ports alone make this more interesting than most hobbyist SBCs. But, of course, there is a lot more to expandability than that:
Hardware Info
The CPU is interesting in itself–the fastest A720 cluster reaches about 2.6GHz, the A520s top out around 1.8GHz, so like many other big.LITTLE ARM architectures you get asymmetric clusters rather than a uniform twelve-core machine.
lspci is a bit more revealing, especially because you get to see where the dual 5GbE setup and Wi-Fi controller are placed–each seems to get its own PCI bridge. In the same way, the USB bus is entirely ordinary. Nothing exotic, which I rather like. And, by the way, the board ships with Cix Technology Group UEFI, version 1.3, so setting up boot devices and managing (very) basic settings was trivial.
Building the Image
This is where I took a very large detour from my usual approach: I decided early on that I wasn’t going to use a vendor image for this board. Vendor images for SBCs like this always tend to be good enough to boot, occasionally good enough to do basic benchmarks, and almost never something I want to build on.
I wanted a server-first layout, reproducible fixes and a place to bake in GPU/NPU prerequisites, so I forked orangepi-build and started from there, with a fairly high bar: a fully reproducible Debian 13 / Trixie build with features like /dev/kvm present. Over a few weeks, I added Trixie configs, patched distribution scripts, and removed Ubuntu-only dependencies.
Getting To First Boot
My first boot-related note on this board was short: I flashed my custom Trixie image, got as far as GRUB, and it fell over because the EFI stub was wrong. The image did contain the right DTBs, but the build scripts somehow pointed at the ACPI path. Getting past GRUB was only half the battle. The first real boot surfaced another issue: the partition resize worked, but the root filesystem resize didn’t. I had to trace the resize helper and patch it to ensure a deterministic first boot.
NVMe and Swap
Once the image was booting reliably, I wanted the board off SD entirely. I partitioned a 512GB NVMe drive into EFI, root and swap, used rsync to move everything across, and patched GRUB.CFG to point at the new PARTUUID.
Software Summary
To recap, I had to fix the boot chain (initially broken due to GRUB paths), stabilize the OS by moving to a clean Debian 13 build, and ensure GPU/NPU firmware was correctly staged. The hardware is a powerhouse, but the software requires a deep dive to get right.
Source: Hacker News















