Orion O6 Debug Party Invitation

[willy]

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

[Jeremy_Linton]

“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.

[Jeremy_Linton]

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.

[tkaiser]

the DMI BIOS data is incomplete around build dates and versions, and that makes it difficult to validate if the latest FW is installed

@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?

[RadxaYuntian]

@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

This will be fixed in next release.

Feel free to create issues under edk2-cix repo.

[washley]

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)?

[Mario]

Regarding BOOT_STRAP:

Orion O6 Debug Party Invitation

While playing with the firmware, I also noticed that there’s support for the fastboot protocol: You will need to have an NVME drive plugged in (we won’t be writing anything to it), otherwise the fastboot app will refuse to load. Open your build_and_package.sh: add local FASTBOOT_LOAD=nvme append -D TOKEN_SETUP_SUPPORT=TRUE to the EDK2 build command Build and flash the generated firmware as usual. There will appear a new setup menu: CIX System Manager. Open it, then go to Soc …