ROCK 5B Debug Party Invitation

In comparison another recent Rockchip SBC: NanoPi R5S (RK3568 based and as such comparable to Rock 3A): idle temperature: 32.5°C, idle consumption: 2740mW (measured via same PowerBOX and 15W RPi USB-C charger).

RK3568 features exactly same cores (4 x Cortex-A55 / r2p0) and the device is running exactly same kernel with same relevant settings (Rockchip’s 5.10.66 BSP kernel with CONFIG_HZ=300) and exactly same userland (Focal Fossa arm64) so we’re seeing here the difference memory access and process node makes (RK3588 made in a much more advanced and expensive process).

Sysfs/Tested:  MIPS / Temp /  Watt
 408 /  410 :   336  37.6°C  3133mW
 600 /  600 :   486  40.0°C  3243mW
 816 /  820 :   651  41.0°C  3286mW
1104 / 1160 :   895  41.9°C  3410mW
1416 / 1480 :  1112  43.1°C  3510mW
1608 / 1680 :  1277  44.2°C  3663mW
1800 / 1840 :  1378  45.2°C  3773mW
1992 / 1940 :  1428  45.9°C  3800mW

The A55 in RK3588 at 400 MHz achieves an 380 7-ZIP MIPS score at a relative consumption of just 180 mW (3463-3280). The A55 in RK3568 scores only 336 at 390 mW (3133-2740). Higher memory latency resulting in lower ‘overall performance’ and worse process node in way higher consumption at the same time:

           RK3588       RK3568
  MHz   MIPS /  mW    MIPS /  mW
 ~405    380 / 183     336 /  393
  600    566 / 163     486 /  503
 ~855    798 / 200     651 /  546
~1455   1295 / 386    1112 /  770
~1665   1478 / 496    1277 /  923
 1840   1629 / 600    1378 / 1033
1 Like

@tkaiser could you please show me the outputs of your cpufreq settings and opp ? Mine limits at 2304 MHz but I’m seeing the dtb expose 2352 and 2400, I don’t understand what’s preventing them from being usable, they’re not based on a boost and I’m not seeing any message at boot. It’s the same for both debian and ubuntu.

Here’s what I’m having:

# grep '' /sys/devices/system/cpu/cpufreq/policy4/*
/sys/devices/system/cpu/cpufreq/policy4/affected_cpus:4 5
/sys/devices/system/cpu/cpufreq/policy4/cpuinfo_cur_freq:408000
/sys/devices/system/cpu/cpufreq/policy4/cpuinfo_max_freq:2304000
/sys/devices/system/cpu/cpufreq/policy4/cpuinfo_min_freq:408000
/sys/devices/system/cpu/cpufreq/policy4/cpuinfo_transition_latency:324000
/sys/devices/system/cpu/cpufreq/policy4/related_cpus:4 5
/sys/devices/system/cpu/cpufreq/policy4/scaling_available_frequencies:408000 600000 816000 1008000 1200000 1416000 1608000 1800000 2016000 2208000 2304000 
/sys/devices/system/cpu/cpufreq/policy4/scaling_available_governors:conservative ondemand userspace powersave performance schedutil 
/sys/devices/system/cpu/cpufreq/policy4/scaling_cur_freq:408000
/sys/devices/system/cpu/cpufreq/policy4/scaling_driver:cpufreq-dt
/sys/devices/system/cpu/cpufreq/policy4/scaling_governor:schedutil
/sys/devices/system/cpu/cpufreq/policy4/scaling_max_freq:2304000
/sys/devices/system/cpu/cpufreq/policy4/scaling_min_freq:408000
/sys/devices/system/cpu/cpufreq/policy4/scaling_setspeed:<unsupported>

Though the DTB gives me this:

