I’ve been playing a bit with the CPU frequencies on my Orion O6. It’s not very difficult, but not trivial, and some of the last updates result in your settings to be completely ignored, so I forked everything into a new repo here: https://github.com/wtarreau/orion-o6-edk2-cix.
This is essentially the repositories from Radxa with a few adjustments. The most important one is a revert of CIX’s bootloader1.img file from:
21:22:18, Mar 11 2025.v2.7-39211b3b31af.v2.7(debug):Beta_2.0.3_release to version:
20:52:39, Feb 7 2025.v2.7-7b96441eb23e.v2.7(debug):Beta_2.0.3_release
And the related changes from pm_config v2.6 to v2.1. I could verify that the new bootloader doesn’t understand any of the settings of either pm_config version, while the older bootloader understands the settings from the older version.
The process updates to 2.6 GHz for the big cores and 2.4 for the med ones. However I’ve had my first board work fine with the two big clusters at 3.0 and my new board has one big cluster at 3.0 and the second one at 2.7, and the two med clusters at 2.6.
On my current board, the big0 cluster doesn’t work reliably at 2.8 GHz whatever the voltage, so I agree with Radxa mentioning that 2.8 cannot be sustained. on both. However this one is the smallest of the big clusters. In fact the SoC really has 5 clusters, 4 dual-A720 and 1 quad-A520. Maybe due to power delivery or other reasons there are different characteristics for all these clusters. In each of them the voltages can be slightly different for the same frequency.
Overall there’s more gain to expect by upping the med clusters than the big ones, though for certain tasks, having a few powerful cores can be nice. Maybe we’ll find that 2x2.7 + 2x2.5 works fine everywhere, which delivers the same total performance as the initially expected 2x2.8 + 2x2.4.
Right now I’m happy with the following on my current board, which is 15% faster than the stock settings:
CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE MAXMHZ MINMHZ MHZ
0 0 0 0 0:0:0:0 yes 3000.0000 800.0000 1819.3350
1 0 0 0 1:1:0 yes 1800.0000 799.0000 1531.1200
2 0 0 1 2:2:0 yes 1800.0000 799.0000 1531.1200
3 0 0 2 3:3:0 yes 1800.0000 799.0000 1531.1200
4 0 0 3 4:4:0 yes 1800.0000 799.0000 1531.1200
5 0 0 0 5:5:0:0 yes 2600.0000 800.0000 1146.1100
6 0 0 1 6:6:0:0 yes 2600.0000 800.0000 1146.1100
7 0 0 2 7:7:0:0 yes 2600.0000 800.0000 1620.9690
8 0 0 3 8:8:0:0 yes 2600.0000 800.0000 1620.9690
9 0 0 4 9:9:0:0 yes 2700.0000 800.0000 1530.2930
10 0 0 5 10:10:0:0 yes 2700.0000 800.0000 1530.2930
11 0 0 6 11:11:0:0 yes 3000.0000 800.0000 1819.3350
I could also experiment with the CI700 frequency on the first board, showing that it was the limiting factor for the CPU<->DRAM bandwidth. Increasing it a bit allows the BW to jump from 40.3 to 47.5 GB/s, but on my current board it’s not stable to change it even a little bit. The DSU (includes the L3 cache unit) can also be adjusted though with less gains. I have not tried GPU settings since I’m not using it.
The build system continues to rely just on the simple makefile and should work basically everywhere without having to install fancy environments (tested both on Ubuntu 22.04 and Slackware 15.0).
The OPP are simply stored into a 4kB section on the flash. I thought it could be interesting to modify the tool to help edit them without having to reflash everything, but I have not found how to flash only one part of an image with the flashupdate.efi utility, and the NOR is not exposed to Linux. Also, the recently published image v9.0 doesn’t have anything in its section (tagged “PMCF” in the image). So I suspect that this pm_config stuff is going away, thus I have not invested more time on this part.