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.
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.
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
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.
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).
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.
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.
First you search the matching UI strings in .uni files, lead you to:
Then you change which value is default in .vfr:
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 
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
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 