# dtc -I dtb -O dts < rk3588-rock-5b.dtb |less
...
...
cluster1-opp-table {
           ...
           opp-2304000000 {
                    opp-supported-hw = <0xff 0x24>;
                    opp-hz = <0x00 0x89544000>;
                    opp-microvolt = <0xf4240 0xf4240 0xf4240 0xf4240 0xf4240 0xf4240>;
                    clock-latency-ns = <0x9c40>;
            };

            opp-2352000000 {
                    opp-supported-hw = <0xff 0x48>;
                    opp-hz = <0x00 0x8c30ac00>;
                    opp-microvolt = <0xf4240 0xf4240 0xf4240 0xf4240 0xf4240 0xf4240>;
                    clock-latency-ns = <0x9c40>;
            };

            opp-2400000000 {
                    opp-supported-hw = <0xff 0x80>;
                    opp-hz = <0x00 0x8f0d1800>;
                    opp-microvolt = <0xf4240 0xf4240 0xf4240 0xf4240 0xf4240 0xf4240>;
                    clock-latency-ns = <0x9c40>;
            };
    }

It’s obviously not dramatic, I’m just wondering why we’re seeing different behaviors.

Edit (since I cannot post anymore): There’s this “opp-supported-hw” field in the opp that lists values. I’m wondering if it’s relying on a CPU or board identifier (which could make sense, it’s possible that we have slightly different models since they’re early samples).

####### EDIT: Sorry for the mess below, but the forum refuses my new posts and asks me to wait 9 hours or to modify an existing post. That’s grossly stupid but I have no other solution #############

response to @tkaiser’s list of OPP below

Ah very interesting! I’m seeing this on mine:

# dmesg|grep cpu.*pvtm
[    2.606324] cpu cpu0: pvtm=1482
[    2.606542] cpu cpu0: pvtm-volt-sel=3
[    2.614206] cpu cpu4: pvtm=1722
[    2.618389] cpu cpu4: pvtm-volt-sel=5
[    2.626814] cpu cpu6: pvtm=1744
[    2.630998] cpu cpu6: pvtm-volt-sel=6

Yours says:

[    3.117399] cpu cpu0: pvtm=1528
[    3.117491] cpu cpu0: pvtm-volt-sel=5
[    3.124529] cpu cpu4: pvtm=1785
[    3.128495] cpu cpu4: pvtm-volt-sel=7
[    3.136234] cpu cpu6: pvtm=1782
[    3.140173] cpu cpu6: pvtm-volt-sel=7

And mine has a lower measured frequency on CPU4 than CPU6 so it would very likely point in this direction.

Now I understand better the difference I was seeing between the measured performance of both clusters, I didn’t notice that the second one was indeed really slightly faster:

# grep '' /sys/devices/system/cpu/cpufreq/policy*/scaling_available_frequencies
/sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies:408000 600000 816000 1008000 1200000 1416000 1608000 1800000 
/sys/devices/system/cpu/cpufreq/policy4/scaling_available_frequencies:408000 600000 816000 1008000 1200000 1416000 1608000 1800000 2016000 2208000 2304000 
/sys/devices/system/cpu/cpufreq/policy6/scaling_available_frequencies:408000 600000 816000 1008000 1200000 1416000 1608000 1800000 2016000 2208000 2352000 

So there’s something related to measured voltages. Note that this does happen both with a 12Vin PSU and a 5V one.

@hipboi could this have something to do with a possibly insufficient resistor divider precision in a voltage regulator circuit, or with one of these regs themselves ? I can measure the voltages if needed, I’m just unsure where to check as I cannot precisely identify the chip locations on the board. Just let me know if you’d like me to check certain things.

I would say by the look of things the mounting points to cpu are a flaw as think others can see that its just so much on a single corner of the cpu, its never going to be really great.
One thing though is the RK3588 runs really cool and think it has took some by surprise how cool.
I didn’t realise it was a tri cluster like some of the current top of the range socs with the newer Xcores, mid core and then the little.
It will prob play havoc with many benchmarks for single core as likely a wrong core will be chosen for bench.
But this is a Dev sample and a pre-release so nothing is set in stone as of yet and what pre-release samples are for.
The fan noise is because its running @ 100% on the wrong header as the fan is a dupont with the wrong type of header for the onboard PWM fan control (Its is a 5v fan on 5v yeah?).
Even the mounting holes might not be much of a thing as it could necessitate a custom heatsink that has sprung legs spidering out to the board mounts.
The heatsink/fan is an extra so if more needs to be done and charged then it doesn’t effect the Rock5b base price.

