ROCK 5B Debug Party Invitation

#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?

#156

BS. It was a stupid bug in sbc-bench adjusting cpufreq governor back to ondemand.

#157

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.

#158

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.

#159

Here is the sdk from rockchip: https://gitlab.com/rk3588_linux

6 Likes
#160

http://ix.io/44sB

##########################################################################

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%)

##########################################################################

http://ix.io/44tb

#161

Is there a way to test HDMI input in the Debian 11 image? I can’t find any information about that.

#162

And also is the NPU SDK @ https://github.com/rockchip-linux/rknpu2 already been tested on the board? Or does it need more work?

#163 
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
#164

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
#165

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

#166

Could you recommend any board for 2x 2-lanes (to install two nvme drives and connect them to PCIe 3.0 x4 port) please?

#167

I started using DC-barrel plug to USB-C adapter and feeding 12v from dumb switching supply meant for LED’s etc

results:

  • things work
  • things work in both usb-c orientations
  • my nvme benchmarks are slightly uhh better
  • didn’t crash on geekbench
  • FUSB302B is reporting 5v@1.5A over i2c, but we think that’s just reporting a default value and nothing else
  • FUSB302B is still properly orientation aware of the usb-c connection and communicates that status
2 Likes
#168

The FUSB302 was an unfortunate choice, this mistake was made earlier by Libre Computer and Firefly on the RK3399-ROC-PC. Mainline support is going to be a catastrophe with anyone using real PD supplies getting infinite boot loops.

Right. With no negotiation, the FUSB302 is defaulting to the “minimum common denominator” power input, it’s unaware of what you are piping in. If Radxa does the proper thing and limits performance on lower wattage supply settings (or eliminates those supply points as inadequate) that means those will need overridden by anyone using a “dumb” supply.

I measured my board, and this is a pet peeve I guess, but it is not Pico-ITX sized, it is 2mm deeper and the mounting holes are incorrect. I’m fine with “Pico-ITX-esque”, like the NanoPC T4, but I was hoping I’d be able to have some common mounting solutions between these and the other PicoITX boards I already have. As everything everywhere says this is pico-ITX, anyone with a variety of industrial SBC’s or Tinker Edge R’s might be taken by surprise. That said, thank you for not making this thing Pi shaped.

5 Likes