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!
ROCK 5B Debug Party Invitation
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.
Possibly, but what I mean is that the driver can also be using some incorrect ratios, or maybe setting frequency before voltage when going up, or the reverse when going down, etc. Typically the transitions can be some of the examples that can cause freezes. And a driver using incorrect ratios, or accessing registers in an unsafe way could also cause freezes.
I have read about the librga issue when accessing memory > 4G and it has been fixed for rk3588.
Rockchip seems to give access to the code for Board makers or when requested, not public available afaik. I wonder if Radxa team have some ways to have access to it? I am not aware of any restrictions on the code.
##########################################################################
Checking cpufreq OPP for cpu0-cpu3 (Cortex-A55):
Cpufreq OPP: 1800 Measured: 1817 (1817.503/1817.339/1816.869)
Cpufreq OPP: 1608 Measured: 1626 (1626.385/1626.238/1626.025) (+1.1%)
Cpufreq OPP: 1416 Measured: 1431 (1431.597/1431.581/1431.391) (+1.1%)
Cpufreq OPP: 1200 Measured: 1240 (1240.266/1240.147/1240.117) (+3.3%)
Cpufreq OPP: 1008 Measured: 1070 (1072.732/1069.832/1069.766) (+6.2%)
Cpufreq OPP: 816 Measured: 853 (854.282/853.973/853.700) (+4.5%)
Cpufreq OPP: 600 Measured: 590 (591.598/591.578/589.009) (-1.7%)
Cpufreq OPP: 408 Measured: 393 (393.683/393.646/393.559) (-3.7%)
Checking cpufreq OPP for cpu4-cpu5 (Cortex-A76):
Cpufreq OPP: 2352 Measured: 2345 (2345.838/2345.838/2345.838)
Cpufreq OPP: 2208 Measured: 2205 (2205.761/2205.737/2205.737)
Cpufreq OPP: 2016 Measured: 2038 (2038.918/2038.898/2038.836) (+1.1%)
Cpufreq OPP: 1800 Measured: 1839 (1840.150/1840.003/1839.731) (+2.2%)
Cpufreq OPP: 1608 Measured: 1608 (1608.919/1608.859/1608.678)
Cpufreq OPP: 1416 Measured: 1419 (1419.495/1419.401/1419.386)
Cpufreq OPP: 1200 Measured: 1233 (1240.415/1240.385/1220.975) (+2.8%)
Cpufreq OPP: 1008 Measured: 1045 (1045.238/1045.228/1045.154) (+3.7%)
Cpufreq OPP: 816 Measured: 838 (838.354/838.277/838.201) (+2.7%)
Cpufreq OPP: 600 Measured: 589 (592.851/592.804/584.130) (-1.8%)
Cpufreq OPP: 408 Measured: 394 (394.987/394.941/394.867) (-3.4%)
Checking cpufreq OPP for cpu6-cpu7 (Cortex-A76):
Cpufreq OPP: 2352 Measured: 2332 (2333.143/2332.927/2332.900)
Cpufreq OPP: 2208 Measured: 2193 (2193.913/2193.889/2193.794)
Cpufreq OPP: 2016 Measured: 2027 (2027.424/2027.099/2027.078)
Cpufreq OPP: 1800 Measured: 1829 (1829.969/1829.948/1829.803) (+1.6%)
Cpufreq OPP: 1608 Measured: 1600 (1600.404/1600.345/1600.325)
Cpufreq OPP: 1416 Measured: 1412 (1412.755/1412.600/1412.600)
Cpufreq OPP: 1200 Measured: 1237 (1237.443/1237.339/1237.162) (+3.1%)
Cpufreq OPP: 1008 Measured: 1040 (1040.826/1040.585/1040.532) (+3.2%)
Cpufreq OPP: 816 Measured: 836 (836.910/836.877/836.834) (+2.5%)
Cpufreq OPP: 600 Measured: 592 (593.117/592.878/592.871) (-1.3%)
Cpufreq OPP: 408 Measured: 394 (394.936/394.775/394.669) (-3.4%)
##########################################################################
Is there a way to test HDMI input in the Debian 11 image? I can’t find any information about that.
And also is the NPU SDK @ https://github.com/rockchip-linux/rknpu2 already been tested on the board? Or does it need more work?
Jul 16 09:47:05 rock-5b kernel: RKNPU fdab0000.npu: Adding to iommu group 0
Jul 16 09:47:05 rock-5b kernel: RKNPU fdab0000.npu: RKNPU: rknpu iommu is enabled, using iommu mode
Jul 16 09:47:05 rock-5b kernel: RKNPU fdab0000.npu: Looking up rknpu-supply from device tree
Jul 16 09:47:05 rock-5b kernel: RKNPU fdab0000.npu: Looking up mem-supply from device tree
Jul 16 09:47:05 rock-5b kernel: RKNPU fdab0000.npu: can't request region for resource [mem 0xfdab0000-0xfdabffff]
Jul 16 09:47:05 rock-5b kernel: RKNPU fdab0000.npu: can't request region for resource [mem 0xfdac0000-0xfdacffff]
Jul 16 09:47:05 rock-5b kernel: RKNPU fdab0000.npu: can't request region for resource [mem 0xfdad0000-0xfdadffff]
Jul 16 09:47:05 rock-5b kernel: [drm] Initialized rknpu 0.7.2 20220428 for fdab0000.npu on minor 1
Jul 16 09:47:05 rock-5b kernel: rockchip-pm-domain fd8d8000.power-management:power-controller: Looking up nputop-supply from device tree
Jul 16 09:47:05 rock-5b kernel: rockchip-pm-domain fd8d8000.power-management:power-controller: Looking up nputop-supply property in node /power-management@fd8d8000/power-controller failed
Jul 16 09:47:05 rock-5b kernel: rockchip-pm-domain fd8d8000.power-management:power-controller: Looking up npu1-supply from device tree
Jul 16 09:47:05 rock-5b kernel: rockchip-pm-domain fd8d8000.power-management:power-controller: Looking up npu1-supply property in node /power-management@fd8d8000/power-controller failed
Jul 16 09:47:05 rock-5b kernel: rockchip-pm-domain fd8d8000.power-management:power-controller: Looking up npu2-supply from device tree
Jul 16 09:47:05 rock-5b kernel: rockchip-pm-domain fd8d8000.power-management:power-controller: Looking up npu2-supply property in node /power-management@fd8d8000/power-controller failed
Jul 16 09:47:05 rock-5b kernel: RKNPU fdab0000.npu: Looking up rknpu-supply from device tree
Jul 16 09:47:05 rock-5b kernel: vdd_npu_s0: could not add device link fdab0000.npu: -EEXIST
Jul 16 09:47:05 rock-5b kernel: vdd_npu_s0: Failed to create debugfs directory
Jul 16 09:47:05 rock-5b kernel: RKNPU fdab0000.npu: Looking up mem-supply from device tree
Jul 16 09:47:05 rock-5b kernel: vdd_npu_s0: could not add device link fdab0000.npu: -EEXIST
Jul 16 09:47:05 rock-5b kernel: vdd_npu_s0: Failed to create debugfs directory
Jul 16 09:47:05 rock-5b kernel: RKNPU fdab0000.npu: leakage=16
Jul 16 09:47:05 rock-5b kernel: RKNPU fdab0000.npu: Looking up rknpu-supply from device tree
Jul 16 09:47:05 rock-5b kernel: vdd_npu_s0: could not add device link fdab0000.npu: -EEXIST
Jul 16 09:47:05 rock-5b kernel: vdd_npu_s0: Failed to create debugfs directory
Jul 16 09:47:05 rock-5b kernel: RKNPU fdab0000.npu: pvtm=912
Jul 16 09:47:05 rock-5b kernel: RKNPU fdab0000.npu: pvtm-volt-sel=5
Jul 16 09:47:05 rock-5b kernel: RKNPU fdab0000.npu: avs=0
Jul 16 09:47:05 rock-5b kernel: RKNPU fdab0000.npu: l=10000 h=85000 hyst=5000 l_limit=0 h_limit=800000000 h_table=0
Jul 16 09:47:05 rock-5b kernel: RKNPU fdab0000.npu: failed to find power_model node
Jul 16 09:47:05 rock-5b kernel: RKNPU fdab0000.npu: RKNPU: failed to initialize power model
Jul 16 09:47:05 rock-5b kernel: RKNPU fdab0000.npu: RKNPU: failed to get dynamic-coefficient
Think there might be more DTB work needed.
Also with the Mali blob it may far better with opencl with ArmNN delegate for Mali than last time I tried with Panfrost.
1 Like
I find this wiki page from firefly: https://wiki.t-firefly.com/en/Core-3588J/usage_hdmiin.html.
This should be familar with rock5b.
1 Like
I woud like ask you about suggested time of delivery. Ready to ship time. Term of august 2022 is suspected date? Early august? Early september,? Orange pi announced orange pi 5. They did not announced ship date or pice. Best regards
Could you recommend any board for 2x 2-lanes (to install two nvme drives and connect them to PCIe 3.0 x4 port) please?