@willy what temps are you getting as with the 7zip @ 2400 @tkaiser is only getting 35.2°C and generally his temps are extremely low generally that sort of range is often idle temps not a stress test :slight_smile:

Sure:

root@rock-5b:~# ls -ld /proc/device-tree/cluster0-opp-table/opp-*
drwxr-xr-x 2 root root 0 Jul  5 09:40 /proc/device-tree/cluster0-opp-table/opp-1008000000
drwxr-xr-x 2 root root 0 Jul  5 09:40 /proc/device-tree/cluster0-opp-table/opp-1200000000
drwxr-xr-x 2 root root 0 Jul  5 09:40 /proc/device-tree/cluster0-opp-table/opp-1416000000
drwxr-xr-x 2 root root 0 Jul  5 09:40 /proc/device-tree/cluster0-opp-table/opp-1608000000
drwxr-xr-x 2 root root 0 Jul  5 09:40 /proc/device-tree/cluster0-opp-table/opp-1800000000
drwxr-xr-x 2 root root 0 Jul  5 09:40 /proc/device-tree/cluster0-opp-table/opp-408000000
drwxr-xr-x 2 root root 0 Jul  5 09:40 /proc/device-tree/cluster0-opp-table/opp-600000000
drwxr-xr-x 2 root root 0 Jul  5 09:40 /proc/device-tree/cluster0-opp-table/opp-816000000
-r--r--r-- 1 root root 0 Jul  5 09:43 /proc/device-tree/cluster0-opp-table/opp-shared

root@rock-5b:~# ls -ld /proc/device-tree/cluster1-opp-table/opp-*
drwxr-xr-x 2 root root 0 Jul  5 09:40 /proc/device-tree/cluster1-opp-table/opp-1008000000
drwxr-xr-x 2 root root 0 Jul  5 09:40 /proc/device-tree/cluster1-opp-table/opp-1200000000
drwxr-xr-x 2 root root 0 Jul  5 09:40 /proc/device-tree/cluster1-opp-table/opp-1416000000
drwxr-xr-x 2 root root 0 Jul  5 09:40 /proc/device-tree/cluster1-opp-table/opp-1608000000
drwxr-xr-x 2 root root 0 Jul  5 09:40 /proc/device-tree/cluster1-opp-table/opp-1800000000
drwxr-xr-x 2 root root 0 Jul  5 09:40 /proc/device-tree/cluster1-opp-table/opp-2016000000
drwxr-xr-x 2 root root 0 Jul  5 09:40 /proc/device-tree/cluster1-opp-table/opp-2208000000
drwxr-xr-x 2 root root 0 Jul  5 09:40 /proc/device-tree/cluster1-opp-table/opp-2256000000
drwxr-xr-x 2 root root 0 Jul  5 09:40 /proc/device-tree/cluster1-opp-table/opp-2304000000
drwxr-xr-x 2 root root 0 Jul  5 09:40 /proc/device-tree/cluster1-opp-table/opp-2352000000
drwxr-xr-x 2 root root 0 Jul  5 09:40 /proc/device-tree/cluster1-opp-table/opp-2400000000
drwxr-xr-x 2 root root 0 Jul  5 09:40 /proc/device-tree/cluster1-opp-table/opp-408000000
drwxr-xr-x 2 root root 0 Jul  5 09:40 /proc/device-tree/cluster1-opp-table/opp-600000000
drwxr-xr-x 2 root root 0 Jul  5 09:40 /proc/device-tree/cluster1-opp-table/opp-816000000
-r--r--r-- 1 root root 0 Jul  5 09:40 /proc/device-tree/cluster1-opp-table/opp-shared

