Pedro Lamas

Unfortunately userspace upgrades like Bionic to Focal or Stretch to Buster have never been officially supported by Armbian due to lack of resources for proper testing. It probably works if you freeze your firmware packages and follow official Ubuntu/Debian guide how to upgrade but if something goes wrong you won't receive help from Armbian.

No. If you run bullseye simply wait until rootfs updates support status to supported. Things are prepared already: https://github.com/armbian/build/commit/f61f560510b8a4ba012209f27c0b3e44909232ef

With that setting you are actually disabling the DVFS after the short period of time during boot - before cpufrequtils kicks in.
My experience is that you could also set it to min/max 2GHz and it would be just as good.
 
Yes, this mod/tweak/hack ;-) fixes the behaviour of my boards with ondemand governor.
 
It seems that the instability of little core's voltage during the voltage change was the issue.
Rockchip has already limited max change per single step for this regulator to 100mV (because of "overshooting") and I did limit it further to 50mV (75mV was still unstable).
It takes a bit longer to switch between frequencies now (at least 456uS vs at least 196uS for full swing between 408MHz and 1512MHz) but it is stable.

@piter75 I've had no issues with my M4V2 since setting the governor to "userspace" and max and min speeds set to "1416000" (and by no issues, I mean no crashes at all and I have an uptime of 20 days now), but I wonder if your fix is for the issues we've seen with the governor set to "ondemand"?

Excellent work @NicoD, does that mean one can now create a PR to improve this and submit to the Armbian repo?

Update : It was a mesa bug that produced the crashes. 
RK3399 is now back stable with latest updates. Even at 2Ghz and ondemand governor. 
But not all problems are fixed yet with mesa/panfrost. The errors in dmesg are still there. And some things that use panfrost will not work. 
Mesa has had a major update to version 20.2.4. So if you need panfrost, best to use mesa 20.2.3. https://docs.mesa3d.org/relnotes/20.2.4.html
You can also download the old version of Armbian Reforged with mesa 20.2.3. But be sure not to upgrade for the moment. 
 

I noticed that the ondemand sampling_rate was low in 5.x compared to 4.4's default. compare below:
 
$ uname -r 4.4.213-rk3399 $ sudo cat /sys/devices/system/cpu/cpufreq/policy{0,4}/ondemand/sampling_rate 40000 465000  
vs
 
$ uname -r 5.8.15-rockchip64 $ sudo cat /sys/devices/system/cpu/cpufreq/policy{0,4}/ondemand/sampling_rate 10000 10000  
It appears that 10000 seems to be a default (or the minimum value possible). Per https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt 10000 is too low given the cpu_transition_latency:
$ uname -r 5.8.15-rockchip64 $ cat /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_transition_latency 40000 40000 40000 40000 515000 515000  
Given the documented formula cpuinfo_transition_latency * 750 / 1000, it should be (at a minimum) 30000 for cpu0-3, and 386250 for cpu4-5.
 
