In Peter's blog post (1), he mentions that there now experimental CPU frequency support for the Raspberry Pi.
I can't get my Raspberry Pi 3 B+ to scale beyond 600MHz. How do I enable the experimental CPU frequency support in /boot/efi/config.txt ?
I'm running Fedora 29 4.19.10-300 kernel. Thanks! -- John
(1) - https://nullr0ute.com/2018/12/raspberry-pi-improvements-in-fedora-29/
On Sun, Dec 30, 2018 at 11:18 PM John Walicki johnwalicki@gmail.com wrote:
In Peter's blog post (1), he mentions that there now experimental CPU frequency support for the Raspberry Pi.
I can't get my Raspberry Pi 3 B+ to scale beyond 600MHz. How do I enable the experimental CPU frequency support in /boot/efi/config.txt ?
You do nothing in config.txt, it's all kernel based, you should be able look in the following:
ls /sys/devices/system/cpu/cpufreq/
Thanks - I have been monitoring the Raspberry Pi's current frequency by looking at: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq Even after adding force_turbo=1 to config.txt and rebooting, cpu0 never seems to scale above 600 A closer peek at $ sudo cat /sys/devices/system/cpu/cpufreq/policy0/* shows that some of the cores will occasionally hit 900, 1200, 1400MHz so you're correct that the CPU frequency support in the kernel is working.
It seems that Gnome Shell / wayland drags down performance on the Raspberry Pi so much that opening Firefox takes 10 minutes. I'd prefer to run Gnome but its unbearable. I've done a $ sudo dnf groupinstall lxde-desktop-environment and LXDE performance is much better. -- John
Thanks - I have been monitoring the Raspberry Pi's current frequency by looking at: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq Even after adding force_turbo=1 to config.txt and rebooting, cpu0 never seems to scale above 600 A closer peek at $ sudo cat /sys/devices/system/cpu/cpufreq/policy0/* shows that some of the cores will occasionally hit 900, 1200, 1400MHz so you're correct that the CPU frequency support in the kernel is working.
It seems that Gnome Shell / wayland drags down performance on the Raspberry Pi so much that opening Firefox takes 10 minutes. I'd prefer to run Gnome but its unbearable. I've done a
In my testing while Gnome isn't as snappy as some of the lighter weight desktops I've not seen Firefox take anywhere near that long, I know the mSD card used does affect the performance quite a bit in that regard too, which card are you using?
$ sudo dnf groupinstall lxde-desktop-environment and LXDE performance is much better. -- John _______________________________________________ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org
Thanks for the replies.
In my testing while Gnome isn't as snappy as some of the lighter weight desktops I've not seen Firefox take anywhere near that long,
When using LXDE, Firefox starts up in under a minute. Something else with Gnome might be the cause. I also tried running Gnome (xorg) but performance was abominable too.
I know the mSD card used does affect the performance quite a bit in that regard too, which card are you using?
Its a 16GB UHS-1 microSD card from a reputable vendor. I don't think that's the problem.
Separately, I initially tried to install Fedora 29 aarch64 on a 32GB Class 10 microSD card. I burned the card several times but it would not boot successfully. Consistently it failed with Bug 1644873 - WARNING at drivers/mmc/bcm2835_sdhost.c:408/bcm2835_send_command()! https://bugzilla.redhat.com/show_bug.cgi?id=1644873
-- John
Hi.
I've been trying to adjust the frequency but never seen /sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq say anything other than 600000 even with 2 cpu intensive processes running.
I have 4.19.13-300.fc29.aarch64
It seems that despite # cat scaling_available_frequencies 600000 900000 1200000 1400000
scaling_max_freq is stuck on 600000
With the scaling_governor set to performance or ondemand, I don't seem able to adjust the scaling_max_freq, so the cpu is always stuck at 600MHz,
[root@sam-pi policy0]# echo 1400000 > scaling_max_freq [root@sam-pi policy0]# cat scaling_max_freq 600000
with govener set to userspace I am also unable to make changes [root@sam-pi policy0]# echo 900000 > scaling_setspeed [root@sam-pi policy0]# cat scaling_setspeed 600000
Is there anything more I need to do?
Hi Sam,
Am 13.01.19 um 23:37 schrieb sam tygier:
Hi.
I've been trying to adjust the frequency but never seen /sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq say anything other than 600000 even with 2 cpu intensive processes running.
I have 4.19.13-300.fc29.aarch64
It seems that despite # cat scaling_available_frequencies 600000 900000 1200000 1400000
scaling_max_freq is stuck on 600000
With the scaling_governor set to performance or ondemand, I don't seem able to adjust the scaling_max_freq, so the cpu is always stuck at 600MHz,
[root@sam-pi policy0]# echo 1400000 > scaling_max_freq [root@sam-pi policy0]# cat scaling_max_freq 600000
with govener set to userspace I am also unable to make changes [root@sam-pi policy0]# echo 900000 > scaling_setspeed [root@sam-pi policy0]# cat scaling_setspeed 600000
Is there anything more I need to do?
do you have the entries "enable_uart" or "core_freq" in your config.txt?
Try to uncomment them.
Best regards Stefan
On Thu, 17 Jan 2019, Stefan Wahren wrote:
Am 13.01.19 um 23:37 schrieb sam tygier:
I've been trying to adjust the frequency but never seen /sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq say anything other than 600000 even with 2 cpu intensive processes running.
...
scaling_max_freq is stuck on 600000
I've seen reports that the rpi3B cannot go beyond 600Mhz without heatsinks because of thermal throttling. I've ordered a case kit (with heat sinks) to test this for myself.
I'm actually kind of impressed - the board is absolutely stable with no additional trappings, and at 600Mhz essentially runs like the XO-1. Add heat syncs, and (according to these reports from people running Fedora 29), clock jumps to 1.4Ghz on demand (and power consumption jumps as well) and dnf no longer feels like molasses. That is true hardware flexibility.
Still stuck at 600Mhz with heat sinks attached and mini-fan from kit. So I guess it is a software problem.
On Thu, 17 Jan 2019, Stuart D. Gathman wrote:
On Thu, 17 Jan 2019, Stefan Wahren wrote:
Am 13.01.19 um 23:37 schrieb sam tygier:
I've been trying to adjust the frequency but never seen /sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq say anything other than 600000 even with 2 cpu intensive processes running.
...
scaling_max_freq is stuck on 600000
I've seen reports that the rpi3B cannot go beyond 600Mhz without heatsinks because of thermal throttling. I've ordered a case kit (with heat sinks) to test this for myself.
On Fri, Jan 18, 2019 at 12:22 AM Stuart D. Gathman stuart@gathman.org wrote:
Still stuck at 600Mhz with heat sinks attached and mini-fan from kit
What about running
watch cat /sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq
Hi John,
John Walicki johnwalicki@gmail.com hat am 31. Dezember 2018 um 00:18 geschrieben:
In Peter's blog post (1), he mentions that there now experimental CPU frequency support for the Raspberry Pi.
apologize for being the grinch, but there are reasons that the cpufreq driver isn't in mainline yet. All affected drivers (sdhost, i2c, aux uart, spi, dpi) aren't aware of the VPU clock changes which could result in unexpected behavior. For example the debug UART (aux uart) on the RPi 3 isn't usable anymore. A workaround here is to disable bluetooth and use that UART.
Further information can be found here: https://github.com/lategoodbye/rpi-zero/issues/32
Regards Stefan
I'm running Fedora 29 4.19.10-300 kernel. Thanks! -- John
(1) - https://nullr0ute.com/2018/12/raspberry-pi-improvements-in-fedora-29/ _______________________________________________ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org