root@rock-5b:~# ls -ld /proc/device-tree/cluster2-opp-table/opp-*
drwxr-xr-x 2 root root 0 Jul  5 09:40 /proc/device-tree/cluster2-opp-table/opp-1008000000
drwxr-xr-x 2 root root 0 Jul  5 09:40 /proc/device-tree/cluster2-opp-table/opp-1200000000
drwxr-xr-x 2 root root 0 Jul  5 09:40 /proc/device-tree/cluster2-opp-table/opp-1416000000
drwxr-xr-x 2 root root 0 Jul  5 09:40 /proc/device-tree/cluster2-opp-table/opp-1608000000
drwxr-xr-x 2 root root 0 Jul  5 09:40 /proc/device-tree/cluster2-opp-table/opp-1800000000
drwxr-xr-x 2 root root 0 Jul  5 09:40 /proc/device-tree/cluster2-opp-table/opp-2016000000
drwxr-xr-x 2 root root 0 Jul  5 09:40 /proc/device-tree/cluster2-opp-table/opp-2208000000
drwxr-xr-x 2 root root 0 Jul  5 09:40 /proc/device-tree/cluster2-opp-table/opp-2256000000
drwxr-xr-x 2 root root 0 Jul  5 09:40 /proc/device-tree/cluster2-opp-table/opp-2304000000
drwxr-xr-x 2 root root 0 Jul  5 09:40 /proc/device-tree/cluster2-opp-table/opp-2352000000
drwxr-xr-x 2 root root 0 Jul  5 09:40 /proc/device-tree/cluster2-opp-table/opp-2400000000
drwxr-xr-x 2 root root 0 Jul  5 09:40 /proc/device-tree/cluster2-opp-table/opp-408000000
drwxr-xr-x 2 root root 0 Jul  5 09:40 /proc/device-tree/cluster2-opp-table/opp-600000000
drwxr-xr-x 2 root root 0 Jul  5 09:40 /proc/device-tree/cluster2-opp-table/opp-816000000
-r--r--r-- 1 root root 0 Jul  5 09:43 /proc/device-tree/cluster2-opp-table/opp-shared

root@rock-5b:~# grep '' /sys/devices/system/cpu/cpufreq/policy4/*
/sys/devices/system/cpu/cpufreq/policy4/affected_cpus:4 5
/sys/devices/system/cpu/cpufreq/policy4/cpuinfo_cur_freq:408000
/sys/devices/system/cpu/cpufreq/policy4/cpuinfo_max_freq:2400000
/sys/devices/system/cpu/cpufreq/policy4/cpuinfo_min_freq:408000
/sys/devices/system/cpu/cpufreq/policy4/cpuinfo_transition_latency:324000
/sys/devices/system/cpu/cpufreq/policy4/related_cpus:4 5
/sys/devices/system/cpu/cpufreq/policy4/scaling_available_frequencies:408000 600000 816000 1008000 1200000 1416000 1608000 1800000 2016000 2208000 2400000 
/sys/devices/system/cpu/cpufreq/policy4/scaling_available_governors:conservative ondemand userspace powersave performance schedutil 
/sys/devices/system/cpu/cpufreq/policy4/scaling_cur_freq:408000
/sys/devices/system/cpu/cpufreq/policy4/scaling_driver:cpufreq-dt
/sys/devices/system/cpu/cpufreq/policy4/scaling_governor:performance
/sys/devices/system/cpu/cpufreq/policy4/scaling_max_freq:408000
/sys/devices/system/cpu/cpufreq/policy4/scaling_min_freq:408000
/sys/devices/system/cpu/cpufreq/policy4/scaling_setspeed:<unsupported>

2304 for example is defined in DT but also missing from my list of available frequencies. So it seems there’s another place determining which freqs get activated and which not…

1 Like

I think the opp table is sort of bogus a bit like the amlogic where its the internal mcu blob that is really at work.

The temp you referred to was cearly labeled ‘single A76 core running 7-ZIP benchmark’, multi-threaded results were posted already yesterday.

The fansink on my board fits really tight, there’s an annoying fan spinning at maximum rpm and I operate my board upright standing to let convection jump in. And as you can see from the consumption measurements RK3588 is a different beast than the SoCs we were used to deal with in the past!

