I totally agree that it would be awesome if it was lower but I disagree that its ‘collecting dust’ level. This soc is actually very reliable with the i/o, the usb works well, 4 x 10g ports
Here is a pic for the hell of it, I replaced the cooler with the next step up, probably not worth it, and I put it in a small mini-itx case, it’s too small for the back plate to go in but still pretty happy for what I paid.
This always depends on Your expectation and reality,
If You plan to replace Your current setup, let’s say Rock 5B, and idle power consumption is 7x higher (1.5W vs 10W) then You may just hold off for some time (dust…). I perfectly understand @tkaiser, maybe he needs it for some service, running 24/7, maybe NAS? and maybe his electric bill is way to high in his area.
Gamer will see it differently, desktop user too.
Nope, I want to review this thing. But not in this state since the software side of things is not ready and especially idle consumption is laughable. And since I fear the board gets fried it will collect dust until a firmware fix is released.
I can’t remember when it was that I used my daily driver with an idle consumption that high… maybe 2 decades ago still on PowerPC?
Just remembered that I’ve another Intel thingy lying around. A five years old MacBook Pro relying on a Core i7-9750H (6 cores, 12 threads) which was my main desktop half a decade ago (replaced by a M1 Pro and since a year the slowest Apple M3 available since ‘way too fast for me’).
Powered it on with exactly same 96W power brick as the O6 was measured with, waited until the battery was fully charged, turned the backlight off and looked at idle consumption: 3W in idle.
macbookpro-tk:~ tk$ pmset -g ps
Now drawing from 'AC Power'
-InternalBattery-0 (id=6357091) 100%; charged; 0:00 remaining present: true
macbookpro-tk:~ tk$ pmset -g ac
Wattage = 60W
Current = 3000mA
Voltage = 20000mV
AdapterID = 28674
Manufacturer = Apple Inc.
Family Code = 0xe000400a
Serial String = C4H218305PJPM0WAP
Adapter Name = 96W USB-C Power Adapter
Hardware Version = 1.0
Firmware Version = 01080053
macbookpro-tk:~ tk$ system_profiler -detailLevel mini SPHardwareDataType
Hardware:
Hardware Overview:
Model Name: MacBook Pro
Model Identifier: MacBookPro16,1
Processor Name: 6-Core Intel Core i7
Processor Speed: 2,6 GHz
Number of Processors: 1
Total Number of Cores: 6
L2 Cache (per Core): 256 KB
L3 Cache: 12 MB
Hyper-Threading Technology: Enabled
Memory: 16 GB
System Firmware Version: 2069.80.3.0.0 (iBridge: 22.16.13034.5.1,0)
OS Loader Version: 577.140.2~30
That thing has 4 Thunderbolt3 ports (up to 40 Gpbs) and adding to the integrated GPU an additional Radeon Pro 5300M (no idea about the performance since for me it’s ‘fast enough’ since decades).
3W in idle measured with the same power brick as powering my O6. All the babbling about ‘desktop class ARM CPU needs to consume moar’ is such an insane BS since wasting energy is a task for morons.
Stuff like power management has been invented decades ago and there exists absolutely no reason why something equipped with plenty of PCIe lanes should consume lots of power when nothing is connected. What those ‘gamers’ might oversee is their stupid PC setups wasting hundreds watts of energy always needing a beefy ATX PSU that is insanely inefficient at low-load scenarios so those ‘20W in idle’ are mostly caused by an overkill PSU.
O6 will be collecting further dust until a firmware fix is available… I don’t want to fry this nice board.
All PCIe devices come up with ASPM disabled (LnkCtl: ASPM Disabled). This might be an area for improvement on the power front.
Totally agree it would be awesome if it gets lower.
As far as x86 pcs go, it seems like idle power is the first thing they sacrifice. I don’t remember my Ryzen 7800 x3d having a minimum frequency of 3ghz when I first bought it, but somehow now it does. Not sure if it has to do with vulnerabilities found or if it’s just me or what. If it is something they’ve done i’m certainly not exactly happy about it because it tends to kill off the uses it might have later on as well.
Ryzens are absolutely horrible in terms of idle consumption. We’ve tested two at work (7700 and 7800x3d) and they were hot in idle. And from the rare reviews online that measure idle, it looks like 9800 is even worse than 7800. That’s the main reason I’m still hesitating to replace my aging skylake with a ryzen, because the ryzen in idle consumes as much as my skylake when compiling… And my PC is on 24x7 so for me idle is the most important (especially since I don’t want to hear any fan in my office).
As I wrote elsewhere:
Hardware feels like easy part as SoC vendors often have some reference designs.
I wonder is Radxa capable of managing software/firmware side of this board. Cixtech did basic BSP so SBC can be used but their plans look like “be patient, we plan to plan upstreaming”.
ACPI mode needs firmware improvements, 23MB of blobs scare potential contributors away.
Do not wait to 2026 with review. Fw/sw side may get better at some point but is it granted to happen “soon”? No.
Cix plans to work on edk2 upstreaming in Q3. Will it mean opening blobs? No idea.
Kernel side did not even started as Cix only sent basic DT which is not merged yet.
I’m not expert on this stuff by a long way, like I said though as far as headless operation goes for cpu / io I think it’s good to go really, it’s completely usable if you know the basics of getting linux booting and compiling a kernel.
So in my opinion the next step if they can would be to get the gpu working with the latest kernels. It seems like someone has already been working on mesa and the kernel side but for the kernel side it’s only for 6.1 still.
How does it work to get the bios to present it ? Does there need to be u-boot + dts instead of ACPI ?
If you refer to an sbc-bench report then this is intended behaviour but actually after a reboot it looks like this:
sh-5.2# lspci -vv 2>/dev/null | grep -A1 'LnkCtl:'
LnkCtl: ASPM L1 Enabled; RCB 64 bytes, Disabled- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
--
LnkCtl: ASPM L1 Enabled; RCB 64 bytes, Disabled- CommClk-
ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
--
LnkCtl: ASPM L1 Enabled; RCB 64 bytes, Disabled- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
--
LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes, Disabled- CommClk-
ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
--
LnkCtl: ASPM L1 Enabled; RCB 64 bytes, Disabled- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
--
LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes, Disabled- CommClk-
ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
--
LnkCtl: ASPM L1 Enabled; RCB 64 bytes, Disabled- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
--
LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes, Disabled- CommClk-
ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
Usually setting /sys/module/pcie_aspm/parameters/policy to performance increases consumption but not with O6! With pcie_aspm set to performance I get 17.1W, with powersave we’re at 18.7W (with 3 RTL8126 NICs and all CPU cores at their max frequencies since the BSP kernel hasn’t been built with powersave cpufreq governor).
At the current state of affairs the best thing you can do with an O6 is shutdown -h now 
But you need to remember that you also unplug the power cord since even when ‘powered off’ it will continue to cook itself:
Interesting. I get ASPM disabled all the time, at least with the Fedora image.
Setting the policy to powersave really borks the system. The command itself took a while to return, and then doing lspci locked up. It’s still pingable, but ssh hangs during authentication. My guess is that powersave mode breaks ethernet, probably preventing interrupts so stalling connections.
Does anyone know where to find the kernel-devel rpm for the fedora image? Installing it with ‘dnf’ wants to install the regular upstream rpm (6.13.7-200.fc41), not the one for the actually-installed (6.1.44-cix-build-generic) kernel.
Up the directory structure of where the image is hosted is 6.1.44.tar.gz, but that only contains dtbs, the kernel, and kernel module binaries.
As already explained those big PC boxes designed to waste hundreds of watts need to be powered by an ATX PSU that all perform very poorly in low-load situations.
Here some guy tested out 4 different ATX PSUs with the very same setup (same mainboard, same CPU, same DDR4 stick, same SSDs) and measured with those four different PSUs 21W, 26W, 29W and 34W ‘idle consumption’ at wall.
That’s 13W ‘idle consumption’ difference by PSU choice for the sole reason ATX PSUs designed for +500W performing crappy below 50W. Interestingly the PSU that stopped its internal fan below 200W was not even the most efficient. And with a properly chosen picoPSU the same setup might run below 10W in idle.
Tom, are you aware that this is just a sad joke?
None of the many questions asked here has been answered. Radxa team may be busy but why starting to sell this thing since it will get really worse if consumers start to compare marketing BS with what they bought?
When will you release a firmware update fixing idle consumption?
ARM is no different so go home with this this calculated incitement commentary please… ALL CPUs OPTIMIZE for IDLE power FFS! That’s HOW they get their ‘good’ poower numbers JFC!
hell with it Im tired and haven’t had the time to read all the power posts since the other day, but I stand by the above post, very damned CPU mfg optimizes foior idle power!
then again we have idiots,
hello hrw having a good time trolling tonight? as you need to go home or buy one of these boards IMNHO. o.w. FOAD
I’m only going to respond to this incase anyone actually believes it. I’m not trolling. As far as i’m aware I made a technical argument and stated a truth about a change in a product I bought. I’m, not sure what you think is going on here, but i’m just posting in a thread about a product I bought and what I think about it. I like this stuff, I like talking about it i’m not sure how actually having the product, proving it and testing it and engaging in conversation is trolling. Of course, others are free to perceive what they wish, but i’m not sure why I’ve been singled out for this projected attack, particularly at a time like this where there’s a lot of other things or people you could be an insane person about.
There is some price limit above which I am checking product before buying. Both @tkaiser and @geerlingguy have boards and both are known for doing good reviews.
And both wait with making such for Orion because at current state both firmware and software are in “not public ready” state.
I am aware that my posts bring lot of bad feelings for people like you. I understand, you spent €€ on hardware, you try to use it and may get frustrated with current state of it (I would).
At same time we got cpu information as I asked @willy to run ArmCpuInfo tool which I maintain. Other board owner ran BSA ACS for me. I looked at ACPI tables and reported issues in Radxa EDK2 repo. When Peter Chen from Cixtech sent their first CD8180 related patch to Linux kernel I commented about DeviceTree he sent and he applied my comments in next revisions.
I left Radxa Discord space cause it was full of discussions going nowhere. Here situation is a bit better.
Still, I think that Radxa should work on updating Orion C6 product page to show real state of this SBC.
When you don’t understand people’s attacks nor insults, just consider that it’s their cultural way of saying “hello” and pass along, you’ll have a better day 
I do like the product, but in its current software state it’s inferior than advertised and not necessarily worth the price. With that said, it’s still much more powerful than many other arm-based devices around in the same price range, but for the price you’ll get much more powerful x86 devices.
The point is: buying it now is a bet on a better future software-wise. If you’re waiting for a really nice Arm machine and are not in a hurry, it should become really great later, so why not buy it now and benefit from it right now. This is why I already bought another one. If you’re just looking for a cheap and powerful board in a hurry, just take an x86. But as a pure development machine, its currently limitations are tolerable for me. If I never see fixes for the idle power, CPU frequency & ordering, nor DRAM speed, well, then I’ll think it will have been not so good a choice. But it’s just a bet that for now I’m willing to take.
I really don’t understand why Radxa is repeating this mistake again. Discord is closed crap.
Everyone reading their terms of service (no-one?) knows that they’re hosted in the US, sell or share your data to whomever (at least the agencies) and at least need to comply to US legizlation.
Especially entities in China must be horribly stupid to rely on this ‘infrastructure’ since the USA is on (trade) war against China. All your precious content on Discord not backed up anywhere else is about to vanish with the next executive order Trump signs.
Discord still stands as an easier/casual messaging and discussion place. Meanwhile threads on a forum are more on topic and make sense differently
