Orion O6 Debug Party Invitation

hrw · March 19, 2025, 7:14am

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.

wilsonyan · March 19, 2025, 7:43am

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 ?

tkaiser · March 19, 2025, 9:34am

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:

washley · March 19, 2025, 12:01pm

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.

washley · March 19, 2025, 1:46pm

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.

tkaiser · March 19, 2025, 2:04pm

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.

tkaiser · March 19, 2025, 10:00pm

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?

cutterjohn · March 19, 2025, 11:57pm

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

wilsonyan · March 20, 2025, 2:19am

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.

hrw · March 20, 2025, 9:17am

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.

willy · March 20, 2025, 9:34am

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

willy · March 20, 2025, 9:42am

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.

tkaiser · March 21, 2025, 11:50pm

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.

meco · March 22, 2025, 12:03am

Discord still stands as an easier/casual messaging and discussion place. Meanwhile threads on a forum are more on topic and make sense differently

willy · March 22, 2025, 4:42am

Discord still stands as an easier/casual messaging and discussion place

Well, that’s just like a corridor full of people telling their lives at the same time as if they were at a party. Nothing good can emerge from this, and even if someone was caught saying something smart, it wouldn’t be indexed nor archived so nobody could find it when searching for it. Discord is just a closed social network full of morons.

rev · March 22, 2025, 2:02pm

I got mine via undervolting to 17W idle COMPLETE SYSTEM power usage. And that is x86 from AMD. I expected / hoped better from the CIX ARM.

And I agree very much, that discord is hell when it comes to their TOS rules, privacy rules and general search-ability of content that could be important. And it is impossible to make anything discord does “privacy friendly” with 3rd party. Its as closed as can be, and I concur that it is a mistake from Radxa to discuss (marketing) a “open source” product in a closed source platform where information just is not accessible to search engines and most privacy-conscious users. Might as well use X (ex twitter) for that in the recent political climate. Baad idea!

cutterjohn · March 22, 2025, 6:56pm

On more modern zen, i.e. WITH IODIE, have an IDLE power floor of c. 20W. Apparently not all of it can be power gated. Which is why Intel generally slaughters them in IDLE power draw.

The APUs, i.e. generally w/iGPU are monolithic designs, and so do not have this ‘problem’.

Hopefully AMD will address the IODIE in the next design.

Bits of this are probably not accurate or as accurately reprexsented as it has been some time since I looked into this, and did not check original research again, other that I was disappointed that zen5 still had high IDLE power draw.

willy · March 23, 2025, 4:23am

Interesting. My suspicion till now was that since they’re essentially focusing on what matters for their marketing, i.e. maximum gaming performance, they absolutely don’t care about idle consumption. I’ll see what they have to offer once the 395+ are out, because for such edge devices idle should count quite a bit.

Mario · March 23, 2025, 7:24pm

Turns out that CPU clocks can actually be increased by modifying the OPP tables in firmware - they are not hardcoded as I initially thought. Here’s a rough guide:

Clone the edk2, edk2-platforms and edk2-non-osi repositories from https://github.com/radxa and follow the build instructions in edk2-non-osi/Platform/CIX/Sky1/Readme.md
Copy edk2-non-osi/Platform/CIX/Sky1/PackageTool/pm_config/ to edk2-platforms/Platform/Radxa/Orion/O6/pm_config/
Open opp_config_custom.h inside the copied pm_config directory
Set #define PM_OPP_TABLE_CONFIG 1
Tweak the frequency and voltage levels in the defined OPP tables (at your own risk!)
- dxs_lit - little cluster
- dxs_gb0 - big cluster 0
- dxs_gb1 - big cluster 1
- dxs_gm0 - medium cluster 0
- dxs_gm1 - medium cluster 1
Rebuild and flash the generated firmware

Here’s a GB6 run with the big clusters set to 2.8, medium to 2.4 and little to 1.8 GHz:

Radxa Computer (Shenzhen) Co., Ltd. Radxa Orion O6 - Geekbench

Mario · March 23, 2025, 8:07pm

While playing with the firmware, I also noticed that there’s support for the fastboot protocol:

You will need to have an NVME drive plugged in (we won’t be writing anything to it), otherwise the fastboot app will refuse to load.
Open your build_and_package.sh:
- add local FASTBOOT_LOAD=nvme
- append -D TOKEN_SETUP_SUPPORT=TRUE to the EDK2 build command
Build and flash the generated firmware as usual.
There will appear a new setup menu: CIX System Manager. Open it, then go to Soc Configuration->USB Configuration and switch USBC DRD Controller Role to Device. Save the changes.
While rebooting/powering the board, short the “BOOT” pins near the UART debug headers. This will cause the firmware to enter fastboot mode after the boot countdown:
```
Fastboot: Initializing...
Fastboot: Initializing done
```
Once you see the initialization message, connect the board to another computer via the port labelled “USBC0”.
Download and extract the Android SDK Platform Tools.
From now on, you can update the firmware by simply running fastboot flash bootloader PATH_TO_FW.bin in a terminal / command prompt.
Reboot the board (fastboot reboot).

To further speed up testing, it’s possible to flash individual parts of the firmware image.

In the case above where we modified the OPP tables, it was only necessary to update csu_pm_config.bin.

edk2-non-osi/Platform/CIX/Sky1/PackageTool/spi_flash_config_ota.json contains a single entry for the EDK2 BL33 image (bootloader3.img). Replace it with the definition for csu_pm_config.bin taken from spi_flash_config_all.json.

Build the firmware, then flash cix_flash_ota.bin instead of cix_flash_all.bin.