BTW: I really don’t get all this babbling polluting this thread. These are dev samples and Radxa guys looked into drawers and put something on that works. The final product will be shipped with a different heatsink anyway…

3 Likes

I don’t remember the measure but they were in that range as well. The CPU is barely warm when the fan spins. The CPU doesn’t consume much, which also explains why even with an uneven surface it still cools well.

Quite frankly, I’m not worried about this part at all. When you see the number of boards sold for which there are no holes at all, and which rely on you gluing the heatsink on top of the CPU, we already have more options there so let’s not turn this limitation into a big problem. It seems that there are little more options to place all components on that board anyway, so the CPU could hardly be more centered. Maybe one option could be to try to slightly rotate the heat sink by placing the holes differently but that’s not easy. I really think that just using a rubber pad of the same height at one extremity will completely solve the problem.

Stick on would do as that is another option with the temps your posting, did you find any other fans to stick on the real fan header. I have a few here but still waiting for delivery.
Its prob that thermal pad that has made things worse willy.

I am frankly uncomfortable asking
but can you swing the returns
cat /sys/kernel/debug/regulator/regulator_summary
cat /sys/kernel/debug/pinctrl/ * /gpio-ranges
cat /sys/kernel/debug/pinctrl/ * /pinmux-pins
cat /sys/kernel/debug/pinctrl/ * /pinmux-functions
cat /sys/kernel/debug/pinctrl/ * /pingroups
cat /sys/kernel/debug/pinctrl/ * /pinconf-pins
cat /sys/kernel/debug/pinctrl/ * /pinconf-groups
ou similar

I’m having a 16GB model with the following silkscreened on it: ‘2022.05.19 ROCK 5B V1.3’ (looks exactly like the pictures in 1st post of this thread except of RK3588 which is a different revision):

As a quick reference dmesg (only interesting stuff I found is around the hyst lines) and DTS from me.

2 Likes
root@rock-5b:/home/rock# ( cat /sys/kernel/debug/regulator/regulator_summary ; grep -R . /sys/kernel/debug/pinctrl/ ) | curl -s -F 'f:1=<-' ix.io
http://ix.io/41F1

BTW: grep -R . /sys/kernel/debug/ freezes the board :slight_smile:

1 Like

Could you please confirm if PCI express indeed works at 3.0 version speeds?

Those devices with black metal case must be nanopi’s R5S or R6S.

R5S as mentioned above when comparing performance/consumption between RK3568 and RK3588.

I’m about to setup a nice 2.5GbE ‘LAN party’ with those 3 ARM boards and 2 MacBooks with RTL8156 dongles :slight_smile:

BTW: never heard of R6S but there’s a little room for speculation about a soon to be announced NanoPi R3S (also based on RK3568).

OK, @willy (who can’t post here since registered just yesterday) pointed me in this direction:

R6S based on RK3588S

Sadly, the contained kernel 4.4 is already EOL:

[2022-07-05T18:44:44+0200] ueberall_l@desktop01:/tmp% wget "https://github.com/radxa/debos-radxa/releases/download/20220701-0727/rockpi-s-ubuntu-focal-server-arm64-20220701-0851-gpt.img.xz"
[…]
[2022-07-05T18:45:47+0200] ueberall_l@desktop01:/tmp% xz -dv rockpi-s-ubuntu-focal-server-arm64-20220701-0851-gpt.img.xz
rockpi-s-ubuntu-focal-server-arm64-20220701-0851-gpt.img.xz (1/1)
  100 %       140,6 MiB / 906,0 MiB = 0,155    92 MiB/s       0:09
[2022-07-05T18:45:59+0200] ueberall_l@desktop01:/tmp% fdisk -l ./rockpi-s-ubuntu-focal-server-arm64-20220701-0851-gpt.img
Disk ./rockpi-s-ubuntu-focal-server-arm64-20220701-0851-gpt.img: 905,101 MiB, 950000128 bytes, 
1855469 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 34D6A485-96AB-4EAE-B781-BEA9FCBC918D

