ROCK 5B Debug Party Invitation

#135

Ok, in case your board freezes when running the benchmarks just like Jean-Luc’s please provide output from

taskset -c 1 /usr/local/src/mhz/mhz 3 100000
taskset -c 5 /usr/local/src/mhz/mhz 3 100000
taskset -c 7 /usr/local/src/mhz/mhz 3 100000

And if this is really reproducible now on 2 boards we need to get in contact with RK for more conservative BLOBs than those currently used.

By comparing memory performance of Radxa’s Ubuntu with your Armbian build I’m pretty sure at least rk3588_ddr_lp4_2112MHz_lp5_2736MHz_v1.07.bin is also used in Radxa’s builds.

Edit: there’s an also an older BL31 available.

#136

Has the m2 pcie3x4 slot been tested for pcie bifurcation support? I am only asking because I read somewhere in this forum that there are plans to support m2 multi-chip network cards (such as the odroid h2 net card) and that would require pcie bifurcation.

2 Likes
#137

I know of no-one who has tested this with RK3588 but it should work. RK3588’s little sibling RK3568 sharing same/similar IP blocks also supports bifurcation (see here for feature comparison and there for discussion) and with RK3568 I can personally confirm it’s working since having two NanoPi R5S on my desk where each Gen3 lane is connected to an own RTL8125BG NIC.

You’re right that it should be tested prior to final release but I don’t know who would match the prerequisits (owning the H2 netcard or some special splitter card that turns M.2 into two or four PCIe slots).

2 Likes
#138

Yes, the PCIe 3.0 x4 can be configured as:

  • 4x 1-lane
  • 2x 2-lanes
  • 1x 2-lanes + 2x 1-lanes
  • 1x 4-lanes

Note you also need PCIe clock for multiple PCIe devices.

5 Likes
#139

Well, I tried to replace this BLOB, built an u-boot package [1], installed it on Armbian [2] and rebooted:

