I went through an unboxing and Debian 12 installation on the Radxa Orion O6 at the end of January, but decided to work on other reviews since software support still needed to be worked on. Since then, there’s been some work done, but no new image released. After waiting for almost two months, I’ve decided to carry on with the review by testing the Debian 12 image in a way similar to the Rock 5B SBC preview I did with Debian 11 in 2022 to check what works and what doesn’t on the Orion O6 at the time of the review.
That will involve testing all ports, including 5GbE networking and the PCIe slot with an (old) NVIDIA graphics card, running some benchmarks, and also trying the Debian 12 image with a self-built Linux 6.13 kernel using ACPI instead of UEFI for the default image.
Orion O6 SBC benchmarks on Debian 12 (take 2)
When I ran sbc-bench.sh in the first part of the review, I used the default 2.5GHz CPU frequency. However, the BIOS has options to set that to 2.6GHz, and I also changed the GPU frequency from 900 MHz to 1.1 GHz to achieve the maximum performance possible at this time. Eventually, the CIX P1 12-core CPU might support 2.8 GHz.
I ran sbc-bench.sh script again, updated to version 0.9.71. I had to disable the load average check in the script, and I also left the script “/usr/bin/cix_audio_switch.sh” script running because it’s needed for audio:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 |
radxa@orion-o6:~$ sudo ./sbc-bench.sh -r Starting to examine hardware/software for review purposes... sbc-bench v0.9.71 Installing needed tools: distro packages already installed. Done. Checking cpufreq OPP. Done. Executing tinymembench. Done. Executing RAM latency tester. Done. Executing OpenSSL benchmark. Done. Executing 7-zip benchmark. Done. Throttling test: heating up the device, 5 more minutes to wait. Done. Checking cpufreq OPP again. Done (28 minutes elapsed). Results validation: * Measured clockspeed not lower than advertised max CPU clockspeed * Background activity (%system) OK * Too much other background activity: 2% avg, 2% max -> https://tinyurl.com/mr2wy5uv * Throttling occured -> https://tinyurl.com/4ky59sys * schedutil cpufreq governor configured but neither dynamic-power-coefficient nor sched-energy-costs defined Full results uploaded to https://0x0.st/8BSl.bin # Radxa Orion O6 Tested with sbc-bench v0.9.71 on Sun, 02 Mar 2025 22:32:37 +0800. Full info: [https://0x0.st/8BSl.bin](http://0x0.st/8BSl.bin) ### General information: The CPU features 6 clusters consisting of 2 different core types: Cix P1/CD8180, Kernel: aarch64, Userland: arm64 CPU sysfs topology (clusters, cpufreq members, clockspeeds) cpufreq min max CPU cluster policy speed speed core type 0 0 0 800 2600 Cortex-A720 / r0p1 1 0 1 800 1800 Cortex-A520 / r0p1 2 0 1 800 1800 Cortex-A520 / r0p1 3 0 1 800 1800 Cortex-A520 / r0p1 4 0 1 800 1800 Cortex-A520 / r0p1 5 0 5 800 2300 Cortex-A720 / r0p1 6 0 5 800 2300 Cortex-A720 / r0p1 7 0 7 800 2200 Cortex-A720 / r0p1 8 0 7 800 2200 Cortex-A720 / r0p1 9 0 9 800 2500 Cortex-A720 / r0p1 10 0 9 800 2500 Cortex-A720 / r0p1 11 0 9 800 2500 Cortex-A720 / r0p1 15222 KB available RAM ### Governors/policies (performance vs. idle consumption): Original governor settings: cpufreq-policy0: schedutil / 1800 MHz (userspace performance schedutil / 800 1200 1500 1800 2100 2300 2600) cpufreq-policy1: schedutil / 1800 MHz (userspace performance schedutil / 800 1800) cpufreq-policy5: schedutil / 800 MHz (userspace performance schedutil / 800 1200 1500 1800 2000 2100 2300) cpufreq-policy7: schedutil / 1500 MHz (userspace performance schedutil / 800 1200 1500 1800 1900 2000 2200) cpufreq-policy9: schedutil / 1800 MHz (userspace performance schedutil / 800 1200 1500 1800 2000 2200 2500) 14230000.vpu: simple_ondemand / 150 MHz (userspace performance simple_ondemand / 150 300 480 600 800 1200) 14260000.aipu: userspace / 1200 MHz (userspace performance simple_ondemand / 400 600 800 1200) 15000000.gpu: simple_ondemand / 72 MHz (userspace performance simple_ondemand / 72 216 350 600 800 1100) Tuned governor settings: cpufreq-policy0: performance / 2600 MHz cpufreq-policy1: performance / 1800 MHz cpufreq-policy5: performance / 2300 MHz cpufreq-policy7: performance / 2200 MHz cpufreq-policy9: performance / 2500 MHz 14230000.vpu: performance / 1200 MHz 14260000.aipu: performance / 1200 MHz 15000000.gpu: performance / 1100 MHz Status of performance related policies found below /sys: /sys/devices/platform/soc@0/14260000.aipu/gm_policy: [1] AIPU GM is shared by tasks of all QoS level. /sys/devices/platform/soc@0/15000000.gpu/power_policy: [coarse_demand] always_on /sys/module/pcie_aspm/parameters/policy: default [performance] powersave powersupersave ### Clockspeeds (idle vs. heated up): Before at 46.0°C: cpu0 (Cortex-A720): OPP: 2600, Measured: 2598 cpu1-cpu4 (Cortex-A520): OPP: 1799, Measured: 1797 cpu5-cpu6 (Cortex-A720): OPP: 2299, Measured: 2298 cpu7-cpu8 (Cortex-A720): OPP: 2199, Measured: 2198 cpu9-cpu10 (Cortex-A720): OPP: 2499, Measured: 2498 cpu11 (Cortex-A720): Measured: 2598 After at 77.0°C (throttled): cpu0 (Cortex-A720): OPP: 2600, Measured: 2598 cpu1-cpu4 (Cortex-A520): OPP: 1799, Measured: 1795 cpu5-cpu6 (Cortex-A720): OPP: 2299, Measured: 2298 cpu7-cpu8 (Cortex-A720): OPP: 2199, Measured: 2198 cpu9-cpu10 (Cortex-A720): OPP: 2499, Measured: 2498 cpu11 (Cortex-A720): Measured: 2598 ### Performance baseline * cpu0 (Cortex-A720): memcpy: 12734.5 MB/s, memchr: 26822.7 MB/s, memset: 36720.4 MB/s * cpu1 (Cortex-A520): memcpy: 8857.0 MB/s, memchr: 1791.7 MB/s, memset: 28361.8 MB/s * cpu5 (Cortex-A720): memcpy: 15156.3 MB/s, memchr: 23932.1 MB/s, memset: 38251.1 MB/s * cpu7 (Cortex-A720): memcpy: 16882.4 MB/s, memchr: 22897.2 MB/s, memset: 28147.2 MB/s * cpu9 (Cortex-A720): memcpy: 14660.4 MB/s, memchr: 25884.6 MB/s, memset: 33965.8 MB/s * cpu11 (Cortex-A720): memcpy: 13036.7 MB/s, memchr: 26376.3 MB/s, memset: 27371.6 MB/s * cpu0 (Cortex-A720) 16M latency: 41.57 27.18 36.06 27.96 35.20 29.36 34.47 44.64 * cpu1 (Cortex-A520) 16M latency: 60.98 92.29 67.55 88.28 75.31 72.16 81.85 108.7 * cpu5 (Cortex-A720) 16M latency: 34.47 26.83 33.50 25.65 40.69 27.93 32.78 45.81 * cpu7 (Cortex-A720) 16M latency: 41.20 25.45 33.55 27.13 33.58 28.75 33.22 43.15 * cpu9 (Cortex-A720) 16M latency: 34.49 26.60 32.93 25.50 36.68 27.42 33.11 41.69 * cpu11 (Cortex-A720) 16M latency: 42.96 25.28 34.79 26.52 32.96 30.02 31.29 42.39 * cpu0 (Cortex-A720) 128M latency: 50.70 72.54 49.22 73.66 50.32 68.46 98.87 140.2 * cpu1 (Cortex-A520) 128M latency: 220.2 222.3 221.1 223.2 220.6 223.2 235.3 325.8 * cpu5 (Cortex-A720) 128M latency: 48.55 70.07 49.07 70.33 48.74 67.07 101.6 139.1 * cpu7 (Cortex-A720) 128M latency: 49.28 70.35 48.50 70.31 48.33 64.99 95.27 136.7 * cpu9 (Cortex-A720) 128M latency: 47.33 70.17 48.38 70.04 47.74 63.02 92.89 136.8 * cpu11 (Cortex-A720) 128M latency: 48.74 69.10 48.07 66.90 48.06 66.41 91.37 137.9 * 7-zip MIPS (3 consecutive runs): 31772, 31512, 32020 (31770 avg), single-threaded: 3902 * `aes-256-cbc 865954.02k 1308675.65k 1430585.77k 1451649.37k 1457927.51k 1458372.61k (Cortex-A720)` * `aes-256-cbc 168944.25k 342178.62k 461513.90k 505287.68k 519705.94k 520421.38k (Cortex-A520)` * `aes-256-cbc 766162.84k 1157427.46k 1265474.65k 1284091.90k 1289598.29k 1290048.85k (Cortex-A720)` * `aes-256-cbc 732852.87k 1107180.71k 1210452.31k 1228282.54k 1233616.90k 1233999.19k (Cortex-A720)` * `aes-256-cbc 832787.97k 1258092.27k 1375477.42k 1395749.89k 1401809.58k 1402241.02k (Cortex-A720)` * `aes-256-cbc 866033.34k 1308272.04k 1430369.96k 1451484.16k 1457774.59k 1458236.07k (Cortex-A720)` ### PCIe and storage devices: * Realtek RTL8852BE PCIe 802.11ax Wireless Network: Speed 2.5GT/s, Width x1, driver in use: rtw89_8852be, ASPM Disabled * Realtek RTL8126 5GbE: Speed 8GT/s, Width x1, driver in use: r8126, ASPM Disabled * Realtek RTL8126 5GbE: Speed 8GT/s, Width x1, driver in use: r8126, ASPM Disabled * 476.9GB "PCIe SSD" SSD as /dev/nvme0: Speed 8GT/s, Width x4, 0% worn out, drive temp: 36°C, ASPM Disabled ### Software versions: * Debian GNU/Linux 12 (bookworm) * Compiler: /usr/bin/gcc (Debian 12.2.0-14) 12.2.0 / aarch64-linux-gnu * OpenSSL 3.0.15, built on 3 Sep 2024 (Library: OpenSSL 3.0.15 3 Sep 2024) ### Kernel info: * `/proc/cmdline: BOOT_IMAGE=/Image loglevel=0 console=ttyAMA2,115200 efi=noruntime earlycon=pl011,0x040d0000 arm-smmu-v3.disable_bypass=0 acpi=off root=PARTUUID=21b3cd7c-3570-4a71-aa70-a3c2b1063c78 rootwait rw` * Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl * Vulnerability Spectre v1: Mitigation; __user pointer sanitization * Kernel 6.1.44-cix-build-generic / CONFIG_HZ=250 Kernel 6.1.44 is not latest 6.1.129 LTS that was released on 2025-02-21. See https://endoflife.date/linux for details. It is somewhat likely that a lot of exploitable vulnerabilities exist for this kernel as well as many unfixed bugs. All known settings adjusted for performance. Device now ready for benchmarking. Once finished stop with [ctrl]-[c] to get info about throttling, frequency cap and too high background activity all potentially invalidating benchmark scores. All changes with storage and PCIe devices as well as suspicious dmesg contents will be reported too. Time cpu0/cpu1/cpu5/cpu7/cpu9 load %cpu %sys %usr %nice %io %irq Temp 22:32:43: 2600/1800/2300/2200/2500MHz 10.92 31% 0% 29% 0% 0% 0% 46.0°C |
There are some improvements to the 7-zip score at 31,770 MIPS on average with the higher CPU frequency. I’m not sure we should care about the memory bandwidth numbers that much since they are all over the place… The Orion O6 is still the fastest board I’ve tested so far, outperforming the Rock 5B (RK3588), Raspberry Pi 5, and UP 7000 (Intel N100) SBC.
The OpenSSL test also shows an improvement with the higher frequency. Note that it is a single-core benchmark, so the Orion O6 does not benefit from the 12 cores on the P1 SoC.

