Orion O6 Debug Party Invitation

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

We have renamed setup.nsh to startup.nsh, which will be automatically loaded by Shell.efi, saving more typing.

I think the cix_flash_ota.bin should be what you need, and flashupdate.efi should support it from a few snippets that I saw. It is not well documented and since we might update EC binary, I did not test this.

Is actually a good thing. since that can easily change between different BIOS versions. If you don’t like it just change the default settings at build time.

1 Like

Re. flashing only part of the firmware, you might have missed that, but I’ve shared a small guide above (at the end of that fastboot guide).

You can then use cix_flash_ota.bin with FlashUpdate.efi or fastboot (to speed up iterations).

1 Like

Weirdly (again) I face the fewest issues when I run radxa debian Image on my (old) 128GB kingston HyperX usb stick. It is fast enough so that everything is smooth.

I say that because other experience with chinese usb-c to nvme adapters for M.2 SSDs lead to system failures etc.

Not to mention that those adapters are causing 0 issues with my laptop or others computers I use them on.

That being said, I’ ll use the USB stick for a while I guess.

I noticed that part but I don’t know enough of the flashing mechanism involved to figure how this relates to this :-/ I never knew what the _ota image was for and don’t even know if it’s compatible with any of the tools so for now I abstained from touching it.

Hmmm interesting. It’s indeed not (at least prominently) documented, I never knew what _ota was for (I suspected “over the air” but didn’t see any relation here). But since the _ota image is smaller, are we sure we only want to flash the beginning and nothing after it ?

I can understand your point on thisn especially from the vendor’s perspective. However, even after trying hard, I still couldn’t figure the options to change the default settings. EDK2 is a super-complicated thing where I really do not understand what each part is doing. For example I’d just have liked to enable ACPI by default (nowadays it’s the only option I change), and haven’t found which build options (or even code lines) change the default values for the BIOS settings. If you happen to find it without wasting your time, a pointer would be greatly appreciated!

Well, you wanted to flash only part of the image, right?

Without going into much detail, firmware packages contain multiple images and a header describing each image (what it is, where it’s supposed to go in flash).

You can have:

  • a full package (all) that contains all firmware images and also has the exact layout of the flash, meaning that it can be written directly with a programmer or the provided UEFI update app.

  • a partial package (ota) that can contain only the image(s) you want updated. This has the header right at the beginning and must only be flashed through the UEFI, as the update app needs to parse it and place each image at the correct location.

You can find the full package description here: edk2-non-osi/Platform/CIX/Sky1/PackageTool/spi_flash_config_all.json

The OTA package is described here: edk2-non-osi/Platform/CIX/Sky1/PackageTool/spi_flash_config_ota.json

As you can see, it currently includes just the BL33 EDK2 image:

{
    "cfs_version": 1,
    "fip_version": 2345,
    "flash_size": "0x800000",
    "ota_flags": "0x80000000",
    "image_count": 1,
    "image_header_groups": [{
            "image_type": 7,
            "address": "0x3FE000",
            "size": "0x402000",
            "file": "Firmwares/bootloader3.img"
        }
    ]
}

But you can replace that with any other image description taken from the full package.

For instance, if we want to update the pm_config:

{
    "cfs_version": 1,
    "fip_version": 2345,
    "flash_size": "0x800000",
    "ota_flags": "0x80000000",
    "image_count": 1,
    "image_header_groups": [{
            "image_type": 4,
            "address": "0x3FC000",
            "size": "0x1000",
            "file": "Firmwares/csu_pm_config.bin"
        }
    ]
}

Run the build script, then pass the generated cix_flash_ota.bin package to the FlashUpdate.efi app and it will know what to do with it.

I can understand your point on thisn especially from the vendor’s perspective. However, even after trying hard, I still couldn’t figure the options to change the default settings. EDK2 is a super-complicated thing where I really do not understand what each part is doing. For example I’d just have liked to enable ACPI by default (nowadays it’s the only option I change), and haven’t found which build options (or even code lines) change the default values for the BIOS settings. If you happen to find it without wasting your time, a pointer would be greatly appreciated!

