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.
ROCK 5B Debug Party Invitation
2 Likes
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
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
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
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
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.
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?
Foxconn according to lookup
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.
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.
Got it, look carefully! It’s 00-1E-4C instead of 00-E1-4C 
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
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.
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!
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.
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
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
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)It’s also possible that the cpufreq driver is a bit bogus. That might even explain Jean-Luc’s freezes during tests.
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?
BS. It was a stupid bug in sbc-bench adjusting cpufreq governor back to ondemand.