root@rock-5b:/home/tk# dpkg -i /tmp/linux-u-boot-legacy-rock-5b_22.08.0-trunk_arm64.deb 
dpkg: Warnung: Version 20220707f-rpardini des Paketes linux-u-boot-rock-5b-legacy wird durch ältere Version 22.08.0-trunk ersetzt
(Lese Datenbank ... 37287 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von .../linux-u-boot-legacy-rock-5b_22.08.0-trunk_arm64.deb ...
Entpacken von linux-u-boot-rock-5b-legacy (22.08.0-trunk) über (20220707f-rpardini) ...
linux-u-boot-rock-5b-legacy (22.08.0-trunk) wird eingerichtet ...

But after a reboot at least same PVTM entries in dmesg as before:

cpu cpu0: pvtm=1529
cpu cpu0: pvtm-volt-sel=5
cpu cpu4: pvtm=1784
cpu cpu4: pvtm-volt-sel=7
cpu cpu6: pvtm=1782
cpu cpu6: pvtm-volt-sel=7
cpu cpu0: l=10000 h=85000 hyst=5000 l_limit=0 h_limit=1608000000 h_table=0
cpu cpu4: l=10000 h=85000 hyst=5000 l_limit=0 h_limit=2208000000 h_table=0
cpu cpu6: l=10000 h=85000 hyst=5000 l_limit=0 h_limit=2208000000 h_table=0

Also ending up with exact same provided cpufreq OPP and real clockspeeds…

[1] MD5 (linux-u-boot-legacy-rock-5b_22.08.0-trunk_arm64.deb.zip) = 154ec1750fbe1d3e1be1431183b43b42
[2] Don’t try this on the Radxa provided images, only supposed to work on the preliminary Armbian images

#140

Are you hinting at something special or can we expect that Rock 5B’s M.2 implementation supports ‘bifurcation’ including clocks to the point where aforementioned PCIe splitters or this ODROID H2 net card work flawlessly?

1 Like
#141

Note that I didn’t expect the values to change as they’re defined in the DTS, e.g.:

rockchip,pvtm-voltage-sel = <0x00 0x63b 0x00 0x63c 0x64f 0x01 0x650 0x668 0x02 0x669 0x68b 0x03 0x68c 0x6ae 0x04 0x6af 0x6cf 0x05 0x6d0 0x6f0 0x06 0x6f1 0x270f 0x07>;

I’m reading this as: 0-63b -> sel 0; 63c->64f -> sel 1 etc. So above for 1782 (0x6f6) it would match 6f1-270f hence 7.

I suspect that the opp-microvolt-L1…L7 values are voltages for various PVTM values for a given frequency, allowing to lower the voltage on some higher quality chips. This owuld mean that the last frequency to support an adjustable voltage is 2208 MHz, and above there are only fixed values. I haven’t yet found how they’re enabled, though the opp-supported-hw value suspiciously looks like a bit mask of the PVTM values that will expose that frequency. With 0x80 for 2.4 GHz (pvtm-sel=7) you’re seeing your frequency, while I’m only seeing 2304 or 2352, and as there are holes in the mask this avoids some useless ones which almost overlap with the next one.

This would then allow to unlock high frequencies for lower grade chips by using a slight overvolting. Apparently at 2.208 the difference between L6 and L7 is 12.5mV and between L5 and L6 it’s 25mV. So it might be reasonable to try to compensate for silicon quality with a bit more heat.

#142

Thank you for the insights!

Different topic: the MAC address of ‘my’ board is 00:e1:4c:68:00:1c which is an unknown OUI to me. Is yours similar?

#143

Foxconn according to lookup

#144

00:e1:4c:68:00:1f here. I can’t find foxconn associated with it, however when I look that prefix up, each time I find it associated with a realtek chip, wired or wireless (8139, 8153, 8125, 8192cu). So I guess it’s a sub-range of realtek. Interestingly, realtek is 00-E0-4C, so there’s just one flip bit there. Maybe they recently ordered a second range.

#146

https://hwaddress.com/oui-iab/00-1E-4C/ was what I used and maybe wrong but presumed the same was found as what does it matter what the OUI is?
If not shame as it would of have had the build quality of an Iphone.

#147

Got it, look carefully! It’s 00-1E-4C instead of 00-E1-4C :slight_smile:
I guess the search engine adjusted the request for you, just like it did for me when looking for this prefix by proposing me different ones!

1 Like
#148

Talking about this?

#149

Never looked at the code think it was something I read on LWN maybe, I thought it was more dynamic than just based on memory but guess that maybe was it.
I read dynamic (from memory) and expected it to shrink or grow on use so maybe not.
I was hunting for some info on the optimum settings for a multidisk snapraid and I will never remember the url or exactly why I thought that was no longer needed.
It was to do a simple distribution agnostic NAS based on https://cockpit-project.org/ but never went much further

In fact prob no as you have posted kernel 5.10 and have said its a newer kernel revision from last year or so.

#150

No idea what this sentence should express but anway. If this is all that has changed recently then the kernel will use 128K per 1G of memory for the coherent_pool size and as such boards with 4GB RAM will run into UAS troubles while those with more memory won’t. Good luck Radxa with your support efforts!

#151

Its not the point if it is or not, it should not be in the image as said. It should be in the wiki as tweaks and fixes so as the image moves forward we don’t bring a forward a load of hidden tweaks and fixes we have forgotten.
It doesn’t matter if its correct or not it just shouldn’t be in the image as that should be vanilla.
I have said its great you have brought that to out attention but not in the image, that is all.

#152

Hello, the result of sbc-bench is here: http://ix.io/443u.
Output of that three commands is here:

jfliu@rock-5b:~$ taskset -c 1 /usr/local/src/mhz/mhz 3 100000
count=807053 us50=22065 us250=110322 diff=88257 cpu_MHz=1828.870
count=807053 us50=22067 us250=110333 diff=88266 cpu_MHz=1828.684
count=807053 us50=22068 us250=110330 diff=88262 cpu_MHz=1828.767
jfliu@rock-5b:~$ taskset -c 5 /usr/local/src/mhz/mhz 3 100000
count=1008816 us50=21888 us250=109433 diff=87545 cpu_MHz=2304.680
count=1008816 us50=21887 us250=109436 diff=87549 cpu_MHz=2304.575
count=1008816 us50=21889 us250=109440 diff=87551 cpu_MHz=2304.522
jfliu@rock-5b:~$ taskset -c 7 /usr/local/src/mhz/mhz 3 100000
count=1008816 us50=21729 us250=108652 diff=86923 cpu_MHz=2321.172
count=1008816 us50=21732 us250=108646 diff=86914 cpu_MHz=2321.412
count=1008816 us50=21727 us250=108651 diff=86924 cpu_MHz=2321.145
#153

Thank you!

So while you’re also not granted access to highest cpufreq OPP by PVTM:

CPU sysfs topology (clusters, cpufreq members, clockspeeds)
                 cpufreq   min    max
 CPU    cluster  policy   speed  speed   core type
  0        0        0      408    1800   Cortex-A55 / r2p0
  1        0        0      408    1800   Cortex-A55 / r2p0
  2        0        0      408    1800   Cortex-A55 / r2p0
  3        0        0      408    1800   Cortex-A55 / r2p0
  4        1        4      408    2256   Cortex-A76 / r4p0
  5        1        4      408    2256   Cortex-A76 / r4p0
  6        2        6      408    2304   Cortex-A76 / r4p0
  7        2        6      408    2304   Cortex-A76 / r4p0

The MCU then decides to somewhat compensate for this and while the 2nd cluster has only 2256 MHz as highest cpufreq OPP in reality it’s 2305 MHz :slight_smile:

cpu0-cpu3: 1800    Measured: 1828 (1829.098/1828.995/1828.290)     (+1.6%)
cpu4-cpu5: 2256    Measured: 2304 (2305.128/2304.785/2304.654)     (+2.1%)
cpu6-cpu7: 2304    Measured: 2322 (2323.016/2322.989/2322.775)
#154

It’s also possible that the cpufreq driver is a bit bogus. That might even explain Jean-Luc’s freezes during tests.

#155

It is definitely bogus since telling to switch to performance most of the times has no effect and the driver still decides to downclock idle cores (which is bad from sbc-bench's perspective since throttling reporting then doesn’t work at all)

In the past we have seen numerous occurences of instabilities that went away once cpufreq scaling has been disabled by switching for example to performance (or latencies adjusted later once the issue has been identified).

Which reminds me of what I already wanted to test: whether userspace governor really results in the cores remaining on configured clockspeeds. If that works Jean-Luc could try again and if his board then survives the benchmarks it’s almost certain that the cpufreq driver is to blame, right?