This is also how you keep the NV variables across updates. But it does require care from the hardware vendor when adding new settings, to not break compatibility.

2 Likes

Noticed that the 3060 was running really slow so i ran “sudo ubuntu-drivers install” to see if by some miracle the Nvidia propietary drivers would install and run… and they did.

2 Likes

First you search the matching UI strings in .uni files, lead you to:

Then you change which value is default in .vfr:

1 Like

https://www.youtube.com/watch?v=7z2AJ35KaAE
O6 Running with the RTX 3060.

4 Likes

I had indeed found these files, that’s where I located the csu_pm_config.bin on the flash. I just didn’t know that the OTA format contained a header transcribing this nor that flashupdate.efi would be able to consume it. That’s wayyyy easier in this case :wink: I’ll probably make a script to produce various combinations and emit the relevant csu_pm_config and ddr parameters so as to make it easier to test one or the other.

Many thanks for your explanation, that’s a huge time saver!

Many thanks Yuntian! It’s indeed much easier with such indications, that’s very helpful!

Have you actually replaced the system mesa with the one you built? You can try using environment variables to override the mesa an app uses https://gist.github.com/Venemo/a9483106565df3a83fc67a411191edbd#using-the-compiled-mesa-binaries

install won’t Switch it to the 25.1 version systemwide.

Could not be clearer. did meson install but after reboot the mesa version will still be 25.0.3, which is the version I also installed by compiling it and installing myself.
I really don’t want to mess with it in an ad-hoc way to test whether I can use GPU acceleration for firefox e.g, if it does not install system wide, then I’d rather wait.

Then it’d depend on your distro. Honestly don’t know why you’d even want to override system mesa without doing everything through your distro’s package manager (especially playing with an untested PR), that seems way worse and error-prone than just testing out an app with the custom build artifacts

And again there’s no point in doing this anyways unless you’re running a kernel with panthor driver that support the g720 and knows that the Orion has one

1 Like

You’re right, I don’t really know what I am doing as I am learning low level linux. That is also why I abide to the idea of breaking the OS, because this is the game I play : Die and retry. I do know that the Orion has an immortalis G720, I did not know what is panthor driver, as I am trying to figure out how drivers and kernal interact together, and finding each piece of this and that is like searching a needle in a haystack if you are not aware enough in the first place. Thanks for helping btw, other’s knowledge is paramount in this journey !

P.S : Now I am struggling to access the actual patch files searching in the email text :smiley:

Hi all,
It is a bit difficult to follow all aspects discussed here, but maybe I can ask directly.

First, I also have an Orion board, with 0.2.2.1 BIOS and plan to use (or at least test) a Radeon RX 7600 with it. Currently, I have installed the Radxa Debian 12 image and can see the discrete graphics card is detected at boot. So, before diving, should I upgrade to the newly added 9.0.0 version of the BIOS and should I change to another distro, maybe latest Fedora ARM spin?

Then, as second question: did someone succeed in launching sbcbench on Orion? In my case it loops endlessly on too high CPU usage under the GUI and had no console display when going to run level 2 with the iGPU.

Thanks

Me for example: https://github.com/ThomasKaiser/sbc-bench/blob/master/results/reviews/Radxa-Orion-O6-1.0.md

But with the preliminary state of software it’s rather pointless to collect any scores yet.

2 Likes

Radxa, you do know what else is needed to get the iGPU working on mainline linux via ACPI? There is currently a Panthor patch and a mesa patch to enable the G720 but that does not seems to be enoght.

So we can have an idea of the work needed.

Hey,
I am using RX6600 now with ACPI and I tested different upstream kernels.

Please note that you might need to try kernel 6.12 first (vanilla if possible) or in case of any issues try to revert this one:

cf424020e040 drm/amdgpu/hdp5.0: do a posting read when flushing HDP

I raised it in maillist:
https://lore.kernel.org/amd-gfx/D97FB92117J2.PXTNFKCIRWAS@linaro.org/

After reverting it works fine mostly.