Edk2 bios for allowing overclocking, undervolting and TDP control

Orion Series
1

Hey everyone, I’ve been working on a custom edk2 UEFI BIOS for the Orion O6 (not supporting O6N currently) that lets you adjust CPU, GPU, DSU, NPU, and other frequencies and voltages directly from the BIOS settings menu — no recompilation needed.

What it does:

  • Tune frequency and voltage for 11 DVFS domains (CPU Little/Mid/Big, GPU Core/Top, DSU, NPU, VPU, MMHUB) from
    the BIOS Power Management menu
  • Adjust per-rail TDP power caps (CPU, GPU, DSU, SOC)
  • Change DDR frequency (DDR5-1600 through DDR5-6400) from BIOS
  • Changes are patched to SPI flash and applied on the next cold boot — no rebuild required
  • 16 thermal zones exposed to Linux (stock only exposes 5) — all CPU clusters, GPU, NPU, VPU, DDR, and board sensors
  • Full CPU cache topology (PPTT) so Linux reports correct L1/L2/L3 cache sizes
  • DSU performance counters available via perf
  • Native PCIe AER and PME support
  • SMMU hardware dirty/access bit tracking fixed
  • Support for all known board revisions including newer RAM types (Hive Semi, Hynix, Rayson)
  • Many other ACPI fixes — see the full changelog in the README

:new_button: V2.1 Update

Safe overclocking — no more bricking from bad settings (mostly):

The biggest change in V2.1 is the addition of a hidden safe sustained OPP entry for every domain. The system now always boots at a known-stable frequency (800 MHz for CPU, 250 MHz for GPU, etc.) regardless of what values you have set in the BIOS. If you set an unstable frequency that crashes Linux, just reboot — you will always get back to the BIOS settings where you can
fix the values. You no longer need an external SPI programmer to recover from bad CPU, GPU, or most other OPP settings.

:warning: DSU exception: The DSU is the one domain where this safety net does not work. The SCP firmware always boots the DSU at its highest configured OPP entry, ignoring the safe sustained setting. If you set an unstable maximum DSU frequency, the board will not boot and you will need an external SPI flash programmer to recover. The stock DSU maximum of 1300 MHz is tested and stable — do not increase it unless you know what you are doing.

Other V2.1 changes:

  • AMD GOP driver updated from v1.68 to v2.10 — supports newer AMD GPUs
  • Ext4 driver updated — 3+ years of upstream bug fixes from tianocore mainline
  • USB VBUS power cycling on Linux reboot — USB devices now properly re-enumerate after a Linux-initiated reboot
  • Hardware Information improvements — split CPU speed into Max and Sustained frequency, added domain frequency display for
    all DVFS domains, expanded memory chip identification to all known board revisions
  • Frequency display accuracy — fixed rounding errors so frequencies in the BIOS and reported to Linux match the values you
    set (e.g. 2800 MHz displays as 2800, not 2801)
  • ACPI as default boot mode — fresh flash or NVRAM reset now defaults to ACPI instead of Device Tree
  • Frequency/voltage step size — OPP entries now adjust in 10 MHz / 10 mV increments instead of 1
  • Automatic Python detection — build system auto-detects python3 or python, no manual configuration needed

:warning: Important warning: While V2.1 makes overclocking much safer, you should still have an external 1.8V SPI flash programmer available as a safety net — especially if you plan to change DSU settings. Read the README carefully before changing any values.

Repo: GitHub - Neol00/edk2-cix-unlocked ( GitHub - Neol00/edk2-cix-unlocked: Custom UEFI (EDK2) firmware for the Radxa Orion O6 single board computer (CIX CD8180 / Sky1 SoC). This firmware adds a BIOS settings menu for configuring OPP (Operating Performance Point) tables and TDP power caps, allowing per-domain frequency and voltage tuning without recompiling the BIOS image. · GitHub )

The README has full build instructions, flashing guide, a detailed explanation of how the OPP patching works, overclocking safety tips, and a complete list of changes.

