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?
Orion O6 Debug Party Invitation
There is clock settings in BIOS under device manager. Check if you set to 2.5G.
Is a bug in CIX’s kernel and is only a display error. Real load is not 4.
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
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
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
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
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).
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?
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?
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
Seems to be fraud according european law. Selling something not with advertised specification.
What about the other disappointed ones. Will you offer a discount , if we don’t ship back?
regards
Uli
1 Like
Mine are working fine at 3.1 (big) and 2.6 (med). I’m quite impressed by the openssl rsa2048 speed test there! It gives me 7744 sign/s. For reference, my 6700K @4.4 GHz gives me 9020. Thus at this speed, the board is as fast as my skylake at 3.8 GHz.
I’m back to trying to experiment with DRAM frequencies. I noticed that the CIX setup panel that appears with -D TOKEN_SETUP_SUPPORT=TRUE allows plenty of stuff including priorities on different ports, but whatever I set there is ignored. I suspect that the O6 init code ignores what is configured there. I’ll report back later.
1 Like
Have you messed with the voltages too? I had to increase them up to ~ 1100 mV in order to complete the GB6 run.
Slightly only. I remained within the limits:
--- edk2-non-osi/Platform/CIX/Sky1/PackageTool/pm_config/opp_config_custom.h 2025-03-29 20:05:37.752470267 +0100
+++ edk2-platforms/Platform/Radxa/Orion/O6/pm_config/opp_config_custom.h 2025-03-29 17:43:37.838172574 +0100
@@ -7,7 +7,7 @@
#include "pm_export_config.h"
#include "opp_config.h"
-#define PM_OPP_TABLE_CONFIG 0
+#define PM_OPP_TABLE_CONFIG 1
#if PM_OPP_TABLE_CONFIG
/* V1.1, DFS */
@@ -48,22 +48,24 @@
};
static domain_opp_config_t dxs_gb0 = {
- .size = 7,
- .sustained_idx = 6,
+ .size = 9,
+ .sustained_idx = 8,
.opp_table = {
{ .level = 800UL, .voltage = 730 },
{ .level = 1200UL, .voltage = 750 },
{ .level = 1500UL, .voltage = 750 },
{ .level = 1800UL, .voltage = 790 },
{ .level = 2200UL, .voltage = 790 },
- { .level = 2300UL, .voltage = 850 },
- { .level = 2400UL, .voltage = 920 }, /* sustained */
+ { .level = 2400UL, .voltage = 850 },
+ { .level = 2800UL, .voltage = 950 }, /* sustained */
+ { .level = 3000UL, .voltage = 950 }, /* sustained */
+ { .level = 3100UL, .voltage = 990 }, /* sustained */
},
};
static domain_opp_config_t dxs_gb1 = {
- .size = 7,
- .sustained_idx = 6,
+ .size = 9,
+ .sustained_idx = 8,
.opp_table = {
{ .level = 800UL, .voltage = 730 },
{ .level = 1200UL, .voltage = 750 },
@@ -71,13 +73,15 @@
{ .level = 1800UL, .voltage = 790 },
{ .level = 2200UL, .voltage = 790 },
{ .level = 2400UL, .voltage = 850 },
- { .level = 2500UL, .voltage = 920 }, /* sustained */
+ { .level = 2800UL, .voltage = 950 }, /* sustained */
+ { .level = 3000UL, .voltage = 950 }, /* sustained */
+ { .level = 3100UL, .voltage = 990 }, /* sustained */
},
};
static domain_opp_config_t dxs_gm0 = {
- .size = 7,
- .sustained_idx = 6,
+ .size = 8,
+ .sustained_idx = 7,
.opp_table = {
{ .level = 800UL, .voltage = 730 },
{ .level = 1200UL, .voltage = 750 },
@@ -85,21 +89,23 @@
{ .level = 1800UL, .voltage = 790 },
{ .level = 2000UL, .voltage = 790 },
{ .level = 2200UL, .voltage = 850 },
- { .level = 2300UL, .voltage = 890 }, /* sustained */
+ { .level = 2400UL, .voltage = 920 }, /* sustained */
+ { .level = 2600UL, .voltage = 950 }, /* sustained */
},
};
static domain_opp_config_t dxs_gm1 = {
- .size = 7,
- .sustained_idx = 6,
+ .size = 8,
+ .sustained_idx = 7,
.opp_table = {
{ .level = 800UL, .voltage = 730 },
{ .level = 1200UL, .voltage = 750 },
{ .level = 1500UL, .voltage = 750 },
{ .level = 1800UL, .voltage = 790 },
{ .level = 2000UL, .voltage = 790 },
- { .level = 2100UL, .voltage = 850 },
- { .level = 2200UL, .voltage = 890 }, /* sustained */
+ { .level = 2200UL, .voltage = 850 },
+ { .level = 2400UL, .voltage = 920 }, /* sustained */
+ { .level = 2600UL, .voltage = 950 }, /* sustained */
},
};
I’ve read that cppc supports “boost” mode on recent kernels >= 5.8, but I don’t know how it needs to be declared in the ACPI tables, all I found is that it’s detected when there’s a difference between a nominal_freq and a maximum_freq, though I found none of these here. This could be useful to reserve some OPP for manual OC and experimentation.
Also, I have not run GB, only some local builds, openssl speed and CPU/DRAM perf tests
1 Like
“Take RK3588 for instance. The display controller (VOP2) depends on pixel clocks exposed by the global clock & reset unit (CRU). VOP2 needs to be able to enable this particular clock and set its frequency based on whatever video mode is used for the corresponding output port.”
But as I know your aware, this isn’t a problem specific to Arm SoC’s. Its not at all uncommon for devices to have firmware/device managed mailbox drivers which send messages to microcontrollers embedded in the device or somewhere else on the platform to change clocks like this. ACPI provides DSM() as a method to achieve this in a device specific manner, or the platform/device and provide direct HW mailboxes to do the operation. After all this is largely how many ‘DT’ devices behave (ex the rpi, which uses the GPU to control voltage/clocks for some things). Then as long as the mailbox remains consistent the SoC/Board provider can change the underlying “change_video_mclock()” function without updating the OS.
Hi,
So I’m running the F42 beta on this board in ACPI mode, and while it tends to work far far far better than I expected, and I’ve seen from most !server grade products a few things poped out:
First is the EFI/RTC service seems to be having problems (possibly due to the 48bit vamap?)
[ 0.860750] CPU: 7 UID: 0 PID: 1 Comm: swapper/0 Tainted: G S I ------- — 6.14.0-63.fc42.aarch64 #1
[ 0.860755] Tainted: [S]=CPU_OUT_OF_SPEC, [I]=FIRMWARE_WORKAROUND
[ 0.860757] Hardware name: Radxa Computer (Shenzhen) Co., Ltd. Radxa Orion O6/Radxa Orion O6, BIOS 1.0 Jan 1 1980
[ 0.860760] pstate: 61000009 (nZCv daif -PAN -UAO -TCO +DIT -SSBS BTYPE=–)
[ 0.860763] pc : __efi_queue_work+0xe4/0x120
[ 0.860766] lr : __efi_queue_work+0xd0/0x120
[ 0.860769] sp : ffff80008007ba10
[ 0.860770] x29: ffff80008007ba10 x28: 0000000000000000 x27: 0000000000000007
[ 0.860775] x26: ffff8000829ef03c x25: ffff800081f5ab40 x24: ffff0000833385a8
[ 0.860779] x23: ffff80008186e328 x22: 0000000000000000 x21: ffff80008007babc
[ 0.860783] x20: ffff80008007bac8 x19: ffff8000843e04f8 x18: 0000000000000000
[ 0.860787] x17: 00000000a7e70532 x16: 00000000edd0963a x15: ffff0000808fcbd0
[ 0.860791] x14: ffff80008349fab0 x13: 0000000000000001 x12: 00000000334d65a6
[ 0.860794] x11: 0000000000000180 x10: 05d9de8a67bf9830 x9 : ffff80008156b08c
[ 0.860798] x8 : ffff0000808ff028 x7 : ffff0000808fcb00 x6 : 0000000000000010
[ 0.860802] x5 : 0000000000000000 x4 : ffff807f54ef8000 x3 : 0000000000000000
[ 0.860805] x2 : 0000000000000000 x1 : 8000000000000015 x0 : 8000000000000015
[ 0.860810] Call trace:
[ 0.860812] __efi_queue_work+0xe4/0x120 §
[ 0.860815] virt_efi_get_time+0x60/0xc0
[ 0.860819] efi_rtc_probe+0x58/0x180
[ 0.860826] platform_probe+0x70/0xe8
[ 0.860831] really_probe+0xc8/0x3a0
[ 0.860835] __driver_probe_device+0x84/0x160
[ 0.860839] driver_probe_device+0x40/0x128
[ 0.860843] __driver_attach+0xd0/0x1f0
[ 0.860847] bus_for_each_dev+0x84/0x100
[ 0.860851] driver_attach+0x2c/0x40
[ 0.860854] bus_add_driver+0x158/0x280
[ 0.860858] driver_register+0x70/0x140
[ 0.860862] __platform_driver_probe+0x54/0xe0
[ 0.860865] efi_rtc_driver_init+0x2c/0x40
[ 0.860868] do_one_initcall+0x64/0x320
[ 0.860873] do_initcalls+0x194/0x1d8
[ 0.860879] kernel_init_freeable+0x1b8/0x218
[ 0.860884] kernel_init+0x28/0x158
[ 0.860890] ret_from_fork+0x10/0x20
Second, the DMI BIOS data is incomplete around build dates and versions, and that makes it difficult to validate if the latest FW is installed.
The CPPC seems to be having ‘boost’ issues around the mismatched big/medium cores. I might suggest adding CPPC ‘turbo’ states to the mid/little cores just to keep the kernel from being unhappy about the asymmetry.
Running TMON, acpitz1 seems to be glitching the thermal state to 1200C once in a while, this seems to correspond to the clocks being cranked to minimum. I’m guessing this and the boost states above are a large part of the perf issues on the board.
The machine seems to be able to go into some suspend state, but then it can’t resume (not tried tracking this down at all).
The DT has coresight information, but its missing from the acpi DSDT/SSDT tables. I might have taken a crack at fixing this, if it were obvious where to post fixes.
3 Likes
@RadxaYuntian is there some working way to address such issues? I second that UEFI info like this is not really helpful:
Vendor: Radxa Computer (Shenzhen) Co., Ltd.
Version: 1.0
Release Date: Jan 1 1980
BIOS Revision: 1.0
Also wrt coresight information Jeremy references… have you and/or Cix enabled any way to let community (now also ARM Holdings Ltd. included) jump in fixing things?
2 Likes