Using sysfs to configure cpufreq on boot with the revised sampling_rate seems to make it stable (although uptime is only about 2 days in). I ran periodic load testing to get the ondemand governor to change freq, and this config looks promising. Despite the previously mentioned calculations, i opted to align the sampling_rate with what was present in the 4.4 kernel:
$ tail -n+1 /etc/sysfs.d/* ==> /etc/sysfs.d/cpufreq-policy0.conf <== devices/system/cpu/cpufreq/policy0/scaling_governor = ondemand devices/system/cpu/cpufreq/policy0/scaling_max_freq = 1416000 devices/system/cpu/cpufreq/policy0/scaling_min_freq = 600000 devices/system/cpu/cpufreq/policy0/ondemand/sampling_rate = 40000 ==> /etc/sysfs.d/cpufreq-policy4.conf <== devices/system/cpu/cpufreq/policy4/scaling_governor = ondemand devices/system/cpu/cpufreq/policy4/scaling_max_freq = 1800000 devices/system/cpu/cpufreq/policy4/scaling_min_freq = 600000 devices/system/cpu/cpufreq/policy4/ondemand/sampling_rate = 465000 $ for i in 0 1 2 3 4 5; do sudo cat /sys/devices/system/cpu/cpu${i}/cpufreq/scaling_{governor,min_freq,max_freq}; done; ondemand 600000 1416000 ondemand 600000 1416000 ondemand 600000 1416000 ondemand 600000 1416000 ondemand 600000 1800000 ondemand 600000 1800000  
one of two boards are already crashing, not sure if its the board or what. going to switch to "performance" governor and see. figured i'd share the sample_rate delta info though.

@Pedro Lamas I don't use this to config. my config equivalent to:
echo 1416000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq echo 1800000 > /sys/devices/system/cpu/cpufreq/policy4/scaling_max_freq echo performance > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor echo performance > /sys/devices/system/cpu/cpufreq/policy4/scaling_governor  

Thanks for sharing that @piter75, following your instruction I've now added the overlay and set the governor back to "ondemand" with min 600000 and max 1800000.
 
I'll keep an eye on it and report back any crash - hopefully not though!!
 
Entering day 3 with "ondemand" governor, min 600000 and max 1800000, and the custom overlay @piter75 provided... no issues at all!! I think we're on to something here!!
 
I just woke up to find my M4V2 had crashed during the night...
 
As I had to manually reboot it, I upgraded the firmware via armbian-config and rebooted it again to make sure I'm using the latest available.
 
Another crash just now while I was pulling some images from Docker Hub...
 
Message from syslogd@localhost at Oct 7 18:13:28 ... kernel:[85530.199864] Internal error: Oops: 96000044 [#1] PREEMPT SMP Message from syslogd@localhost at Oct 7 18:13:28 ... kernel:[85530.221095] Code: f94006e1 f9403fe2 f90004e1 d37cf400 (f9000027)  

@aprayoga Fingers crossed!
I remember playing with "regulator-ramp-delay" with M4V2 before (after noticing slow big cpu cluster transitions) but I probably did not got that high and definitely did not see that post you mentioned (and was not successful).
I started some tests with 40000 right now.
 
@Pedro Lamas if you want to also try testing it...
Save below overlay into a file in your M4V2 (let's name it rump-delay-test.dts), run "sudo armbian-add-overlay rump-delay-test.dts" and reboot your M4V2.
/dts-v1/; /plugin/; / { compatible = "rockchip,rk3399"; fragment@0 { target = <&vdd_cpu_b>; __overlay__ { regulator-ramp-delay = <40000>; }; }; };  

@piter75 @Pedro Lamas
Helios64 also encounter some random crash, yesterday we tried to redefine opp just 408 MHz and 1.4/1.8 GHz and we don't see any random crash anymore.
It seems similar DVFS problem as discussed in this thread. Then our customer point us to odroid n1 issue at
https://forum.odroid.com/viewtopic.php?t=30303
Maybe you can give it a try on Nano Pi M4v2.
 
We are still testing on Helios64 (with value 40000), so far with reboot and power cycle does not trigger any kernel crash.

Yes. They are treated as separate groups/clusters when it comes to scaling and they also have separate regulators assigned to them.
 
cpufrequtils however cannot configure their limits separately - the same limits are applied to both clusters
 

I've changed it to 1008000 yesterday, so far all good (though obviously a bit slower):
pedro@nanopim4v2:~$ cat /etc/default/cpufrequtils ENABLE=true MIN_SPEED=1008000 MAX_SPEED=1008000 GOVERNOR=userspace  

FYI, I found that this was due to a missing entry in debian-config-functions so I submitted a PR to add it (here) and this has now been merged so it should be available on the next update of armbian-config!

Thx for the PR.
 
You can also things like blacklisting the wifi module, using iwconfig wlan0 power off ...