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
On a diiferent Linux site it can be found Mesa merge request was submitted march 12th (Guiilemart) and a v2 patch for the kernel gpu initialization was submitted march 20th (Kazunika).
So I would expect support for the G720 “soon”. (Meaning without a 3 year delay like with the G610, still we are probably talking about the 2nd half of 2025 at the earliest.)
Yes, that’s Collabore work. There should be a guest post here soon.
The fact that the G720 was able to gain support quickly is basically based on the efforts made on the G610. So if RK3588 doesn’t use G610, G720 will also have to wait long enough to get support.
By adding the ID’s of many gpu’s to Collabora’s patches they made quite a headstart, it seems.
“ODROID O6 SBC benchmarks on Debian 12 …” ? Probably “ORION O6”, right?
Does it indicate the is something new from Odroid is in the queue? 🙂
Technically the O6 is an SBC… just a rather large one. Since the SoC and RAM are all soldered onto the board it’s just an ITX sized SBC 🙂
The problem is that I first wrote “ODROID” (as a board from hardkernel) instead of “Orion”. 😉
I don’t know what will be the use case for this, as there are Ryzen 6000 mini pc’s in the 250-300€ league that literaly obliterate this board performance wise (and they come with NMVe already). And if you want it solely for the NPU, get a Ryzen 7000 for 100€ more and enjoy a beast mini pc for virtually everything. Ahhh, and you get them working out of the box.
A few years ago SBC made sense because they were very small cute things with very attractive price for simple projects but now they are more like PC’s, as expensive as PC’s (or even more) and without the software support, so kind of useless. If you add this monstruous size, I really don’t understand the point of anything.
The only SBC that make sense (and only sometimes) are the low cost low power ones. Let’s see if in the future it won’t get even worse 🙁
actually this one is more of a small Arm-based PC than an SBC. I value it as a development platform on which I can build. SBCs are not suitable for such use cases, but are suitable to many other ones (low power etc). Previously a nice dev board was the LX2 from SolidRun with 16 A72 cores at 2.2 GHz. Here we’re on another level, the board is about twice as fast, supports modern atomics and plenty of Arm extensions, and has a bit faster memory for 1/4 of the price of the former (though it has less I/O).
I don’t want a Ryzen, or any x86. I want an ARM workstation with good power and expandability. Or better yet, RISC-V, but those are still a bit behind ARM so far it seem.
Good luck. At least this kind of Arm dev boards have always sucked compared to x86 alternatives in pretty much every way. Poor efficiency (wasn’t that the whole point of Arm?), poor performance, poor I/O compliance (Arm world never gets PCIe right – even the expensive Ampere options), really poor software support that only manages to improve *years* after release when the board is already outdated.
RISC-V might be worth mentioning once they get out of the RPi 3 era of performance.
I disagree with you. This board allowed me to deliver 70 Gbps of HTTP traffic using a 100G intel NIC connected into its slot. And generally speaking it’s delivering about 85% of the performance of my quad-core Skylake at 4.4 GHz in builds, asymmetric crypto and such stuff. Honestly it’s really not bad. It’s still suffering from some annoyances like a limited number of settings in the BIOS, the CPU ordering and still a bunch non-mainlined drivers. But it’s among the best ones we’ve had in a while, both in terms of performance and software support at release date.
Regarding Ampere, I’ve had lots of trouble dealing with a horribly bogus BIOS that took me a while to get the machine to boot, then to keep its frequency after boot (as it would sometimes switch to 1 GHz and never back). However, it’s delivering up to expectations, swallows 100G without a sweat, runs LLMs like crazy and maxes out the DRAM memory bandwidth. Let’s not consider that everything is an RPi or a Banana.
What points do you disagree with more exactly?
Skylake is decade old hardware at this point. The O6 efficiency leaves a lot to be desired for the level of performance that you find in phones nowadays. Not to mention long-standing firmware issues + usual Radxa (and SoC vendor)’s level of close to no support.
4 months have passed since O6 started selling and it still doesn’t have even the most bare-minimum device tree merged into mainline Linux. So yes – it very much takes *years* before these boards get close to the software support that you get on day 1 with x86 boards.
> What points do you disagree with more exactly?
The points regarding “poor performance, poor I/O compliance, Ampere doesn’t get PCIe right” etc.
> Skylake is decade old hardware at this point.
Can you cite an x86 design that has significantly evolved in terms of IPC since then ? Long gone are the days where performance was increasing by two digits every two years. Most designs have just improved power efficiency to add more cores, increased frequencies a bit, and added new features. My old 6th gen skylake remains twice as fast as my laptop’s 8th gen with the same number of cores for example. I’ve even compared it with a Sapphire Rapids Xeon W3 wih quad-channel DDR5-4800 (my PC has dual-channel DDR4-2400), and the xeon cores are less than 30% faster on compilation (54.8s vs 1m18), that’s not much for 9 years of evolution, especially when you factor in the 4x RAM bandwidth which generally is the limiting factor for this task!
> for the level of performance that you find in phones
Phones at 250 EUR provide you with 8 A720 cores, 16 GB of 128b RAM and 252 Gbps of PCIe bandwidth ? Because if you want to go down that route, we can also compare it to Apple’s M2/M3/M4 which are waaaaayy better in terms of everything, but at a different price.
> 4 months have passed since O6 started selling and it still doesn’t have even the most bare-minimum device tree merged into mainline Linux.
Sure but it’s in progress and stuck with the usual process: https://lore.kernel.org/lkml/Z-Ua7MK-Kv033uDu@nchen-desktop/
Also this board is one of the very first SBC (even if not the first) that boots mainline out of the factory when configured in ACPI mode. The last one that offered this to me was SolidRun’s LX2 and it’s not in the same price tag nor size. It’s also more difficult to cool due to its form factor (requires a southbridge heatsink and fan either making a lot of noise or taking a lot of space).
Mine is currently running above specs so I’m keeping hopes for default higher frequencies:
It does actually run stable over many builds, and with heavily parallel memtester instances. It reaches 33W at peak under such tests.
The DRAM performance limitation I reported is in fact caused by the CI700 coherent interconnect inside, which is clocked at 1.5 GHz. At 1.8 GHz the DRAM performance increases by ~17% but I noticed instabilities. At 1.6 it’s stable and an integer divisor of DRAM speed. There’s also the DSU (dynamiq shared unit) which comprises the L3 cache and some I/O that’s running at 1.3 GHz, and also runs fine at 1.6 with a small performance boost. All this to say that I’m quite confident that the spec numbers will eventually be revised.
I’ve noticed something strange, in ACPI mine crashes at boot now (BSP kernel complains about speed setting for a serial port, and mainline hangs while printing some very late boot messages). I’m not seeing anything in my local changes that could explain this (opp only). I’m still investigating.
There has been some (IMHO) unfair complaints about this product, which is more related to Radxa’s long silence and too late comunication on the pending issues. I consider that this device is very good even with its current limitations. For example a test on OpenSSL RSA (very cpu intensive) delivered 85% of my skylake’s 4.4 GHz performance for about 1/3 of its TDP, and it could made pretty good small desktops and servers. It’s just that the purpose of the “debug party” is still obscure to me as I’m not very sure whether or not reports are useful to fix issues since due to the limited communications those are more complaints now. While the DRAM speed issue has been investigated a bit on the Radxa side, the long-reported CPU ordering issue doesn’t seem to get any traction beyond “why do you find this annoying?”, and at least the situation with the CPU frequency and DRAM frequency was explained. I continue to think they should leave these settings accessible to the user in the BIOS like in the PC world. It would make everyone happy, stop the complaints, bring them faster stability reports and improve the product’s value.
I think that for now, inexperienced developers might feel a bit of frustration if they have to install it themselves, and they’d rather wait a few weeks for next updates, or get help from a more advanced user to set it up optimally for their needs. However once properly installed / tuned, they’ll probably be happy if they’re targetting use cases that rely on the well working parts mentioned above. The fan can be adjusted to a speed where it’s bearable even for me, but only when using the BSP kernel. That’s still something to keep in mind as well.
Please use “Radxa Debian 12 image” form rather than “Debian 12”. Or some other way to show that you use Debian 12 based userspace with 6.1.44 vendor kernel.
There are people would like to run plain Debian 12 rather than vendor provider image/kernel.
My Ryzen 3300u is running a stock Debian Bookworn.and has a 6.1.0-32 kernel 😉
But I agree that Radxa advertising and com could have been more explicit. Something A la Pinebook: “If you do not expect blood, sweat and tears, don’t buy this”, “specs may be changed without notice” or so.
Thank you Jean Luc for the excellent in depth review. I consider it very positively in its globality:
Sure, but your Ryzen system runs the official Debian kernel, not “vendor BSP” kernel.
And you can run the 6.12.12 Debian kernel from bookworm-backports as well (should work on Orion C6).
I beg to differ. The full score means exactly nothing, as it shows the compositor/DE performance. The only meaningful thing it has it the “terrain” test. Now, if we look just at that, we’ll see:
Pi 5 – 72fps;
RK3588 – 306fps (and, btw, on Collabora driver you’ll see about 120-140fps);
Orion O6 – 710fps.
In other words, according to your benchmarks, G720 is a beast and a half, about 10x faster that Pi 5. Not disappointing at all.