I’ll run other benchmarks, as I test features on the board
Storage
Let’s run iozone3 on the M.2 NVMe SSD I installed on the motherboard to test the PCIe interface:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
radxa@orion-o6:~$ iozone -e -I -a -s 1000M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 Iozone: Performance Test of File I/O Version $Revision: 3.489 $ Compiled for 64 bit mode. Build: linux Output is in kBytes/sec random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 1024000 4 77811 96611 105365 106083 53255 98142 1024000 16 389971 344660 96986 97062 152006 252953 1024000 512 1953404 2162714 977644 1017265 1008912 1987809 1024000 1024 2200030 2196034 1421633 1423228 1416168 2015445 1024000 16384 2186107 2130259 2340284 2378495 2388743 2144434 iozone test complete. |
A read speed of 2,340 MB/s is around the max read speed (2,050 MB/s) advertised for the MAKERDISK SSD used with the system. That part works as expected.
Video Output
The Orion O6 supports up to four displays through an HDMI 2.0 port, a DisplayPort video output, USB-C ports, and an eDP connector. I could not test the latter, but I did try to connect the CIX P1 motherboard to four displays, including a KTC A32Q8 4K monitor providing 65 Watts of power to the board through USB PD.
HDMI and USB-C video output worked up to 4K, but DisplayPort did not, and the second USB-C port would not output video (albeit detected) while getting power from the monitor. If I switch the USB-C port, then I can output.

