Vaclav Rada

Yes, marginally lower performace is expected due to the inreased clock-latency-ns in the device tree (which makes the cpu frequency ramp up over longer period of time) and also due to the increased rate_limit_us (which makes the cpu run at certain frequency at least certain amount of time). This should improve stability - especially if there is some problem with power delivery (which i think there is). I am aware of the topic you posted, I have been playing myself with realtek firmware, with cpu frequencies, governors, etc. In past I had most success with min=max=1200Mhz across all cores and performance governor, but now I settled with the slight overvolt, inreased latencies and schedutil governor.

CAUTION: This content is provided "as is," without warranties or guarantees, and the user assumes responsibility for any consequences, including data loss, system failure, or damages, whether direct or indirect. This is just a few hints how I persuaded mine helios64 to run stable with armbian 24.11 and linux 6.12.1-edge. I have been stressing it several days now and haven't encountered any issue/crash/kernel oopsie. 1) created custom device tree with higher cpu voltage: big cores up to 1800Mhz@1.3V small cores up to 1400Mhz@1.15V also the clock-latency-ns was bumped from 40000 to 50000 2) set up the cpufrequtils service to use big.LITTLE architecture 3) created the /etc/default/cpufrequtils-bl config for the cpufrequtils service I run the big cores 408Mhz@0.85V - 1608Mhz@1.2V and the small cores 408Mhz@0.85V - 1200Mhz@1.025V I prefer to run the cores slower than absolute max freq. I do not recommend running them at 1800Mhz@1.3V (1.3V is absolute max voltage recommended in rk3399 datasheet). My feeling is that the most problematic was the rate_limit_us. It was set to 75/93 out of the box. The cpufrequtils service sets it hard to 20000, which might be too conservative, but whatever. So, If someone is willing to give this a go, this is how to set it up. Hope this helps someone, also looking forward to any feedback. # backup the original device tree first cp /boot/dtb/rockchip/rk3399-kobol-helios64.dtb rk3399-kobol-helios64.dtb.bak # copy new device tree instead of the original # if you're using some custom overlays, you might wanna get rid of them cp <downloaded rk3399-kobol-helios64.dtb> /boot/dtb/rockchip/ # then set up the cpufrequtils service, which uses the /etc/default/cpufrequtils-bl config # cpufrequtils should be installed apt install cpufrequtils # backup the original cpufrequtils service and cpufrequtils-bl config cp /etc/init.d/cpufrequtils /etc/init.d/cpufrequtils.bak cp /etc/default/cpufrequtils-bl /etc/default/cpufrequtils-bl.bak # copy the files in place of the old ones cp <downloaded cpufrequtils> /etc/init.d/cpufrequtils cp <downloaded cpufrequtils-bl> /etc/default/cpufrequtils-bl # start/restart and enable the cpufrequtils service and reboot to use the new device tree systemctl daemon-reload systemctl restart cpufrequtls systemctl enable cpufrequtls reboot # after reboot, check the cpu settings, this is how mine runs: cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq 1200000 1200000 1200000 1200000 1608000 1608000 cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_min_freq 408000 408000 408000 408000 408000 408000 cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor schedutil schedutil schedutil schedutil schedutil schedutil cat /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_transition_latency 50000 50000 50000 50000 62000 62000 cat /sys/devices/system/cpu/cpu*/cpufreq/schedutil/rate_limit_us 20000 20000 20000 20000 20000 20000 rk3399-kobol-helios64.dtb cpufrequtils cpufrequtils-bl