For now we only support the Debian system we provide with the BIOS released during the same time period. This is similar to our other system images, except for those, the bootloader is part of the image, while for O6 it is a separate BIOS.
Orion O6 Debug Party Invitation
Did you find a way to make the OPP work in 0.3.0 ? Last time I tried, anything I’d put there was completely ignored, both in the v21 and v26 formats, which is why I rolled back to 0.2.2.
Do you have more detailed description of your issue? I can forward that to CIX.
I should recheck for more accurate details, but from what I remember, changing anything in the opp_config file has strictly no effect on the CPU frequency. The tool does indeed produce a config block in the new format, but that one seems completely ignored at boot. I had to revert to bootloader1.img prior to pm_config 2.6 (that was pm_config 2.1) and same for the tool that generates the config block, for opp to be considered again.
I’m having the changes available here with a few info in the commit messages:
https://github.com/wtarreau/orion-o6-edk2-platforms/commits/20250412-fix-pmcfg-1/
https://github.com/wtarreau/orion-o6-edk2-non-osi/commits/20250412-fix-pmcfg-1/
Hoping this helps. BTW there might be trivial fixes you could be interested in there (such as the one that takes care of rebuilding csupm_bin_config). Thanks!
Does old Platform/CIX/Sky1/PackageTool/Firmwares/bootloader1.img work with pm_config 2.6?
@geerlingguy, I managed to get AMD Radeon RX 6700 XT working with UEFI version 9.0.0 in ACPI mode and Ubuntu 25.04. However, I had to build my own kernel (I could provide instructions, if necessary) - if I am not mistaken, I applied the patch attached here on top of commit 7a13c14ee59d4f6c5f4277a86516cbc73a1383a8 (that is between tags v6.15-rc4 and v6.15-rc5).
Doom 3 (in the form of dhewm3), GravityMark, and Shadertoy in a browser seem to work fine. Actually, Doom 3 had some visual artifacts, but after I switched the OpenGL driver to Zink (with MESA_LOADER_DRIVER_OVERRIDE=zink as an environment variable) they disappeared. Setting RUSTICL_ENABLE=radeonsi let me run the Geekbench Compute benchmark, but it complained during the result validation at the end and performance was atrocious (more than an order of magnitude lower than expected). The older Clover OpenCL implementation led to a kernel panic.
1 Like
Unfortunately not. The format of the structures has changed between the two. I can recheck the detail this week-end, but from memory I think there was a new field indicating the power level in the new format that was not there in the old one (only freq and voltage).
Another thing we’re really missing, maybe your contacts at CIX have an idea how to do this, is to mark certain OPP as “boost only”. This is super convenient, as it allows to declare some OPP that are possibly not stable and that are not used by default. The user can then set the max OPP they want then enable boost mode to benefit from them. It allows each board owner to try and choose the frequencies of their different clusters depending on what their boards support. For example, my first board was fine with the two big clusters at 3.0 while the second one supports only 3.1 and 2.7 for them (which confirms your concerns about 2.8 not being stable everywhere). This leaves quite a good margin from the new “stock 2.6” for most owners.
I had been using the boost mode quite a lot at the RK3399 era (particularly on my build farm for obvious reasons), and it was really appreciable, allowing the user to recover the unused (and understandable) safety margin from the stock device.
BTW, if you get the whole BIOS source code this month, maybe it will be easier for all of us to figure how to just add settings there like in any PC instead of flashing such parameters at build time, so that anyone can simply adapt to their device’s capabilities. I’m still super busy till the end of the month (new haproxy release) but after that I’m on holidays, I’ll have more time to dig 
1 Like
If you have not seen it - @geerlingguy uploaded video about Orion C6 SBC:
https://www.youtube.com/watch?v=OMnCqmM-WKo
This is review I was waiting for. Now can share with all those friends and people who sent me link to Orion C6 announcement in December.
4 Likes
This was great, thanks!
There was a bug with hdp flush in amdgpu (likely an acpi issue or HW issue). I think fixes are in current -rc5 kernel.
Or you might need to compile vanilla kernel, something like 6.12 (not a stable branch) by yourself. Some distro kernels took commits that break things so you might be out of luck.
You might need to check this thread:
https://lore.kernel.org/amd-gfx/CADnq5_PuXu-9MAhr3d7HLGnOqHR7Uo+nJPzrpdJEusvRCE8wbw@mail.gmail.com/
Yes, I confirm that kernel version 6.15-rc6 works without any extra patches on UEFI version 0.3.0-1, in ACPI mode as usual. In fact, I am writing this reply on my O6-based machine 
.
In my case I simply got the kernel source, copied one of the stock Ubuntu kernel configurations from /boot, ran make oldconfig, and was able to compile a working kernel.
4 Likes
I have created a set of PPTT tables for this machine, which fix the topology when injected using fedora+dracut.conf’s acpi_override option. They are in two forms as github issues rather than PR’s for ‘reasons’ one of which is an aslc file which can be included in the edk2 acpi build dirs/etc and should compile if your lucky enough to be able to build it in a meaningful way. Its possible depending on kernel configuration/etc this could help performance, but I’ve not done any benchmarking just validation that its possible to convince SPE and lstopo to work.
3 Likes
Also for all the people plugging in GPU’s/etc. The x86 option rom emulator doesn’t appear to be enabled by default on this platform. That means that unless you have an arm option rom and a supported card you won’t get UEFI graphics on it, and likely it won’t configure correctly in linux either.
Ex: the X86EmulatorDxe.inf should be added to the edk2 build, and that will enable a subset of boards that don’t tend to work out of the box on arm platforms.
3 Likes
Note: While there hasn’t been any new changes since Intel archived that project in march the person responsible maintains it here: https://github.com/andreiw/MultiArchUefiPkg
Let’s see if we can get Nvidia GPU’s in UEFI with this. Would make debugging easier for me and others probably too
Just wanted to back this up. Currently running No Man’s Sky on a RX6500XT on Ubuntu 24 with the 6.15rc6 generic kernel (and firmware-amd-graphics) installed. Seems like the kernel panic with some more recent Radeon cards has been resolved in mainline
Nice. I think I see some kernel panic from amdgpu driver (not related to hdp) when I run and use Firefox for a while. I need to check and play with a little bit more but will nice if someone else can reproduce it too.
@geerlingguy If you have an amdgpu board, you might retry testing it with a 6.15rc6+ kernel because, Yes there was a fix for a PCIe posted write bug merged to amdgpu that fixes the OOPs/hang on boot-up you were probably seeing. I have a RX6600 plugged in and its running pretty flawless now, including in the EDK2/BIOS/Grub menus.
OTOH, the fix is worrying as it looks like something CIX/radxa should be looking at and possibly fixing in TFA/etc if it can be fixed. (AKA root bridge/interconnect isn’t responding correctly (or a timeout is firing) when it detects read after write operations).
Also, it appears that the board is power/thermal capping the CPUs when its on USB-C more than it is when using an ATX power supply. I got a small but noticeable bump switching to a proper PSU, and now the cores go up to 60C before throttling.
3 Likes
Unexpected things are happening on the UEFI front:
https://www.ami.com/blog/2025/05/20/aptio-v-uefi-firmware-from-ami-powers-radxa-orion-o6-mini-itx-motherboard-at-computex-taipei-2025/
7 Likes
Woow! This is interesting. Hope it goes beyond Computex demo unit.
Thats quite wow. More power to them!