There may be some interoperability issues here, and your experience may vary with other monitors or TVs. Audio worked over HDMI.
Networking (5GbE & WiFi 6)
The Orion O6 features two 5GbE (5 Gbps Ethernet) ports, and I also inserted a WiFi 6E module into its M.2 E-Key socket.
Let’s start by testing the left 5GbE port with iperf3 using iKOOLCORE R2 Max 10GbE mini PC on the other side.
- Download to Orion O6:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
radxa@orion-o6:~$ iperf3 -t 60 -c 192.168.4.1 -i 10 -R Connecting to host 192.168.4.1, port 5201 Reverse mode, remote host 192.168.4.1 is sending [ 5] local 192.168.4.235 port 45000 connected to 192.168.4.1 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-10.00 sec 5.48 GBytes 4.71 Gbits/sec [ 5] 10.00-20.00 sec 5.48 GBytes 4.71 Gbits/sec [ 5] 20.00-30.00 sec 5.48 GBytes 4.71 Gbits/sec [ 5] 30.00-40.00 sec 5.48 GBytes 4.71 Gbits/sec [ 5] 40.00-50.00 sec 5.48 GBytes 4.71 Gbits/sec [ 5] 50.00-60.00 sec 5.48 GBytes 4.71 Gbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-60.00 sec 32.9 GBytes 4.71 Gbits/sec 0 sender [ 5] 0.00-60.00 sec 32.9 GBytes 4.71 Gbits/sec receiver iperf Done. |
- Upload from Orion O6
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
radxa@orion-o6:~$ iperf3 -t 60 -c 192.168.4.1 -i 10 Connecting to host 192.168.4.1, port 5201 [ 5] local 192.168.4.235 port 54676 connected to 192.168.4.1 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-10.00 sec 5.48 GBytes 4.71 Gbits/sec 0 1.48 MBytes [ 5] 10.00-20.00 sec 5.47 GBytes 4.70 Gbits/sec 0 1.48 MBytes [ 5] 20.00-30.00 sec 5.48 GBytes 4.71 Gbits/sec 0 1.48 MBytes [ 5] 30.00-40.00 sec 5.47 GBytes 4.70 Gbits/sec 0 3.40 MBytes [ 5] 40.00-50.00 sec 5.46 GBytes 4.69 Gbits/sec 0 3.40 MBytes [ 5] 50.00-60.00 sec 5.48 GBytes 4.71 Gbits/sec 0 3.40 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-60.00 sec 32.8 GBytes 4.70 Gbits/sec 0 sender [ 5] 0.00-60.00 sec 32.8 GBytes 4.70 Gbits/sec receiver iperf Done. |
- Full duplex (bidirectional)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
radxa@orion-o6:~$ iperf3 -t 60 -c 192.168.4.1 -i 10 --bidir Connecting to host 192.168.4.1, port 5201 [ 5] local 192.168.4.235 port 55502 connected to 192.168.4.1 port 5201 [ 7] local 192.168.4.235 port 55514 connected to 192.168.4.1 port 5201 [ ID][Role] Interval Transfer Bitrate Retr Cwnd [ 5][TX-C] 0.00-10.00 sec 5.45 GBytes 4.68 Gbits/sec 0 1.71 MBytes [ 7][RX-C] 0.00-10.00 sec 5.46 GBytes 4.69 Gbits/sec [ 5][TX-C] 10.00-20.00 sec 5.47 GBytes 4.70 Gbits/sec 0 1.71 MBytes [ 7][RX-C] 10.00-20.00 sec 5.47 GBytes 4.69 Gbits/sec [ 5][TX-C] 20.00-30.00 sec 5.47 GBytes 4.70 Gbits/sec 0 1.71 MBytes [ 7][RX-C] 20.00-30.00 sec 5.46 GBytes 4.69 Gbits/sec [ 5][TX-C] 30.00-40.00 sec 5.47 GBytes 4.70 Gbits/sec 0 1.71 MBytes [ 7][RX-C] 30.00-40.00 sec 5.47 GBytes 4.69 Gbits/sec [ 5][TX-C] 40.00-50.00 sec 5.47 GBytes 4.70 Gbits/sec 0 1.71 MBytes [ 7][RX-C] 40.00-50.00 sec 5.46 GBytes 4.69 Gbits/sec [ 5][TX-C] 50.00-60.00 sec 5.47 GBytes 4.70 Gbits/sec 0 1.71 MBytes [ 7][RX-C] 50.00-60.00 sec 5.47 GBytes 4.69 Gbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID][Role] Interval Transfer Bitrate Retr [ 5][TX-C] 0.00-60.00 sec 32.8 GBytes 4.70 Gbits/sec 0 sender [ 5][TX-C] 0.00-60.00 sec 32.8 GBytes 4.70 Gbits/sec receiver [ 7][RX-C] 0.00-60.00 sec 32.8 GBytes 4.69 Gbits/sec 0 sender [ 7][RX-C] 0.00-60.00 sec 32.8 GBytes 4.69 Gbits/sec receiver iperf Done. |
Let’s try again with the second 5GbE port directly with a full duplex test:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
radxa@orion-o6:~$ iperf3 -t 60 -c 192.168.4.1 -i 10 --bidir Connecting to host 192.168.4.1, port 5201 [ 5] local 192.168.4.237 port 47398 connected to 192.168.4.1 port 5201 [ 7] local 192.168.4.237 port 47412 connected to 192.168.4.1 port 5201 [ ID][Role] Interval Transfer Bitrate Retr Cwnd [ 5][TX-C] 0.00-10.00 sec 5.47 GBytes 4.70 Gbits/sec 0 2.10 MBytes [ 7][RX-C] 0.00-10.00 sec 5.47 GBytes 4.70 Gbits/sec [ 5][TX-C] 10.00-20.00 sec 5.47 GBytes 4.70 Gbits/sec 0 2.10 MBytes [ 7][RX-C] 10.00-20.00 sec 5.47 GBytes 4.70 Gbits/sec [ 5][TX-C] 20.00-30.00 sec 5.47 GBytes 4.70 Gbits/sec 0 2.10 MBytes [ 7][RX-C] 20.00-30.00 sec 5.47 GBytes 4.70 Gbits/sec [ 5][TX-C] 30.00-40.00 sec 5.47 GBytes 4.70 Gbits/sec 0 2.10 MBytes [ 7][RX-C] 30.00-40.00 sec 5.47 GBytes 4.70 Gbits/sec [ 5][TX-C] 40.00-50.00 sec 5.47 GBytes 4.70 Gbits/sec 0 2.10 MBytes [ 7][RX-C] 40.00-50.00 sec 5.47 GBytes 4.70 Gbits/sec [ 5][TX-C] 50.00-60.00 sec 5.47 GBytes 4.70 Gbits/sec 0 2.10 MBytes [ 7][RX-C] 50.00-60.00 sec 5.47 GBytes 4.70 Gbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID][Role] Interval Transfer Bitrate Retr [ 5][TX-C] 0.00-60.00 sec 32.8 GBytes 4.70 Gbits/sec 0 sender [ 5][TX-C] 0.00-60.00 sec 32.8 GBytes 4.70 Gbits/sec receiver [ 7][RX-C] 0.00-60.00 sec 32.8 GBytes 4.70 Gbits/sec 0 sender [ 7][RX-C] 0.00-60.00 sec 32.8 GBytes 4.70 Gbits/sec receiver iperf Done. |
Perfect! This part works great.
Time to switch to WiFi 6 after adding a Xiaomi Mi AX6000 router and UP Xtreme i11 Edge mini PC (192.168.31.12) to the testbed:
- Download
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
radxa@orion-o6:~$ iperf3 -t 60 -c 192.168.31.12 -i 10 -R Connecting to host 192.168.31.12, port 5201 Reverse mode, remote host 192.168.31.12 is sending [ 5] local 192.168.31.149 port 48726 connected to 192.168.31.12 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-10.00 sec 1.04 GBytes 896 Mbits/sec [ 5] 10.00-20.00 sec 1.02 GBytes 878 Mbits/sec [ 5] 20.00-30.00 sec 996 MBytes 836 Mbits/sec [ 5] 30.00-40.00 sec 1.04 GBytes 894 Mbits/sec [ 5] 40.00-50.00 sec 1.07 GBytes 921 Mbits/sec [ 5] 50.00-60.00 sec 1.07 GBytes 921 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-60.04 sec 6.23 GBytes 891 Mbits/sec 1 sender [ 5] 0.00-60.00 sec 6.22 GBytes 891 Mbits/sec receiver iperf Done. |
- Upload
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
radxa@orion-o6:~$ iperf3 -t 60 -c 192.168.31.12 -i 10 Connecting to host 192.168.31.12, port 5201 [ 5] local 192.168.31.149 port 54996 connected to 192.168.31.12 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-10.00 sec 664 MBytes 557 Mbits/sec 0 3.08 MBytes [ 5] 10.00-20.00 sec 682 MBytes 573 Mbits/sec 0 3.08 MBytes [ 5] 20.00-30.00 sec 664 MBytes 557 Mbits/sec 0 3.08 MBytes [ 5] 30.00-40.00 sec 680 MBytes 570 Mbits/sec 0 3.08 MBytes [ 5] 40.00-50.00 sec 701 MBytes 588 Mbits/sec 0 3.08 MBytes [ 5] 50.00-60.00 sec 674 MBytes 565 Mbits/sec 0 3.08 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-60.00 sec 3.97 GBytes 568 Mbits/sec 0 sender [ 5] 0.00-60.05 sec 3.97 GBytes 568 Mbits/sec receiver iperf Done. |
I used the Realtek RTL8852BE-based Fn-Link 6252M-PUB WiFi 6 and Bluetooth 5.2 module from the Rock 5B in this test, and the performance is similar to that of the Rockchip RK3588 SBC, except the bitrate does not fluctuate as much. In other words, it’s somewhat more stable on the Orion O6. I’d expect similar results with the Radxa Wireless Module A8 (also based on RTL8852BE).
Bluetooth
While on the topic of the wireless module, I also quickly tested Bluetooth, especially since it did not work the first time I tried it on the Rock 5B in 2022.
I could enable Bluetooth out of the box and transfer a file to the OPPO A98 5G Android smartphone and vice-versa.
I also noticed a “Bluetooth Tethers” menu show up, but it did not work for me. It’s not something I’ve ever used on any other platforms.
USB testing
The Orion O6 comes with six USB ports. Let’s check the performance of each, and in the case of the USB-C ports, features like USB PD and DisplayPort Alt Mode. I connected each to an ORICO USB 3.2 Gen 1 enclosure, Beelink Expand M USB-C dock with 512GB SSD, or a USB 3.0 HDD and ran lsusb to check the connection speed and iozone3 to test the performance.
Example with USB-A #3 port:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
lsusb -t | grep uas |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 10000M radxa@orion-o6:/media/radxa/TB3-EXT4$ sudo iozone -e -I -a -s 10000M -r 16384k -i 0 -i 1 Iozone: Performance Test of File I/O Version $Revision: 3.489 $ Compiled for 64 bit mode. Build: linux random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 10240000 16384 973112 974571 899564 898546 iozone test complete. |
Here’s the summary of all six USB ports on the rear panel from left to right:
- USB-C #1
- ORICO enclosure – Green LED on, but not detected
- Beelink Expand M – Blue LED on, detected, but can’t be enabled with message “Cannot enable. Maybe the USB cable is bad?”
- Power Input – OK
- DisplayPort Alt mode – OK (with CrowView monitor), but note that I had an issue with the KTC monitor while trying to use both USB PD and DP Alt mode at the same time.
- USB-C #2
- ORICO enclosure – Green LED on, but not detected
- Beelink Expand M – Blue LED on, detected, but can’t be enabled with message “Cannot enable. Maybe the USB cable is bad?”
- Power Input – OK
- DisplayPort Alt mode – OK (Although specs don’t mention DP Alt support for that port).
- USB-A #1 (top) – USB 2.0 – 480 Mbps – iozone test won’t complete (see dmesg output below)
- USB-A #2 (bottom) – USB 2.0 – 480 Mbps – iozone test won’t complete (see dmesg output below)
- USB-A #3 (top) – USB 3.0 – 10 Gbps – Read speed: 899 MB/s; write speed: 973MB/s (ORICO enclosure)
- USB-A #4 (bottom) – USB 3.0 – 10 Gbps – Read speed: 937 MB/s; write speed: 977MB/s (ORICO enclosure)
One USB 2.0 port, the iozone3 takes forever with frequent errors shown:
1 2 3 4 5 6 7 |
[ 5507.979630] [2025:03:29 09:27:39][pid:138056,cpu8,kworker/u24:13]sd 0:0:0:0: [sda] tag#13 uas_eh_abort_handler 0 uas-tag 10 inflight: CMD [ 5507.979650] [pid:138056,cpu8,kworker/u24:13]sd 0:0:0:0: [sda] tag#13 CDB: opcode=0x2a 2a 00 28 82 a8 00 00 00 08 00 .... [ 5507.983812] [pid:138056,cpu8,kworker/u24:13]sd 0:0:0:0: [sda] tag#14 CDB: opcode=0x2a 2a 00 28 82 a8 08 00 04 00 00 [ 5517.073341] [2025:03:29 09:27:48][pid:133261,cpu7,scsi_eh_0]scsi host0: uas_eh_device_reset_handler start [ 5517.199664] [pid:133261,cpu5,scsi_eh_0]usb 9-1: reset high-speed USB device number 3 using xhci-hcd [ 5517.349435] [pid:133261,cpu7,scsi_eh_0]scsi host0: uas_eh_device_reset_handler success |
I connected the USB 3.0 HDD to my laptop, just in case this fairly old drive itself had any issues, but nope, the test went through:
1 2 3 4 5 6 7 8 9 10 11 |
jaufranc@CNX-LAPTOP-5:/media/jaufranc/USB3_EXT4$ sudo iozone -e -I -a -s 100M -r 16384k -i 0 -i 1 Iozone: Performance Test of File I/O Version $Revision: 3.506 $ Compiled for 64 bit mode. Build: linux-AMD64 random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 102400 16384 19128 61946 37178 26004 iozone test complete. |
There’s more work to be done to have the USB ports fully working as expected…
PCIe slot
The Orion O6 mini-ITX motherboard also comes with a PCIe x16 slot. I don’t own any recent graphics card, but I do have an old Inno3D NVIDIA GeForce GT210 graphics card I bought with a PC in 2013… So I installed it on the motherboard.
I connected its HDMI port to a monitor, and after booting Debian 12, I was amazed it worked out of the box.
Or so I thought, because it’s not actually usable. When I move the mouse pointer to that monitor, some funny business is happening:
Here’s the output from lspci with the graphics card:
1 2 3 4 5 6 7 8 9 10 11 12 |
sh-5.2$ lspci 0000:90:00.0 PCI bridge: Device 1f6c:0001 0000:91:00.0 Non-Volatile memory controller: Phison Electronics Corporation PS5013 E13 NVMe Controller (rev 01) 0001:60:00.0 PCI bridge: Device 1f6c:0001 0001:61:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8852BE PCIe 802.11ax Wireless Network Controller 0002:c0:00.0 PCI bridge: Device 1f6c:0001 0002:c1:00.0 VGA compatible controller: NVIDIA Corporation GT218 [GeForce 210] (rev a2) 0002:c1:00.1 Audio device: NVIDIA Corporation High Definition Audio Controller (rev a1) 0003:00:00.0 PCI bridge: Device 1f6c:0001 0003:01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. Device 8126 (rev 01) 0004:30:00.0 PCI bridge: Device 1f6c:0001 0004:31:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. Device 8126 (rev 01) |
The good news is that low-level support is working (I get HDMI output), but other issues make it unusable. Switching to another OS image may have worked. People tried various graphics, networking, storage PCIe cards with Debian or Fedora, UEFI or ACPI in the long forum thread about Orion O6’s debug party.
GPIO testing
GPIOs are enabled:
1 2 3 4 5 6 7 8 |
radxa@orion-o6:~$ ls -l /dev/gpiochip? crw------- 1 root root 254, 0 Mar 6 22:56 /dev/gpiochip0 crw------- 1 root root 254, 1 Mar 6 22:56 /dev/gpiochip1 crw------- 1 root root 254, 2 Mar 6 22:56 /dev/gpiochip2 crw------- 1 root root 254, 3 Mar 6 22:56 /dev/gpiochip3 crw------- 1 root root 254, 4 Mar 6 22:56 /dev/gpiochip4 crw------- 1 root root 254, 5 Mar 6 22:56 /dev/gpiochip5 crw------- 1 root root 254, 6 Mar 6 22:56 /dev/gpiochip6 |
But sadly, there’s no information in the wiki about GPIO pin assignment like we had for the Radxa O6. Going to /sys/class/gpio shows some gpiochip devices:
1 2 3 |
radxa@orion-o6:/sys/class/gpio$ ls export gpiochip116 gpiochip32 gpiochip52 unexport gpiochip0 gpiochip148 gpiochip42 gpiochip84 |
We can also list the GPIO as follows:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
sudo apt install gpiod radxa@orion-o6:/sys/class/gpio$ sudo gpioinfo gpiochip0 - 32 lines: line 0: unnamed unused input active-high line 1: unnamed "reset" output active-high [used] line 2: unnamed "reset" output active-high [used] line 3: unnamed "reset" output active-high [used] line 4: unnamed "reset" output active-high [used] line 5: unnamed "reset" output active-high [used] line 6: unnamed unused input active-high line 7: unnamed "status-led" output active-low [used] line 8: unnamed unused input active-high line 9: unnamed "gbe2-power-3v3" output active-high [used] line 10: unnamed unused input active-high line 11: unnamed unused input active-high line 12: unnamed "regulator-vdd-3v3-pcie" output active-high [used] line 13: unnamed unused input active-high line 14: unnamed unused input active-high ... |
You can check out the full output on CNX Software’s pastebin. But as just mentioned, GPIO documentation is seriously lacking (or I missed it), and we’d have to reverse-engineer the pinout.
3D graphics acceleration
The built-in Arm Immortalis-G720 GPU seems to be supported when checking out glxinfo:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 |
sh-5.2$ glxinfo name of display: :0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.4 server glx extensions: GLX_ARB_context_flush_control, GLX_ARB_create_context, GLX_ARB_create_context_no_error, GLX_ARB_create_context_profile, GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, GLX_ARB_multisample, GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, GLX_EXT_get_drawable_type, GLX_EXT_libglvnd, GLX_EXT_no_config_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_OML_swap_method, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_SGI_make_current_read client glx vendor string: Mesa Project and SGI client glx version string: 1.4 client glx extensions: GLX_ARB_context_flush_control, GLX_ARB_create_context, GLX_ARB_create_context_no_error, GLX_ARB_create_context_profile, GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_ATI_pixel_format_float, GLX_EXT_buffer_age, GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, GLX_EXT_import_context, GLX_EXT_no_config_context, GLX_EXT_swap_control, GLX_EXT_swap_control_tear, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, GLX_MESA_query_renderer, GLX_MESA_swap_control, GLX_NV_float_buffer, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync GLX version: 1.4 GLX extensions: GLX_ARB_context_flush_control, GLX_ARB_create_context, GLX_ARB_create_context_no_error, GLX_ARB_create_context_profile, GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_buffer_age, GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, GLX_EXT_no_config_context, GLX_EXT_swap_control, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_query_renderer, GLX_MESA_swap_control, GLX_OML_swap_method, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_SGI_make_current_read Extended renderer info (GLX_MESA_query_renderer): Vendor: Mesa (0x13b5) Device: zink (Mali-G720-Immortalis) (0xc8700000) Version: 23.0.4 Accelerated: yes Video memory: 15222MB Unified memory: yes Preferred profile: core (0x1) Max core profile version: 4.0 Max compat profile version: 4.0 Max GLES1 profile version: 1.1 Max GLES[23] profile version: 3.2 |
Let’s run the glmark2-es2-wayland program to confirm that.
Here’s the output:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 |
sh-5.2$ glmark2-es2-wayland ======================================================= glmark2 2023.01 ======================================================= OpenGL Information GL_VENDOR: ARM GL_RENDERER: Mali-G720-Immortalis GL_VERSION: OpenGL ES 3.2 v1.r49p0-00eac0.b97811108d91b3a6cd0a9d90e51f9da5 Surface Config: buf=32 r=8 g=8 b=8 a=8 depth=24 stencil=0 samples=0 Surface Size: 800x600 windowed ======================================================= [build] use-vbo=false: FPS: 1724 FrameTime: 0.580 ms [build] use-vbo=true: FPS: 1959 FrameTime: 0.511 ms [texture] texture-filter=nearest: FPS: 2533 FrameTime: 0.395 ms [texture] texture-filter=linear: FPS: 2578 FrameTime: 0.388 ms [texture] texture-filter=mipmap: FPS: 2507 FrameTime: 0.399 ms [shading] shading=gouraud: FPS: 2584 FrameTime: 0.387 ms [shading] shading=blinn-phong-inf: FPS: 2370 FrameTime: 0.422 ms [shading] shading=phong: FPS: 2362 FrameTime: 0.423 ms [shading] shading=cel: FPS: 2254 FrameTime: 0.444 ms [bump] bump-render=high-poly: FPS: 1400 FrameTime: 0.714 ms [bump] bump-render=normals: FPS: 2586 FrameTime: 0.387 ms [bump] bump-render=height: FPS: 2453 FrameTime: 0.408 ms [effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 2470 FrameTime: 0.405 ms [effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 2505 FrameTime: 0.399 ms [pulsar] light=false:quads=5:texture=false: FPS: 2903 FrameTime: 0.345 ms [desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 2326 FrameTime: 0.430 ms [desktop] effect=shadow:windows=4: FPS: 2204 FrameTime: 0.454 ms [buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 623 FrameTime: 1.606 ms [buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 577 FrameTime: 1.736 ms [buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 779 FrameTime: 1.285 ms [ideas] speed=duration: FPS: 1101 FrameTime: 0.909 ms [jellyfish] <default>: FPS: 2429 FrameTime: 0.412 ms [terrain] <default>: FPS: 710 FrameTime: 1.410 ms [shadow] <default>: FPS: 2215 FrameTime: 0.452 ms [refract] <default>: FPS: 1218 FrameTime: 0.821 ms [conditionals] fragment-steps=0:vertex-steps=0: FPS: 2799 FrameTime: 0.357 ms [conditionals] fragment-steps=5:vertex-steps=0: FPS: 2434 FrameTime: 0.411 ms [conditionals] fragment-steps=0:vertex-steps=5: FPS: 2797 FrameTime: 0.358 ms [function] fragment-complexity=low:fragment-steps=5: FPS: 2759 FrameTime: 0.362 ms [function] fragment-complexity=medium:fragment-steps=5: FPS: 2543 FrameTime: 0.393 ms [loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 2677 FrameTime: 0.374 ms [loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 2686 FrameTime: 0.372 ms [loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 2525 FrameTime: 0.396 ms ======================================================= glmark2 Score: 2138 ======================================================= |
While it works, the score (2,138 points) is disappointing as it’s about the same score as on the Raspberry Pi 5 (2,036 points), and Rockchip RK3588 platforms usually get over 4,000 points.
There will be more development here, as Collabora works on the Panfrost driver for the Arm Immortalis-G720 and even showcased a demo on the Orion O6 at Embedded World 2025 using a fully open-source stack. A guest post should be coming soon on CNX Software with more details about the implementation.
VPU (Video Processing Unit) & 4K/8K Video Playback
Based on the CIX P1 (CD8081) specifications, the Orion O6 features a VPU with the following capabilities:
- Video Decoder – Up to 8Kp60 AV1, H.265, H.264, VP9, VP8, H.263, MPEG4, MPEG2
- Video Encoder – Up to 8Kp30 H.265, H.264, VP9, VP8
However, I could not find any instructions to play videos with hardware decoding. Printenv has some variables for Gstreamer:
1 2 3 |
radxa@orion-o6:~$ printenv | grep gstreamer GST_PLUGIN_SCANNER=/usr/share/cix/libexec/gstreamer-1.0/gst-plugin-scanner GST_PLUGIN_PATH_1_0=/usr/share/cix/lib/gstreamer-1.0 |
So I tried to play Big Buck Bunny H.264 1920×1080 @ 60 FPS with gstreamer.
It was smooth and CPU usage was low, which indicates hardware video decoding might be used. I switched to the BBB 3840 x 2160 60 FPS video, and the results were similar:
Here’s the output after I interrupted video playback:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
sh-5.2$ gst-launch-1.0 filesrc location=bbb_sunflower_2160p_60fps_normal.mp4 ! decodebin name=decoder decoder. ! queue ! audioconvert ! audioresample ! pulsesink decoder. ! videoconvert ! xvimagesink Setting pipeline to PAUSED ... (gst-launch-1.0:104352): GStreamer-CRITICAL **: 13:01:30.224: gst_value_collect_int_range: assertion 'collect_values[0].v_int < collect_values[1].v_int' failed (gst-launch-1.0:104352): GStreamer-CRITICAL **: 13:01:30.224: range start is not smaller than end for `GstIntRange' (gst-launch-1.0:104352): GStreamer-CRITICAL **: 13:01:30.224: gst_value_collect_int_range: assertion 'collect_values[0].v_int < collect_values[1].v_int' failed (gst-launch-1.0:104352): GStreamer-CRITICAL **: 13:01:30.224: range start is not smaller than end for `GstIntRange' (gst-launch-1.0:104352): GStreamer-CRITICAL **: 13:01:30.224: gst_value_collect_int_range: assertion 'collect_values[0].v_int < collect_values[1].v_int' failed (gst-launch-1.0:104352): GStreamer-CRITICAL **: 13:01:30.224: range start is not smaller than end for `GstIntRange' Pipeline is PREROLLING ... Redistribute latency... Missing element: AC-3 (ATSC A/52) decoder [DspWrap] Audio Component Ready Redistribute latency... Redistribute latency... Redistribute latency... Redistribute latency...0.0 %) Pipeline is PREROLLED ...0 %) Setting pipeline to PLAYING ... Redistribute latency... New clock: GstPulseSinkClock ^Chandling interrupt. (12.9 %) Interrupt: Stopping pipeline ... Execution ended after 0:01:21.861573484 Setting pipeline to NULL ... Freeing pipeline ... |
I then switched to an 8K LG demo video with 7680×4320 (8K) resolution at 59.94 FPS, and it could play too, but it was not quite smooth, feeling like 10 to 15 FPS. The CPU was not stressed at all, and I got no error message from gstreamer. In my experience, the bottleneck might be in the DPU (Display Processing Unit) while downscaling 8K to 1080p (the display resolution).
YouTube video playback seldom works properly on Arm SBCs at release. But I gave it a try anyway in Chromium
No problem at 1080p24 with just 10 frames dropped at the beginning.
Switching to 2160p24 (4K 24 FPS) was equally smooth.
I was surprised that my last test at 4320p24 (8K @ 24 FPS) was also successful with virtually no frames dropped after more than one minute of video playback.
High-end frame rates may be more challenging, so I switch to a 60 FPS starting at 4K resolution. I had more frames dropped here, but the video was still watchable. Note that software video decoding is likely used here, since CPU0 and CPU5 to CPU11 Cortex-A720 cores all have high CPU usage.
However, 8K 60 FPS was too much to ask and the video was choppy, even stopping at times with a loading icon. YouTube video playback performance is close to some mid-range Intel and AMD mini PCs I’ve tested recently. Not too bad…
NPU / AI accelerator
While so far, I’m not too pleased with the documentation provided for the Orion O6, the company released instructions explaining how to use the CIX P1’s 30 TOPS NPU.
Sadly, downloading the SDK requires an email registration with manual approval from the company.
I was also not sure about the “Download Type(s)” to select, so I went with AI Model Hub and NeuralOne AI SDK. I usually work on reviews on weekends, so I won’t get a reply soon… So I haven’t tried it myself, and I might do a separate post later, but for now, I’ll quickly go through the documentation.
The first step is to install the SDK on an x86 host from the instructions received by email (needed only when compiling the models yourself):
1 2 3 4 |
tar -xvf nor.tag.gz cd noe pip3 install -r requirements.txt pip3 install ./CixBuilder-6.1.2958.1-py3-none-any.whl |
We’ll also need to install the NOE UMD (User Mode Driver) on the Orion O6 itself:
1 |
sudo dpkg -i ./cix-noe-umd_0.01-1_arm64.deb |
Clone the CIX AI Model Hub repository (username/password required):
1 |
git clone https://e.coding.net/g-uaqh1479/ai-model-hub/ai_model_hub.git |
Here’s the directory structure to expect:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
├── datasets ├── models │ ├── Audio │ │ └── Speech_Recognition │ ├── ComputerVision │ │ ├── Face_Detection │ │ ├── Face_Recognition │ │ ├── Image_Classification │ │ ├── Object_Detection │ │ ├── Pose_Estimation │ │ ├── Semantic_Segmentation │ │ └── Super_Resolution │ └── Generative_AI │ ├── LLM │ └── Text_Image_Search └── utils ├── evaluate └── label |
You’ll find pre-trained models for the example above on ModelScope.
Prepare the environment, and run the model on the NPU:
1 2 |
pip3 install -r requirements.txt python3 inference_npu.py |
or on the x86 machine:
1 |
python3 inference_onnx.py |
One example is the ResNet50 model. Here are the commands after installing the SDK and using a pre-compiled model:
1 2 3 |
cd ai_model_hub/models/ComputeVision/Image_Classification/onnx_resnet_v1_50 wget https://modelscope.cn/models/cix/ai_model_hub_24_Q4/resolve/master/models/ComputeVision/Image_Classification/onnx_resnet_v1_50/resnet_v1_50.cix python3 inference_npu.py --images test_data --model_path ./resnet_v1_50.cix |
If you want to see the performance difference, you can run it on the CPU instead:
1 |
python3 inference_onnx.py --images test_data --onnx_path ./resnet50-v1-12-sim.onnx |
Compiling mainline Linux (6.13)
So far, we’ve tested Debian 12 with 6.1.44 on the Orion O6 relying on UEFI firmware. Since the board is advertised as an open-source machine with EDK II bootloader, it should eventually boot any Arm ISO and support mainline Linux like on x86 hardware. Vladimir Smirnov provided mainline Linux instructions for the Orion O6, so I tried with Linux 6.13.8 a few days before Linux 6.14 was released.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
KVER=6.13.8 sudo mkdir -p /boot/efi sudo mount /dev/nvme0n1p1 /boot/efi sudo apt -y install dracut build-essential bison flex libssl-dev firmware-linux firmware-linux-nonfree wget "https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-${KVER}.tar.xz" tar -xf linux-${KVER}.tar.xz pushd linux-${KVER} wget "https://gist.githubusercontent.com/Civil/8bf3259974136b05df9642139b7a60ae/raw/01a17d45a85494483a1f41dfb1243aceaf9937a6/.config" make -j12 sudo make modules_install sudo cp arch/arm64/boot/Image.gz /boot/vmlinuz-${KVER} sudo dracut --force --kver ${KVER} sudo cp arch/arm64/boot/Image.gz /boot/efi/vmlinuz-${KVER} sudo cp /boot/initrd.img-${KVER} /boot/efi/ NUM=$(grep '^set default' /boot/efi/GRUB/GRUB.CFG | cut -d '"' -f 2) NUM=$((NUM+1)) echo -e "\n\nmenuentry '${NUM} Mainline ${KVER}' {\n linux /vmlinuz-${KVER} root=/dev/nvme0n1p2 rootwait rw\n initrd /initrd.img-${KVER}\n}\n" | sudo tee -a /boot/efi/GRUB/GRUB.CFG sudo sed -i 's/default=.*/default="'"${NUM}"'"/;s/timeout=.*/timeout=10/' /boot/efi/GRUB/GRUB.CFG |
However, the system would not boot after a reboot. That’s because this kernel requires ACPI mode. We can change that in the BIOS.
This time around, the Orion O6 boots with Debian 12 + Linux 6.13, but the desktop environment does not show up. I tried again with Linux 6.13.4 – the exact same kernel as used by Vladimir – but the result was the same.
I could still log in through SSH and check the system information:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 |
radxa@orion-o6:~$ sudo inxi -Fc0 System: Host: orion-o6 Kernel: 6.13.8 arch: aarch64 bits: 64 Console: pty pts/1 Distro: Debian GNU/Linux 12 (bookworm) Machine: Type: Unknown Mobo: Radxa (Shenzhen) model: Radxa Orion O6 v: 1.0 serial: N/A UEFI: Radxa (Shenzhen) v: 1.0 date: Jan 1 1980 CPU: Info: 12-core model: N/A bits: 64 type: MCP Speed (MHz): avg: 419 min/max: 800/2600:1800:2300:2200:2500 cores: 1: 518 2: 683 3: 653 4: 648 5: 648 6: 233 7: 251 8: 307 9: 233 10: 257 11: 246 12: 358 Graphics: Message: No PCI device data found. Display: server: X.org v: 1.21.1.7 with: Xwayland v: 22.1.9 driver: X: loaded: fbdev,modesetting gpu: N/A tty: 80x24 API: OpenGL Message: GL data unavailable in console for root. Audio: Message: No device data found. API: ALSA v: k6.13.8 status: kernel-api Network: Device-1: Realtek RTL8126 5GbE driver: r8169 IF: enp1s0 state: down mac: 00:48:54:20:0b:af Device-2: Realtek RTL8126 5GbE driver: r8169 IF: enp49s0 state: up speed: 2500 Mbps duplex: full mac: 00:48:54:20:0b:b0 Device-3: Realtek RTL8852BE PCIe 802.11ax Wireless Network driver: N/A Drives: Local Storage: total: 476.94 GiB used: 20.76 GiB (4.4%) ID-1: /dev/nvme0n1 model: PCIe SSD size: 476.94 GiB Partition: ID-1: / size: 54.57 GiB used: 20.76 GiB (38.0%) fs: ext4 dev: /dev/nvme0n1p2 Swap: Alert: No swap data was found. Sensors: Src: lm-sensors+/sys Message: No sensor data found using /sys/class/hwmon or lm-sensors. Info: Processes: 222 Uptime: 1m Memory: 15.38 GiB used: 630.5 MiB (4.0%) Init: systemd target: graphical (5) Shell: Sudo inxi: 3.3.26 |
All graphics and audio drivers are gone. The wireless module is detected, but the driver is not loaded. The good point is that NVMe SSD and 5GbE networking are working. I thought I might benchmark the system with sbc-bench.sh, but I skipped that part too, due to the high CPU usage at idle with Linux 6.13 due to the dbus-daemon process.
The good news is that it can boot Linux mainline, a feat most Arm boards can’t achieve after launch, but there’s still a lot of work to do, and upstreaming has just started. Mainline Linux on the Orion O6 might be a 2026 story…
Power consumption
Let’s go back to UEFI and Linux 6.1 to measure the power consumption.
- Power off – 3.4 Watts
- Idle
- Server mode – 15.8 -15.9 Watts
- Desktop mode – 16.5 – 16.6 Watts
- YouTube 4K 60 FPS – 23.9 – 25.9 Watts
- Stress test (stress -c 12) – 26.0 – 26.2 Watts
Measurements were done with a wall power meter. The Orion O6 was connected to the HDMI display, a 2.5GbE switch, WiFi 6, and a USB RF dongle for a wireless keyboard and mouse combo. That’s for the “desktop mode” used for most tests, and in “Server mode”, I unplugged the HDMI cable and the USB dongle.
While the power consumption under test and YouTube looks OK compared to x86 machines, the power off and idle power consumption numbers are atrocious. Sadly, it’s not a problem with my setup, and others have reported similarly high numbers. Let’s assume you leave the machine on for 365 days straight; that would be about 140 kWh per year at idle, considering 16 Watts. I pay around 12 cents per kWh, so that would be $16.8 per year. That’s not ideal, but probably manageable, but if your electricity costs are higher, that could make the machine a poor value over time (TCO) compared to an x86 motherboard.
I shot a video with a thermal camera to spot locations with high temperatures.
That could be a starting point for optimization, but I don’t see any really hot part, but instead, multiple components are slightly warm all around the board. It’s unclear whether a software/firmware fix is possible, or whether the high power consumption requires the board to be redesigned, or worse, the SoC itself needs a new revision.
Conclusion
Radxa Orion O6 mini-ITX motherboard has plenty of potential, and as things stand, it’s about twice as fast as RK3588 platforms and three times faster than Raspberry Pi 5/CM5 on multi-core workloads like 7-zip. It also features a PCIe x16 slot (PCIe Gen4 x8 signals), 5GbE ports, M.2 sockets for storage and wireless, support for four video outputs, a few USB ports, and the ability to get power from a USB-C PD adapter or an ATX power supply.
However, “potential” is the keyword here, as most people should avoid purchasing the Orion O6, and I view it mostly as a development kit. Here’s the summary of what works and what doesn’t with the provided Debian 12:
Feature | Remark |
---|---|
Storage | NVME OK with good performance |
Video Output | HDMI - OK DisplayPort - Not working for me 2x USB-C with DP - OK, but not when using USB PD at the same time eDP - Not tested |
PCIe | Tested with GeForce GT210 graphics card. HDMI output works, but there's a bug with the desktop environment that prevents normal usage |
Networking | 5GbE OK with great performance WiFi 6 OK with about to 890 Mbps |
Bluetooth | OK |
USB | USB 3.0 Type-A ports - OK USB 2.0 Type-A ports - OK with HID devices, but issue with USD HDD when running iozone3 USB Type-C ports - USB PD OK, USB-C DP Alt OK. Failed to work with NVMe enclosures, failed with video output when USB PD and DP Alt mode are used as the same time |
GPIO | OK, tested with sysfs (documentation lacking for pin assignment) |
GPU | 3D graphics acceleration working, but glmark2-es2-wayland performance is on the low side |
Video Playback | Hardware video decoder looks to be working with Gstreamer (TBC). YouTube works well with software decoding up to 8K24 or 4K60. |
NPU | Documentation is here, but requires email registration and manual approval to access the SDK. Not tested yet. |
With an excellent price/performance ratio and the promise of open source firmware and software, many people may have been under the impression that it could serve as an x86 motherboard, but it’s clear not the case, as there’s still a lot more to do on the software front.
We also have to talk about power consumption, because at 16-17 Watts idle, most people will be better served with an x86 mini-ITX motherboard that may consume 5 to 10 Watts at idle, and everything mostly working out of the box. Radxa and CIX also made other promises, like a 2.8 GHz CPU and 100+ MB/s memory bandwidth, none of which are currently achieved since they are theoretical and not achieved. You can check the thread on Jeff Geerling’s SBC-Review GitHub repo with many disappointed early users with regards to both software support and hardware features. This led Radxa to issue a statement:
Currently, the DRAM runs at 6000MT/s (~96GB/s) . The hardware design simulations indicate that achieving 6400MT/s (>100GB/s) is feasible; however, rigorous validation and software optimization are still required to ensure system stability and performance. This is why we’ve temporarily updated the product specifications to reflect the current stable bandwidth. Once the validation process is complete and stable firmware/software enabling 6400MT/s is available, we will update the specifications accordingly.
…
The CPU cores are designed to run at up to 2.8GHz, and internal tests indicate stable operation at this frequency under typical workloads. However, Cix has adopted a more conservative approach for now, officially listing the maximum clock frequency at 2.6GHz , to guarantee stability across various scenarios and workloads. We understand users desire the maximum potential from the hardware, and we’ll actively communicate with Cix about enabling stable higher clock rates through future firmware updates
The statement also includes parts related to the companies’ open-source software commitment:
We have regular bi-weekly open-source status meetings between Radxa and Cix, specifically addressing community-reported issues and continuously improving both hardware and software experiences.
…
Additionally, Cix is a sponsor of the upcoming Linaro Connect 2025 event, “Boosting the Next Wave of Arm Innovation,” taking place from 14-16 May 2025 in Lisbon, Portugal . Radxa will also be sending engineers to participate. If you’re attending, this would be a great opportunity to engage directly with engineers from both Radxa and Cix in person.
The company is also offering returns to dissatisfied customers and a full refund with shipping costs.
I’d like to thank Radxa for the opportunity to test/review the Orion O6 Armv9 mini-ITX motherboard. While I’m confident most issues reported in this preview can be fixed with firmware/software updates over time, I’m less so with the high power consumption issue, which may or may not require hardware changes. So you may want to wait for clarification if you are interested in the board and this is a critical issue. For reference, the Orion O6 model with 16GB RAM reviewed here is currently sold for $252 on Arace or AllNetChina.

Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress