ROCK 5B Debug Party Invitation

I don’t think its the fan that is the real problem in the long run, as if you draw a diagonal from the mounting holes that is where the pressure point and fulcrum will be. You could be offset a little, but when so far and crossing the very corner of the raised part of the cpu its going to do what its doing and at the least compression is going to be uneven.
Seems a little back to school with fulcrums and levers and Mr Archimedes…

I can understand why as there is very little room elsewhere but with the cpu shifting up that diagonal style mount isn’t going to be a great solution as the CPU on the board has moved up the board since the 1st revision.
Its a square peg and 2 round holes to me and can see why as there isn’t a whole lot of space for anywhere else and maybe it will have to be the spider type that presses down from mounted pillars on the normal board mounts.
Pretty sure you can find a better fan but also the fan connector is PWM so on 5v its going 100%?

1 Like
1 Like

That was my expectation as well, but thanks for confirming. I’ll eventually try to run some tests with various heat sinks.

1 Like

I’ll try with diverse heat sinks, I have plenty here.

Regarding power usage, here’s what I’m seeing, powered from 5V: 1.6W idle, 8.6W during a compilation, add one watt for the fan.

I also started it with a USB-C power block that I’m using for my laptop at home, and it boots fine but at the end of the boot sequence the machine stops and restarts. I’m suspecting it could have something to do with OTG initialization that might possibly cause the board to stop requesting power for a short instant, but I could of course be wrong. I’ll eventually try with other PSUs.

Edit: It’s indeed related to software, as it does so when I boot from the ubuntu image on the SD, but not from the debian image on the eMMC.

I don’t think it will matter willy as the mount point positions to the cpu position will always remain the same so likely any heatsink will have a pressure point balancing on that corner.
You might get some that are a bit better but thinking its always going to have a tendency to lift at the other side.
The thermal pad might even be making things worse?

1 Like

Some performance/efficiency measurements made using 7z b walking through all DVFS OPP…

Why using 7-ZIP’s internal benchmark mode? https://github.com/ThomasKaiser/sbc-bench#7-zip

Rock 5B: idle temperature: 30.5°C, idle consumption: 3280mW (measured via PowerBOX 4KF with an Apple 94W USB-C charger)

single A55 core running 7-ZIP benchmark:

Sysfs/Tested:  MIPS / Temp /  Watt
 408 /  400 :   380  30.5°C  3463mW
 600 /  600 :   566  31.2°C  3443mW
 816 /  850 :   798  31.5°C  3480mW
1008 / 1070 :   988  31.8°C  3566mW
1200 / 1240 :  1134  31.5°C  3570mW
1416 / 1430 :  1295  32.1°C  3666mW
1608 / 1650 :  1478  32.4°C  3776mW
1800 / 1840 :  1629  32.7°C  3880mW

single A76 core running 7-ZIP benchmark:

Sysfs/Tested:  MIPS / Temp /  Watt
 408 /  400 :   652  31.5°C  3520mW
 600 /  600 :   932  31.5°C  3633mW
 816 /  860 :  1260  31.8°C  3670mW
1008 / 1060 :  1502  32.1°C  3730mW
1200 / 1260 :  1724  32.4°C  3776mW
1416 / 1440 :  1907  32.4°C  3766mW
1608 / 1630 :  2094  32.4°C  3876mW
1800 / 1820 :  2272  33.3°C  3980mW
2016 / 2020 :  2460  33.9°C  4130mW
2208 / 2190 :  2615  34.2°C  4333mW
2400 / 2350 :  2746  35.2°C  4590mW

As expected the higher DVFS OPP for the A76 core become more inefficient especially above 2.0 GHz.

4 Likes

I think we don’t need to insist on it, it was predictable since the presentation of the new version, and Radxa is measuring the problem.

I don’t know the exact heights of the components, personally I have several thicknesses of Gelid thermal pad solution, so it’s not really a problem for me with this configuration, moreover my case is ventilated with 12cm inaudible fan so I won’t use 40XX fan which makes 28db in continuous or 30XX or 20XX.

It is necessary for the Alpha to check that all promises can be kept in future developments for this motherboard, that there are no hidden flaws in the hardware engineering, you must push in this direction.

Because when Radxa starts distribution to the end user, matters are going to get complicated.

At the first visible design flaw, some people will cry for their money, and spit on the company forgetting the main thing, this card works and can bring a lot of satisfaction and the community will be divided.

Gents, we are interested to hear about stability, wi-fi, ethernet, hdmi, nvme, usb and etc.

1 Like

Regarding this, my board is currently up and running at home while I’m at work. I’ll run some ethernet performance tests later this week. I also have a USB SSD delivering 300-350 MB/s depending on the board it’s plugged on, I’ll have to test it with it.

Stability wise, I don’t have much to say in its current form, as the board doesn’t heat at all and is perfectly stable. I’ll rather run such tests with a fanless heatsink and try to spot the temperature limits above which trouble starts to appear.

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