Interesting, I might possibly have faced this. I’m not using it in graphics mode, only via SSH and UART. But I remember one boot where I saw a super-long avalanche of messages about drm errors that made me think that maybe the GPU handn’t been properly reset. I could only shut it up by disabling the gdm service once for all. I only noticed it once but given that the service was disabled, it won’t be triggered anymore. You may want to see if anything is spitted on the console when this happens.
Orion O6 Debug Party Invitation
@willy, IIRC the SPI peripheral is protected from non-secure world, meaning it may not be exposed to the OS as-is. The proper way to update would be to use UEFI capsules; not sure if they are implemented yet.
It would be good for this sort of findings to be added to the official docs. I often find myself looking up older posts here and pointing users to them.
2 Likes
OK, but the hardware remains accessible, right ? I guess in the worst case it could be bit-banged using GPIO. Anyway I don’t see the purpose of not exposing it, even PCs can be updated from the OS (I could understand having a write-protect option in the BIOS though).
I have not yet checked if it’s actually secured by default. But you don’t want it directly exposed to the OS either way, because it’s already used at runtime by the UEFI variable services. This implies that only UEFI can safely drive the SPI controller.
PCs use the standard capsule updates mechanism. I’ve seen some recent changes related to this, so it appears that it’s being worked on.
Hmm got it. I don’t think I’ll ever see the limit by which UEFI disgusts me 
For those interested, I’ve opened a separate topic to discuss OPP settings to change RAM and CPU freq, and made them accessible in a forked repo: Trying different CPU/DRAM frequencies for Orion O6. This will avoid polluting this thread with this.
To those who mentioned using a mainline kernel with ACPI, how did you get around there not being mainline support for the PWM fan? The system boots fine, but the fan shuts off for me.
does it not turn back on under load?
Haha ah of course you’re right. The fan switched itself on after thermal_zone0 went above 50. I didn’t want to push it before just in case. Thanks for the suggestion!
1 Like
So i installed Ubuntu 24.10 in ACPI mode with the 9.0.0 bios, i had to remove the dgpu for that.
It really takes a long time to display the login screen, some times several minutes but it does work.
It has a old kernel (6.11) but it detected the onboard nics and even my non radxa wifi m.2 card. Nice.
After that i installed the RTX 3060, plugged the monitor to it, and i got a desktop! There is no video out for a while as the 3060 dosent work on UEFI and still takes several minutes to display the login screen…
Long boot times could be caused by dev-tpmrm0.device, might be waiting for the 1m30s timeout like it does for me on nixos. Does systemctl mask tpm2.target or adding systemd.mask=tpm2.target to kernel cmdline speed things up?
I only started getting that timeout error after the BIOS update, and I used the following command to prevent it from happening, in a way that maybe won’t break it when the BIOS feature starts working in the future.
sudo systemctl mask dev-tpmrm0.device
I finally managed to install Ubuntu 25.10 on my NVME drive.
It works OKish and the command you gave @Bill_Fleming helped reducing the boot time.
I also tried to compile the last version of mesa (25.0.3). But so far it seems that the patch for the G720 is not integrated yet (and might not be soon as I can see that it fails to build on their CI c.f). I might try to build this branch, just to see.
In case others would stumble upon this, I noticed something a bit surprising after updating the BIOS on my 32GB board. Sometimes after you flash it, if you only reboot using “reset -c” (cold boot) or stop using “reset -s” then press the power button, or power-cycle using the power button, after reboot, only 16GB RAM are reported (both in the BIOS and in the OS). The first time I feared something was broken or fried. But in fact no, one really needs to pull the power cable and plug it again after flashing, and in this case the 32GB are reported again. Even after only 16GB have been reported, just pulling the plug once is sufficient to make the 32GB appear again. Hoping this helps someone
I mean I don’t think it’d be able to work without all the 6.1-cix drivers and devicetree anyways. Plus you’d only get vulkan 1.1 with panvk.
mary’s panfrost-avalon branch seems to build fine for me, I guess if you wanted you can probably use it with her kernel tree https://gitlab.freedesktop.org/marysaka/linux/-/tree/6.1-orion6-panthor
1 Like
Yes this is a CIX provided BIOS for Arm SystemReady certification purpose. Arm requested us to put it on our website but CIX already made another version, so we will need to wait until the final release.
This one currently has no relation with our edk2-cix repo. We have no source code to the SR BIOS.
2 Likes
Like Mario said it is not safe to expose low level firmware directly to the OS. We are working on our own Debian system, and one of the features is to allow updating BIOS directly from systemd-boot entries:
This should make the process easier for the end user, and especially helpful if kernel upgrade requires an updated BIOS.
As for the development, it is really that tedious that I have to write a script to make it even a bit less insufferable.
1 Like
spot on with my assumption lol.
I thought as well about adding a line to my grub.cfg for this. I already added this to access the shell, it saves me one access through the BIOS, and I thought about calling flashupdate.efi directly as well:
menuentry 'UEFI shell' {
chainloader /orion-o6/Shell.efi
}
Also one thing I find a bit annoying with that firmware is that flashupdate takes no option so you can’t flash only one part of the chip, you have to flash it entirely each time. That’s annoying because it takes a long time, also at next boot to reinit everything, loses the settings etc, while some parts (DRAM, CPU settings) only take one 4kB page and could directly be touched without all these inconvenience.
But I understand that all the UEFI stuff is a bit more the “windows way” of managing a computer and that the computer devices are hidden behind obfuscation layers. It’s not dramatic, just needlessly inconvenient when you try to develop or experiment. Thanks for your explanation!
hmm I might be too noob to understand why I need another kernel to make mesa work. (I fundamentally never learned how drivers and other stuff interact with the kernel)
yet I can give it a try.
also, the devel branch of mesa (25.1) won’t install using meson. everything compiles, but install won’t Switch it to the 25.1 version systemwide. as usual no obvious information why this happens but guessing this is some flag in the code that prevents it.
also won’t show the G720 in glxinfo if I use devenv mode