Orion O6 Debug Party Invitation

Hahaha. I always look forward for your comment.

Miss you on x. :rofl:

CIX did not provide changelog for their BIOS updates. The only changelog we have is the one for the SDK I posted above.

1 Like

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.

1 Like

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.

3 Likes

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.

1 Like

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

1 Like

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!

Does old Platform/CIX/Sky1/PackageTool/Firmwares/bootloader1.img work with pm_config 2.6?

@geerlingguy, I managed to get AMD Radeon RX 6700 XT working with UEFI version 9.0.0 in ACPI mode and Ubuntu 25.04. However, I had to build my own kernel (I could provide instructions, if necessary) - if I am not mistaken, I applied the patch attached here on top of commit 7a13c14ee59d4f6c5f4277a86516cbc73a1383a8 (that is between tags v6.15-rc4 and v6.15-rc5).

Doom 3 (in the form of dhewm3), GravityMark, and Shadertoy in a browser seem to work fine. Actually, Doom 3 had some visual artifacts, but after I switched the OpenGL driver to Zink (with MESA_LOADER_DRIVER_OVERRIDE=zink as an environment variable) they disappeared. Setting RUSTICL_ENABLE=radeonsi let me run the Geekbench Compute benchmark, but it complained during the result validation at the end and performance was atrocious (more than an order of magnitude lower than expected). The older Clover OpenCL implementation led to a kernel panic.

Unfortunately not. The format of the structures has changed between the two. I can recheck the detail this week-end, but from memory I think there was a new field indicating the power level in the new format that was not there in the old one (only freq and voltage).

Another thing we’re really missing, maybe your contacts at CIX have an idea how to do this, is to mark certain OPP as “boost only”. This is super convenient, as it allows to declare some OPP that are possibly not stable and that are not used by default. The user can then set the max OPP they want then enable boost mode to benefit from them. It allows each board owner to try and choose the frequencies of their different clusters depending on what their boards support. For example, my first board was fine with the two big clusters at 3.0 while the second one supports only 3.1 and 2.7 for them (which confirms your concerns about 2.8 not being stable everywhere). This leaves quite a good margin from the new “stock 2.6” for most owners.

I had been using the boost mode quite a lot at the RK3399 era (particularly on my build farm for obvious reasons), and it was really appreciable, allowing the user to recover the unused (and understandable) safety margin from the stock device.

BTW, if you get the whole BIOS source code this month, maybe it will be easier for all of us to figure how to just add settings there like in any PC instead of flashing such parameters at build time, so that anyone can simply adapt to their device’s capabilities. I’m still super busy till the end of the month (new haproxy release) but after that I’m on holidays, I’ll have more time to dig :wink:

1 Like