Device                                                       Start     End Sectors  Size Type
./rockpi-s-ubuntu-focal-server-arm64-20220701-0851-gpt.img1  32768  262143  229376  112M EFI System
./rockpi-s-ubuntu-focal-server-arm64-20220701-0851-gpt.img2 262144 1855435 1593292  778M Linux filesystem
[2022-07-05T18:46:07+0200] ueberall_l@desktop01:/tmp% mkdir ./rockpi-s-ubuntu-focal-server-arm64-20220701-0851-gpt
[2022-07-05T18:46:46+0200] ueberall_l@desktop01:/tmp% sudo mount -t auto -o loop,offset=$((262144*512)) ./rockpi-s-ubuntu-focal-server-arm64-20220701-0851-gpt.img ./rockpi-s-ubuntu-focal-server-arm64-20220701-0851-gpt
[sudo] password for ueberall_l:
[…]
[2022-07-05T18:49:16+0200] ueberall_l@desktop01:/tmp% dpkg-query -W --admindir=./rockpi-s-ubuntu-focal-server-arm64-20220701-0851-gpt/var/lib/dpkg >./rockpi-s-ubuntu-focal-server-arm64-20220701-0851-gpt.dpkg-query.txt
[2022-07-05T18:50:11+0200] ueberall_l@desktop01:/tmp% grep ^linux- ./rockpi-s-ubuntu-focal-server-arm64-20220701-0851-gpt.dpkg-query.txt               
linux-4.4-rock-pi-s-latest:arm64        4.4.143-69-rockchip
linux-base      4.5ubuntu3
linux-firmware-image-4.4.143-69-rockchip-g8ccef796d27d:arm64    4.4.143-69-rockchip
linux-headers-4.4.143-69-rockchip-g8ccef796d27d:arm64   4.4.143-69-rockchip
linux-image-4.4.143-69-rockchip-g8ccef796d27d:arm64     4.4.143-69-rockchip
[2022-07-05T18:51:35+0200] ueberall_l@desktop01:/tmp%

Given that competing SBC have patches for the 5.15 kernel (and newer ones) which also slowly find their way upstream (if they have not been included already), I’m afraid that this is simply way too old. The system might run, but kernel 4.4 was published 6.5 years ago and isn’t tested against current software packages/applications (because it’s EOL) unless you manage to pay for it.

Please at least consider including a kernel that is not already EOL or won’t be EOL by the time the hardware will be available (IMHO, even kernel 4.9 will not really fit the bill, it’ll require kernel 4.14 or newer).

EDIT: As pointed out below by tkaiser, I downloaded the wrong image, so the rant is misplaced and does not apply to the ROCK5B (only to other/older models). :sweat_smile:

But we’re talking about Rock 5B / RK3588 here. And deal with a forward ported version 5.10 from Rockchip (not to be confused with official 5.10 LTS kernel which is a different thing).

1 Like

everyone does what they want, however when you get targets for free you can test it with the ammunition that come with it.

My bad! Using the correct image, you’re presented with

[2022-07-05T19:47:05+0200] ueberall_l@desktop01:/tmp% grep ^linux- ./rock-5b-ubuntu-focal-server-arm64-20220701-0826-gpt.dpkg-query.txt
linux-base      4.5ubuntu3
linux-headers-5.10.66-11-rockchip-geee2b32138fd:arm64   5.10.66-11-rockchip
linux-image-5.10.66-11-rockchip-geee2b32138fd:arm64     5.10.66-11-rockchip
[2022-07-05T19:47:32+0200] ueberall_l@desktop01:/tmp%

That’s an acceptable starting point. If you can trust the version number, that is. (EDIT: tkaiser is simply too fast to reply :grin:)

Well, the information about which kernel version we’re dealing with Rock 5B is here multiple times in this thread (part of sbc-bench output for example). But it’s important to understand how this kernel got to this version since as already said: it’s forward ported from 2.6.32 on and not the official 5.10 LTS kernel.

1 Like