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).
Orion O6 Debug Party Invitation
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
Is uart4 “Power management, voltage, and frequency monitoring” planned on being used? I’ve never seen any output there. Is this actually active but is interactive?
Also, what is the use for the BOOT_STRAP pin (next to the cluster of uart pins)?
Regarding BOOT_STRAP:
3 Likes
https://browser.geekbench.com/v6/compute/3962520
10249 - Vulkan Score
(compared to ~3500 on RK3588)
2 Likes
Is the Debian 12 DT image suppoused to be unstable?
Right now, flashing to image to a NVME and booting from it it works for a while until it crashes and eventually stops working.
Sometime it freeses with visual artifacts as when you have a memory problem on a unstable computer.
After reinstalling the image i try to run memtester, screen glitched out and lost signal half way trought it. Rebooted and it freezed on the desktop.
God damn it $300 for the board, $90 for shipping and an additional suprise $110 Fedex charged me at my door.
I tried with a psu, then with a 90W USB-C and two different m.2 at this point.
Just opened chromium on a fresh image 
There is a stock distro that will give video out in ACPI mode so i could test with something else?
That doesn’t smell good 
Regarding memtester, you can try to pin it to one CPU core to see if that changes anything.
The big cores are 0,9,10,11; the medium cores are 5,6,7,8. The little cores are 1,2,3,4.
You can run for example: taskset -c 1 ./memtester to run it on a little core and see if it
crashes or works. Normally memory tests are agnostic to the CPU’s performance so a little
core should suffice and will draw less juice. If it passes, it would indicate that the RAM is not
at fault. Then you can retry on other cores, then multiple in parallel. If it only fails when using
multiple cores, it could be a power or cooling issue (e.g. heatsink improperly installed). But I
tend to think more about a power issue based on your description (maybe the USB cable itself if you’re using the same with various PSUs).
2 Likes
Ok doing memtester runs only by ssh without anything else attached.
without taskset it freezes and stop responding like after like 2 minutes in.
Did a run on core 1 for 16386mb and it completed OK (this takes a lot of time)
Then tryied to 28700mb and it got “killed” when it tried to mlock, its running now for 28000mb.
Btw, i already checked the cooler and its fine.
EDIT: Ok 28000mb memtest completed on core 1 OK… well ill test one of the middle cores, then core 0.
Also the two m.2 screws came loose inside were the motherboard was, not sure if thats enoght to do damage during shipping.
1 Like