This is quite surprising, I also had to install this on Ubuntu to make it work (not on orion, I don’t have this). Strange times!
Orion O6 Debug Party Invitation
I wonder if that might’ve been a Geekbench reporting issue? I just ran your sbc-bench on the same install and I see 2596/2600 clocks measured:
Clockspeeds (idle vs. heated up):
Before:
cpu0 (Cortex-A720): OPP: 2600, Measured: 2596
After:
cpu0 (Cortex-A720): OPP: 2600, Measured: 2596
Full results: https://0x0.st/8WAL.bin
At this point i would just recommend new people to stop installing specialised DT images and go for standart stock ISO in ACPI mode.
The Radxa Debian image never worked right for me, even if it worked right, the desktop stopped working (not being able to log in in the desktop screen) probably becaus esome package i keep installing keep breaking it.
Just use the stock Ubuntu 25.04 desktop arm64 ISO image with the 9.0.0 BIOS in ACPI mode.
What would be nice to have from Radxa, while we wait for full mainline, is a official guide on how to install the cix packages on it to get the gpu, npu and vpu working. There is already some people helping with that.
That said, the consesus seems to be the IGPU cant work in ACPI atm.
Another question to Radxa, i noticed that the 9.0.0 bios removed the iGPU clock settings, this is also about CIX not liking overclocking? Any idea if that will come back or what the final clock will be? Or at what clock it runs now?
The documentation mentioned to use an alternative network device: " * Connect the O6 Type-A port to a Type-A USB to Ethernet adapter (Internet access is required for ISO installation)."
2 Likes
We are barely figuring this our ourselves. First off, SoC vendors usually don’t have this documentation in the first place, and we have to reverse engineer their SDK to understand how they put the system together. SoC vendors also almost never follow Debian policies so we have to do a lot of hacking to make the system working. There is also no guaranteed stability between SDK releases, so you cannot expect your hack will work forever.
You are welcome to check our hacks to figure out how we did those. It’s all public:
We have no involvement to the development of SystemReady BIOS so we cannot answer any of those questions. We should have the source code eventually and that’s when we can make adjustment.
5 Likes
Ah indeed it is, I completely missed that line. Might be easier to spot if re-worded, or maybe it could be singled out with part in bold, or as the first item? As that’s the one thing that was not intuitive for me.
I’m used to USB adapters for Windows, but had never personally had that happen in a Linux install, as I’ve mostly installed Ubuntu on newer boards with 2.5 Gbps networking (and Ubuntu 24.04 and later, I believe, include rtl8125/8126).
That’s because sbc-bench was pinning the measurements to cpu0 whereas Geekbench doesn’t do this and then with this UEFI firmware (that’s there for certification processes and not us?) and Ubuntu release it’s simply luck on which core a task is executed. We know from your testing that power hungry tasks may end up on cores clocked at 2.6 GHz and 2.5 GHz, maybe further testing reveals that 2.3 GHz and 2.2 GHz are also possible.
Full details over there: https://github.com/ThomasKaiser/sbc-bench/issues/115#issuecomment-2834228333
2 Likes
I would recommend to stay away from older releases of distributions.
Debian 12 ‘bookworm’ is a great release but you want 13 ‘trixie’ images for today’s development due to 6.12 kernel and newer userspace.
Ubuntu 24.04 has 6.8 kernel by default and 6.11 as HWE one.
Fedora 42 gives you 6.14 one etc.
Spending time on old releases (Debian 12, Ubuntu <24.04, Fedora <41) is just waste of time.
RTL8125 chip is in mainline for quite a while. You just need to use newer kernel (Debian 12 has 6.12 in bookworm-backports).
2 Likes
I really think that the whole “CPU mess” is around the same problem:
- absurd CPU ordering making interrupt distribution etc a real pain
- windows not liking what it’s being presented
Are you guys sure that by presenting consistent clusters this would not simply address the problem ?
It’s rather strange that only this board with this very baroque CPU ordering is experiencing trouble, to the point that one has to disable 1/3 of the CPU cores. From the very beginning this has sounded very fishy to me and I sincerely hoped that this design mess would ultimately be addressed. I’m noting that along all the questions around that topic from the very first days, nobody ever provided a response about the reason why cores are ordered in that crazy mode. I.e. either we can force the SoC to boot from the A520, or we need to present the full suite of cores consistently to the operating system even if that means presenting the big ones first. But the current approach is totally broken. I have to agree with @tkaiser here, it’s not the first Arm board that windows boots on and which has different CPU cores. In addition these ones present the same set of flags, so I’m really suspecting that the only problem windows is facing is that the logical CPUs do not match the physical ones.
But with the binary-only BIOS it’s impossible to investigate. I spent two full week-ends on that already and have to give up by not understanding what I was seeing 
Please at least try to present the CPUs as they should be and test again. The current situation is the worst anyway.
1 Like
Another few bits of info from testing a Windows 11 install (downloaded ISO from Microsoft, flashed to USB with Rufus, install went without a hitch:
- At one point, the display output went to 640x480 (from the HDMI port), tried rebooting a few times and with 3 different displays and two different KVMs, they were all getting a 640x480 signal—though Windows was running at 1080p, so something confusing there! Even the BIOS was rendering at 640x480 for some reason
- To fix, I had to pull power and wait ten seconds. Then after that 1080p was rendered throughout.
- Speculation: Is the Radxa RA820-1 chip some kind of HDMI retimer or something? Maybe I got it stuck in a weird memory state that required the full power off/power on cycle to get it out of? I couldn’t find any mention of RA820-1 online.
- Nvidia driver will not install (of course), but I do see an Nvidia RTX A400 card in the PCIe subsystem in Device Manager. Wish Nvidia would someday release their Windows drivers (which are said to exist for Azure uses).
- Geekbench result was a bit worse than under Linux: link to comparison
Afaik it used to be that windows didn’t have problems and only with recent versions this bug was introduced.
Unless Windows requires SPE, that could be disabled (AFAIK it would have to be done in ATF, not UEFI) so Windows doesn’t detect its presence on a big core and then crash trying to use it on a little core.
Speaking of ATF, are we ever going to get the CIX source for that?
I just installed the new 0.3.0-1 firmware release from the edk2-cix repo, and am not having any success booting plain Fedora 42 aarch64 with it (ACPI mode). Same for Ubuntu 25. The non-ISO releases installed the way I install these usually just kicks right back to the UEFI menu, both with a USB drive and an NVMe drive. An ISO image on a USB drive gets stuck almost instantly during boot on something about bringing up CPUs.
Both fedora 42 and ubuntu 25 hang up after just this output
EFI stub: Booting Linux Kernel...
EFI stub: EFI_RNG_PROTOCOL unavailable
EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path
EFI stub: Generating empty DTB
EFI stub: Exiting boot services...
I/TC: Secondary CPU 0 initializing
I/TC: Secondary CPU 0 switching to normal world boot
I/TC: Secondary CPU 1 initializing
I/TC: Secondary CPU 1 switching to normal world boot
I/TC: Secondary CPU 2 initializing
I/TC: Secondary CPU 2 switching to normal world boot
I/TC: Secondary CPU 3 initializing
I/TC: Secondary CPU 3 switching to normal world boot
I/TC: Secondary CPU 4 initializing
I/TC: Secondary CPU 4 switching to normal world boot
I/TC: Secondary CPU 5 initializing
I/TC: Secondary CPU 5 switching to normal world boot
I/TC: Secondary CPU 6 initializing
I/TC: Secondary CPU 6 switching to normal world boot
I/TC: Secondary CPU 7 initializing
I/TC: Secondary CPU 7 switching to normal world boot
I/TC: Secondary CPU 8 initializing
I/TC: Secondary CPU 8 switching to normal world boot
I/TC: Secondary CPU 9 initializing
I/TC: Secondary CPU 9 switching to normal world boot
I/TC: Secondary CPU 11 initializing
I/TC: Secondary CPU 11 switching to normal world boot
Switching to device tree mode, the hang is after just
EFI stub: Booting Linux Kernel...
EFI stub: EFI_RNG_PROTOCOL unavailable
EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services...
but I wasn’t expecting device tree mode to work without a cix kernel.
Not everything is broken, my previous radxa-customized fedora 41 nvme install did boot after the update.
Also adding a note that when booting in Ubuntu with an Nvidia A400 graphics card installed in the PCIe slot, I get errors like:
[ 494.760746] arm-smmu-v3 arm-smmu-v3.0.auto: event: F_TRANSLATION client: 0000:c1:00.0 sid: 0xc100 ssid: 0x0 iova: 0x0 ipa: 0x0
[ 494.772149] arm-smmu-v3 arm-smmu-v3.0.auto: unpriv data write s1 "Input address caused fault" stag: 0x0
[ 494.781555] arm-smmu-v3 arm-smmu-v3.0.auto: event 0x10 received:
[ 494.787577] arm-smmu-v3 arm-smmu-v3.0.auto: 0x0000c10000000010
[ 494.793512] arm-smmu-v3 arm-smmu-v3.0.auto: 0x0000020000000000
[ 494.799447] arm-smmu-v3 arm-smmu-v3.0.auto: 0x0000000000000000
I’m presuming that’s just something to do with the older card not having the right Option ROM to be compatible with this board? I tried both Nouveau and the nvidia-proprietary driver (570) from Ubuntu.
I wonder also if that could be coming from snd_hda_intel? That’s the device at c1:
[ 2.945867] snd_hda_intel 0000:c1:00.1: Adding to iommu group 0
[ 2.946078] snd_hda_intel 0000:c1:00.1: enabling device (0000 -> 0002)
[ 2.946091] snd_hda_intel 0000:c1:00.1: Disabling MSI
[ 2.946095] snd_hda_intel 0000:c1:00.1: Force to snoop mode by module option
It’s an DisplayPort to HDMI adapter chip, and we used on our other products when we need a HDMI port without issue. Currently CIX’s display controller does not work very well with this chip and they are working on it.
Yes this is another dtb BIOS for CIX kernel.
You mean b6 image? I have found unplug and replug USB device when it went to setup screen helps with detection.
Also, O6 is now listed on Arm’s official certified system list. From the cert the following systems were certified with O6 with SystemReady SR:
• Windows PE 26100
• SUSE Linux Enterprise Server 15 SP6
• Red Hat Enterprise Linux 9.5 (Plow)
• Ubuntu Desktop 24.10
Debian 12.9 was not in the list due to lack of NIC support (though Arm folks said the ISO can still be installed without network), and more importantly, because the system will auto suspend and then freeze. This seems to be desktop environment ignoring firmware reporting suspend not supported, and did the suspend syscall anyway.
3 Likes
You mentioned that the system will automatically suspend and then freeze when using Debian 12.9 with BIOS version 9.0.0. Will the B6 image (in device tree mode) experience the same issue?
It shouldn’t. It’s a different kernel. But I don’t remember how the test report says.
Orion C6 being on “SystemReady complaint” list just shows that SR compliance list is worthless.
Especially when you had to drop 1/3 of cpu cores to get there.
1 Like