You mean b6 image? I have found unplug and replug USB device when it went to setup screen helps with detection.
I am speaking only of vendor-provided aarch64 images, not customized radxa/cix stuff. It was said earlier that ACPI mode should work (obviously without special devices) on the latest upstream kernel. So far that doesn’t appear to be the case, or that 0.3.0-1 firmware release is not there yet.
0.3.0-1 was just released. You should stay on 0.2.2-1 for ACPI since that’s what most people were using.
Can you at least explain the differences, especially regressions (given you’re suggesting 0.3.0-1 breaks boot of stock upstream linux versus 0.2.2-1)?
Ideally that explanation would be in the github release notes.
Hahaha. I always look forward for your comment.
Miss you on x. 
CIX did not provide changelog for their BIOS updates. The only changelog we have is the one for the SDK I posted above.
Can you at least put in the release notes what operating systems/kernels are supported? At the very least try to avoid people breaking their working systems by updating to a release that doesn’t explicitly call out any caveats or expected regressions.
This isn’t debug party for no reason. Things will break this is not hardware to deploy in to prod.
Oh come on. Radxa/CIX surely aren’t treating development as a “debug party”. Someone knows what changes are going in and simply needs to get it communicated. If nobody even knows what changes are being made, well then this platform won’t ever make it to a “production” state.
Has anyone been able to get the LS2 idle power to actually go less than like 14W? I feel like I am missing something.
So far I haven’t seen anyone get the board to consume < 14W at idle, in any circumstance.
To be precise, in my case I’m measuring on the USB-C connector (I verified the meter’s accuracy previously and its error compared to my other voltmeters was less than 1%). What I got with the stock board with DDR5 at 5500, an SSD, fan at low speed, one port connected as GbE, and cix_audio_switch killed (since it’s making bursts) was between 10.3 and 10.5W:
After I set my DDR to 6400 and slightly overclocked and overvolted the DSU (1.3GHz/790mV ->1.5GHz/850mV), the idle consumption increased to 10.9-11.1W:
And with cpufreq set to “performance” (3.0/2.7/2.6/2.6 GHz), it reaches 11.3-11.5W:
I think it’s a bit high on the range of what should be expected, though it’s not dramatic either, it’s the same as what I’m measuring at the wall for my old Celeron J4105 (4 cores) with DDR4-2400 delivering a third of the bandwidth. Obviously both boards don’t exactly have the same performance, the O6 builds 4.3 times faster…
I suspect that the O6’s memory controller just doesn’t idle, and with 128 lanes at 3.2 GHz, it might start to consume quite a bit. Maybe one day we’ll have an opensource driver allowing us to adjust its speed at run time :-/
mines always 14W+ with pico psu, realistically with optimization I would think you could get down to 5W idle. I know my amd board will do that low with a 4750g.
I wanted to do an ARM mini rack for my house. I bought 2 or6 (16) (32) wanted to make the 16 a nas and the 32g a app server, and have it fail over to the other one. BPI-r4 for the router. I have 5 HDDs and 3 SSDs I wanted to attach to it. Been playing around just trying to get a stable server version that will use VPU/GPU
I’ve been testing an AMD RX 7900 XT, Radeon Pro W7700, and RX 6700 XT on my Orion O6, and all three fail, though the older card gets a little further along it seems before failure.
Debug info is here: https://github.com/geerlingguy/sbc-reviews/issues/62#issuecomment-2798278680
When I try loading amdgpu on Ubuntu 25.04, it completely locks up the system. No more response on keyboard/mouse, no update on built-in HDMI output, all my SSH sessions are dropped.
Anyone able to get AMD cards working on the latest SystemReady firmware? Or do I have to drop to a different firmware and/or OS to get them working?
I also just tested with an Nvidia 3080 Ti installed. Got some errors still (see https://github.com/geerlingguy/sbc-reviews/issues/62#issuecomment-2852490521), but one other weird issue: when I shut down the system, it was still powering the GPU, it seems—it was consuming 26W total power through the PSU, and luckily on the EVGA card I have, it ramped the fans to maximum thrust to make sure it wouldn’t overheat with the system off.
I remember that was an issue on older firmwares like with Warning, nearly cooked my AMD Pro while the Orion was turned off — is this still an issue on the SystemReady 9.0.0 firmware?
Seems like there was a link to this: https://github.com/radxa/edk2-platforms/commit/37aa58ffc9d5987d551d824870c1f05e717fc81b (but not sure if that’s in any active firmware).
I am having the same issue with my RX 6500XT. Bizarrely, I was able to get the card working perfectly ONLY if I loaded up the most recent RC of 6.15 with the 64K page size. The same kernel with a normal page size locked up.
Edit: this was using the most recent Ubuntu 25.10 Arm desktop image
We have no idea what code is in the SystemReady firmware, so it may not contain that fix.
0.3.0-1 BIOS should contain that commit. Need a bit more testing before we release it.
For now we only support the Debian system we provide with the BIOS released during the same time period. This is similar to our other system images, except for those, the bootloader is part of the image, while for O6 it is a separate BIOS.
Did you find a way to make the OPP work in 0.3.0 ? Last time I tried, anything I’d put there was completely ignored, both in the v21 and v26 formats, which is why I rolled back to 0.2.2.
Do you have more detailed description of your issue? I can forward that to CIX.
I should recheck for more accurate details, but from what I remember, changing anything in the opp_config file has strictly no effect on the CPU frequency. The tool does indeed produce a config block in the new format, but that one seems completely ignored at boot. I had to revert to bootloader1.img prior to pm_config 2.6 (that was pm_config 2.1) and same for the tool that generates the config block, for opp to be considered again.
I’m having the changes available here with a few info in the commit messages:
https://github.com/wtarreau/orion-o6-edk2-platforms/commits/20250412-fix-pmcfg-1/
https://github.com/wtarreau/orion-o6-edk2-non-osi/commits/20250412-fix-pmcfg-1/
Hoping this helps. BTW there might be trivial fixes you could be interested in there (such as the one that takes care of rebuilding csupm_bin_config). Thanks!
