Orion O6 Debug Party Invitation

Ok what is happening to me right now, with the RTX 3060 connected, Linux installers start with the IGP, then i get stuck on a black screen. Then they attempt to display video on the dGPU, but its not the main screen, its the extended desktop, so i cant really install anything with the dGPU attached.

Ubuntu 24.10 Live CD, actually gave me video output via the RTX 3060 but it was the extended monitor.
The 3060 dosent work on the bios atm… or it always considers the iGPU as primary, even when nothing is connected to it.

And if you manage to install Ubuntu 24.10 or a daily of 25.04 without the eGPU being present and then try hooking it up afterwards? Maybe this fools the iGPU?

ofc I did.

Set back to device tree, and completely disabled network stack like I did on the previous 2.2.1 version.
So far I never had an OS close to stable, be it radxa image or other I tested. The worst thing is that if I flash the onboard SSD I have with the radxa image, after a random number of reboots, gnome won’t load anymore and i’ll reach a state of login loop at startup.

FYI I have the 64GB version. Dunno if it has something to do with it or no.

I’m a bit confused. Radxa’s github repo still contains only 0.2.2-1 with a last commit yesterday, so is this a build from a different tree ? Maybe from CIX ? But their tree doesn’t even seem as up to date as Radxa’s. Or was only the version changed ?

Also I found that PM v2.6 as found in the latest repo doesn’t seem to be producing working OPP tables. Whatever I change there is ignored and the output format seems to differ a bit. There’s a nice feature in the new csupm_config tool that allows to read a csu_pm_config.bin file and dump its settings, but running it on a working file produced by a previous version just emits garbage and segfaults. As such if the formats are incompatible, I suspect that any PM tables produced by that tool are just not properly understood by the init code.

I also noticed that the checksum isn’t located at the same place between the old and new tools, which could also explain why the new tables are ignored:

     // checksum
-    (void)double_check_sum(&g_config, sizeof(g_config) - 8, &ck, false);
+    (void)double_check_sum(&g_config, sizeof(g_config), &ck, false);
     g_config.crc1 = ck >> 32;
     g_config.crc2 = (uint32_t)(ck & (0xFFFFFFFFull));

Anyway, reverting the pm_config tool to v2.1 doesn’t produce a working setup either with that BIOS, so it’s difficult to figure where the issue is given that I still don’t understand what blobs consume the csu_pm_config block.

I’ll give a try to that new BIOS, to see what it looks like, but I still feel like manipulating a black box.

@RadxaYuntian do you know if there is a way to access the SPI from Linux ? I failed to find any MTD device for now. It would make BIOS upgrades much simpler during development, we could just use flash_write to /dev/mtd0 instead of having to boot three times. Also, is the FlashUpdate.efi utility limited to flashing the whole image or can it also flash a selected part ? It doesn’t have any help available, and “strings” on the binary doesn’t reveal anything useful.

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.

@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 :slight_smile:

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 :slight_smile:

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