SystemReady BIOS needs to support Windows, which does not support different types of cores on Arm, so they are disabled.
Orion O6 Debug Party Invitation
Can we then get a upgraded Bios for Linux with all the cores?
Are you fooling us again?
First not the tec spec. now not all cores for linux available, whats next?
Seems we have bought the most expensive paperweight.
Should be fixed in this one.
Don’t use SystemReady if you want all cores.
2 Likes
Which is a bit strange since Windows boots flawlessly on something like a Snapdragon 8 Gen3 which combines the very same A520/A720 as in P1 but adds also a single X4 core to the mix.
And while all cores on each SoC share same features/flags they do differ between both SoCs. Asides the flags they both share (fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 sm3 sm4 asimddp sha512 asimdfhm dit uscat ilrcpc flagm sb paca pacg dcpodp flagm2 frint i8mm bf16 dgh bti ecv afp) these flags are unique to each SoC:
- Snapdragon 8 Gen3:
ssbs - Cix P1:
sve sve2 sveaes svepmull svebitperm svesha3 svesm4 svei8mm svebf16 mte mte3 wfxt
Or is this an ACPI vs. DT thing?
See:
This could probably be worked around by making core 0 an A520, but ultimately should be fixed in Windows as SPE is just an optional profiling feature.
Though, the SystemReady band test suite was run with only 8 cores as well, so I suspect there’s more to it and the system couldn’t be certified with all cores enabled.
1 Like
As it’s the case wird all those Snapdragons Windows runs on 
From the Windows perspective: has this any disadvantages the 1st CPU core being a slow one? Bad affinity settings maybe?
I lost a bit overview (and interest) and have no clue whether Cix has been asked or said to implement a firmware setting ‘adjusting’ the core order so core 0 could be set to the first A520 instead of core 11 from the fastest cluster…
2 Likes
There’s a similar problem on linux with regard to PMU counters. It does detection on CPU 0 which, being a big core, has 30 event counters available. But the little cores only have 7, so you can kernel panic it by trying to use more than 7 on the little cores.
I did run tinymembench again, as well as my full “standard suite”—results are being compiled here: https://github.com/geerlingguy/sbc-reviews/issues/62 (I have moved the earlier results into a comment and am re-filling the original issue with SystemReady results).
How about just installing the module?
sudo apt install r8168-dkms or maybe r8125-dkms
I wasn’t able to do that through the graphical installer with the Live CD ISO, at least. It would bail out since I didn’t have a network connection.
1 Like
This seems to be Debian’s fault then. Maybe you can use a WiFi dongle or USB ethernet as a workaround.
I mean… that’s fine… but I’m just following the Radxa Wiki recommendations, and pointing out what’s not working: https://docs.radxa.com/en/orion/o6/bios/boot-debian-official-iso
If Debian requires additional work to get installed then it would be useful to include that information in the Wiki since that’s much more accessible to end users (instead of reading through 50 pages of this forum thread ).
2 Likes
I understand your point, but that it would not install would be true for any x86 system with the same ethernet chip. So while pushing Radxa to make their docs better is a nice goal, this is not something specific to them, and any manufacturer should include these instructions (and then, where do we stop? Should every manufacturer include instructions on how to install any distro on any pc?)
Most X86 manufacturers don’t specifically call out one ‘tested’ / ‘golden’ OS that they recommend in their docs 
This being a novel motherboard and a novel CPU, any and all help towards setting people on a happy path is appreciated.
I understand that the rtl8126 driver is not included. And I could easily pop it onto a USB flash drive with the driver on it during Debian setup, and install it that way (though it’s inconvenient and I’m lazy, which is why I wound up switching tracks to Ubuntu).
But the whole purpose of this thread (IMO) is to smooth over the 300 or so remaining bumps so people who buy these boards after we initial alpha/beta testers (I’m including current purchases in that group) will not have to live with all the same struggles we’ve faced.
2 Likes
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!
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.
1 Like
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?