Orion O6 Debug Party Invitation

#299

When firmware and kernel support are done right I do not need schematics to run system.

When it comes to EDK2: as above.

When it comes to kernel: I already built kernels which work on NVidia Grace or Graviton 4. They are Armv9 systems, existed before you announced that beta program. Your board is capable of running mainline kernel. I would not even run your 6.1.44 kernel as I do not use SBC vendor kernels.

DRAM speed capped to 4266 MT/s on O6? thread shows that SoC is unable to make use of that bandwidth.

And “dram is capable so why not” is bullshit. I had a device with 400MHz SoC which had DDR2 chips capable of running at 800MHz. And was used at less than half of memory bandwidth.

1 Like
#300

Are you serious? I was willing to look past the source code delay and the DRAMa, but advertising a clock speed that you KNOW is incorrect is on another level

1 Like
#301

Bait and switch fraud is illegal.

#302

Well, I wouldn’t necessarily be so eager as you to sling around legal terms. I doubt Radxa expected the P1 to not reach the advertised frequency. But still, continuing to advertise it as such is really reprehensible…

1 Like
#303

hmmm guys you just edited the text on the front page to 2.6ghz but forgot to replace the image.

2 Likes
#304

For reference, the image with all the cores in a graphical layout:

00%E2%80%AFAM
Screenshot 2025-03-26 at 10.13.00 AM.jpg2562×1442 409 KB

I had also assumed the lower clocks were conservative during bringup, but now hearing Cix is nervous about overclocks, and thermal limits are reached at slight overclocks, it seems these chips are definitely coming off the line without as much performance capability as was originally advertised.

Better to be brutally conservative initially, and ‘bless’ people with much faster clocks, it is not as fun to buy something based on hopes and dreams :frowning:

4 Likes
#305

There seems to be two versions, CD8180 and a CP8180, maybe the speeds got mixup?

#306

The one in Orion is the most performant one the others are derivatives

#307

Given the new website numbers (but not the image), when are we getting an update to at least hit the shifted goalposts? Bigs are still only up to 2.5GHz (versus now 2.6 advertised) and the mediums are only up to 2.3 (versus now 2.4 advertised).

#308

I just noticed that despite sitting at 0% utilization on all cores, the load averages (1, 5 and 15 minute) sit at 4. Not sure how that’s possible. Some poorly-behaved not-yet-upstreamed/closed-source drivers that radxa has added to the kernel?

#309

There is clock settings in BIOS under device manager. Check if you set to 2.5G.

#310

Is a bug in CIX’s kernel and is only a display error. Real load is not 4.

#311

Usually this is caused by hung modules or drivers not finishing loading, sometimes even improper reference counting. Most commonly the culprits are found by looking for ‘D’ state kthreads. Here on first try I’m seeing 4 such threads, which look like plausible candidates and would explain the ‘4’:

willy@orion-o6:~$ ps auxw | grep -v grep | grep '  D  '
root          89  0.0  0.0      0     0 ?        D    Mar24   0:00 [bbox_main]
root          90  0.0  0.0      0     0 ?        D    Mar24   0:00 [bbox_cleartext]
root         137  0.0  0.0      0     0 ?        D    Mar24   0:00 [chre_kthread]
root         138  0.0  0.0      0     0 ?        D    Mar24   0:00 [scp_power_reset]

But it’s not a “display error”, it’s really the load as reported everywhere by the systems and used in internal calculations. For example you can have much slower (or even stopped) email delivery when running on such a system because the mail server throttles under load to limit what it believes is its own impact on the system. Similarly, “make” can refuse to start until the load average goes below a certain value, which can for example prevent from building certain projects making use of the “-l” parameter.

In general these are not critical but they do cause annoyances and dysfunction. And indeed they’re definitely bugs.

2 Likes
#312

What’s the current gap to being able to boot a stock upstream 6.14 kernel, if we used the radxa device tree? Would we just loose accessories like audio, GPU, NPU? For use-cases where we only need the basic system (and ethernet) working, it would be nice to get off this old custom kernel.

1 Like
#313

Switch from DT to ACPI and 6.14 should work for you.

DT from 6.1.44 kernel assumes several devices which are not present in mainline so it is not granted that it will work.

3 Likes
#314

I’m using mainline in about half of the boots on my board and remember why I left the BSP by default: the PWM fan is not accessible in mainline, and my ears appreciate when I slow it down. The rest looks like it’s working (PCIe, USB, network, cpufreq, etc). Note that I’m not using audio nor video on the board, nor on any board by the way, I’m not a good tester for such things.

1 Like
#315

The PWM fan isn’t accessible w/ device tree in the radxa-provided Fedora 41 image, either. At least there it runs really slow (perhaps it doesn’t even ramp up, I haven’t noticed).

#316

Seriously… are you really not able to understand the difference between powering some ‘gamer PC’ with a multiple hundred watts absolutely inefficient ATX PSU vs. something powered by an efficient USB PD power brick?

#317

Average load on Linux is not CPU utilization: https://www.brendangregg.com/blog/2017-08-08/linux-load-averages.html

As such the ‘load’ is ‘real’.

BTW: when do you guys provide a fix for the stupidly high idle consumption and ship a 6.6 BSP kernel? Will it happen within the next four weeks?

#318

Currently waiting for their March SDK release before releasing a new image, as there are some issues with the Feb release. High idle should be fixed but will double check.

6.6 is not available to us before May.

2 Likes