Feedback and testing welcome! Let me know if you run into any issues. I am very curious how high you guys can clock your CPU and still be stable, so please share your results!

6 Likes
2

Why not poll one of the GPIOs on boot and if set, clear setting to sane values?

You can probably think of something more complex, that will not be set by mistake (maybe require a loopback on two GPIOs so you can set one and read the other , then clear it and see that the 2nd is cleared too).

3

Awesome! I’ve been staying on the very first version of the BIOS because next ones wouldn’t support the OPP tables in the same format anymore and since this “opensource” device is in fact full of binary blobs, I couldn’t figure the new format. I’ve been wanting to see something like this but don’t have enough time available to try to hack exactly this, so I’m super happy someone did it, especially with the fact that it includes DSU and CI700 that I also patched!

Honestly it ought to have come from the vendor, especially given the specs changed after distributing the devices, it would have seem the minimum acceptable to let users take the risk to restore their settings in the BIOS, leaving the vendor ones as the “safe” ones. The O6 I have at home runs at 2x3.0, 2x2.7, 4x2.6, the previous one was at 2x3.1, 2x2.8, 4x2.4, and the one at work 2x2.9, 2x2.7, 4x2.6. All at 6400 MT/s RAM. So I found it quite sad not to have access to this in the BIOS as it could even let people share better benchmarks than the stock ones (PC vendors have well understood that BTW).

Time to reconnect the CH341A flasher :slight_smile:

4

Why not poll one of the GPIOs on boot and if set, clear setting to sane values?

As explained above, this is read by the system controller firmware directly from the flash before the CPU runs any code. Here what was done is a configuration interface to write that block into the flash, it’s the same as what the pm_config utility does in the source code, except that it’s fully integrated into the BIOS. The right approach is to have a separate backup flash ship that runs a safe version and use another one to experiment with new frequencies. At least now as long as it works you don’t need to rebuild/reflash, that’s a huge time saver!

What would be needed would be an SCP firmware which counts the number of failed boots or checks that power button is held pressed during boot to ignore OPP, but nobody knows what is in this firmware.

5

So, you were able to make that work? This has no effect when changed in the Radxa BIOS and reportedly it was due to issues in the Cix blobs.

6

Yes it works. It is a config option in the file O6.dsc that disables it by default that i have enabled. If you check the readings from dmidecode –type 17 in the OS it does actually take effect!

1 Like
7

Woah!
No way, At long last a way to make this SoC viable.
This is wonderful!
Running my orion with 4x 1.8, 4x 2.6, 4x 2.8, Saw a major performance improvement with this. (Pretty sure i can fine tune things even further but i’m happy with this for now)
I’ve been pretty upset with how CIX treated their user base.

First by not being so “open” and using closed firmware blobs.
Second is with them telling radxa the SoC is capable of 2.8ghz then failed to deliver on that causing Radxa some issues because users have already purchased the board expecting it to reach 2.8ghz. (Me included)
Third is how CIX is removing the option to drive the CPU to 2.8 or 2.6 in later versions of UEFI.

Not to mention that there’s still no way to use the onboard GPU on mainline, Nor use the NPU because they’re focused on DT changes first.
But that’s irrelevant to this conversation.

I have to applaud @Neol for these changes :clap:
That includes the USB and PCIE fixes, I thought i was going crazy and that these USB issues were caused by my hub, Apparently not!
So thank you once more!

1 Like
8

Forgot to mention but is it possible to fix the core layout?
Also just noticed that i can’t save my custom boot entry with this UEFI.
efibootmgr says: Could not prepare Boot variable: No space left on device

Also also, Is there a way to disable this annoying standby mode the board enters when shutting down?
If i shut the board down, Wait a bit, Come back to turn it on, Press the power button, It would enter a sort of standby mode where i have to press the button again for it to turn on.

When the board is in “Deep sleep” mode the green LED is off, When it’s in standby the green LED turns on.

1 Like
9

It’s really hard to tell what was changed when commit history is all gone.

1 Like
10

Test all bios including this one, when the Intel Arc B50 plugged in, all NVMe and other devices still hiding. :fight_cloud: