Does old Platform/CIX/Sky1/PackageTool/Firmwares/bootloader1.img work with pm_config 2.6?
Orion O6 Debug Party Invitation
@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.
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
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.
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.
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.
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.
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.
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/
Woow! This is interesting. Hope it goes beyond Computex demo unit.
Thats quite wow. More power to them!
Quick, someone get on the demo and dump its firmware!
Got the Nvidia GPU (GT1030) to output at boot in UEFI with added X86EmulatorDxe to EDK2 thanks to @Mario (you’re awesome!).
Combined with ACPI boot and mainline this feels like a proper Desktop now.
I have that running with a Radeon Pro WX5100 (also have a WX2100 and a WX4100 - also working is a NVidia GT710 with Nouveau driver - no NVidia drivers - the GT710 isn’t supported by the latest NVidia packages - I had a 174 working at some point). Radeon is so much faster. I run Fedora Rawhide (and I have a Ubuntu 25 partition). Both work (kinda) flawlessly. The 5100 is a slot only power 50W (75max) RX570 - so, quite alright performance wise. Not playing games.
One issue I have is, that I can’t run all DP ports for some reason. The WX4100 shuts off at more then 2, the WX5100 can handle 3 ports. Weird. And Can’t have both, internal GPU and Radenon running at the same time.
So far I run this productive as my main workstation and had no issues (all my SW runs).
Well, the RX6400 locks up - but I need that for something else; haven’t tried any Navi card, else. RTX4060 no luck - but also I have a PCIe 3 riser and that doesn’t do great with PCIe4 cards).
Also - if you don’t plug in a monitor into the internal HDMI/DP port(s) - the bios screen shows up alright on the Polaris cards (and the GT710).
Did you get any Radeon card that is fanless and has Displayport connectors to work well with the O6?