Raspberry Pi 5 | "initial_turbo" keeps max CPU frequency forever

[MichaIng]

Is this the right place for my bug report?
This repository contains the GPU firmware used on the Raspberry Pi. This software is the closed source part of the Raspberry Pi system, it includes booting (including network booting and USB booting), low-level power and clock control, FKMS and legacy HDMI control (not full KMS that is in the linux kernel), hardware legacy codecs (MPEG2, H264 and VC1), encode hardware including the ISP (image sensor pipeline) and camera control, audio output (analogue and HDMI audio).

If you believe that the issue you are seeing is within this area, this is the right place. If not, we have other repositories for the linux kernel at github.com/raspberrypi/linux and Raspberry Pi userland applications at github.com/raspberrypi/userland. If you have problems with the Raspbian distribution packages, report them in the github.com/RPi-Distro/repo. If you simply have a question, then the Raspberry Pi forums are the best place to ask it.

Describe the bug
When applying initial_turbo with any non-zero value to config.txt, the CPU frequency is not only maxed for the defined amount of seconds, but forever. This is only true on Raspberry Pi 5, while on other models, CPUFreq takes over as expected.

To reproduce

echo 'initial_turbo=20' > /boot/firmware/config.txt
reboot
vcgencmd measure_clock arm

Expected behaviour
After 20 seconds uptime, the CPU frequency is intended to be scaled by CPUFreq.

Actual behaviour
CPU frequency remains at 2400 MHz.

System
Copy and paste the results of the raspinfo command in to this section. Alternatively, copy and paste a pastebin link, or add answers to the following questions:

• Which model of Raspberry Pi? Raspberry Pi 4
• Which OS and version (cat /etc/rpi-issue)? Debian/Raspbian Bookworm
• Which firmware version (vcgencmd version)?

2024/01/05 15:57:40
Copyright (c) 2012 Broadcom
version 30cc5f37 (release) (embedded)

• Which kernel version (uname -a)?

Linux RPi5 6.1.0-rpi8-rpi-2712 #1 SMP PREEMPT Debian 1:6.1.73-1+rpt1 (2024-01-25) aarch64 GNU/Linux

Logs
If applicable, add the relevant output from dmesg or similar.

root@RPi5:~# grep initial_turbo /boot/firmware/config.txt
initial_turbo=20
root@RPi5:~# uptime
 20:25:24 up 1 min,  1 user,  load average: 0.40, 0.15, 0.06
root@RPi5:~# vcgencmd measure_clock arm
frequency(0)=2400008960
root@RPi5:~# vcgencmd measure_clock arm
frequency(0)=2400006144
root@RPi5:~# vcgencmd measure_clock arm
frequency(0)=2400008192
root@RPi5:~# vcgencmd measure_clock arm
frequency(0)=2400006144
root@RPi5:~# vcgencmd measure_clock arm
frequency(0)=2400005376

Additional context
A pretty similar issue appeared some years ago before RPi 4 release: #1005
One difference: That time /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_cur_freq showed the max frequency as well, but now it reports 1500 MHz while only vcgencmd measure_clock arm reveals the 2400 MHz. This is probably a minor (kernel) bug on its own, regarding the sysfs node.

[mann1x]

I have verified this also on another Pi 5 with Raspberry Pi OS 64-bit; the power consumption in idle is stuck at 3.4 W.

Not sure if it's related but the idle power consumption of the Pi 5, after the latest updates. jumped from 2.20 W to 2.70 W

[timg236]

initial_turbo support has not been implemented yet for Pi5 so current behaviour would be equivalent to arm_freq_min=2400

[mann1x]

@timg236

Thanks for the feedback, good to know.

BTW do you know or heard anything about the increase in idle power consumption?

[timg236]

I don't see any reason for an increase in idle power consumption and it's nothing that I've seen

[mann1x]

I don't see any reason for an increase in idle power consumption and it's nothing that I've seen

Thanks.

Have one 4GB and one 8GB and they both are consuming more.
Was monitoring the power at the time so I could see the increase happening after a kernel update and reboot.
I guess just nobody is interested much about idle power consumption.

[timg236]

Idle power is something that is worked on but there are many things that can influence it so you have to be careful that nothing else has changed in the software / system configuration. I think this is off topic now though

[mann1x]

Idle power is something that is worked on but there are many things that can influence it so you have to be careful that nothing else has changed in the software / system configuration. I think this is off topic now though

Indeed it's off-topic, thanks for the feedback

[MichaIng]

As long as initial_turbo has not been fully implemented, it would be probably better to have it fully ignored, rather than taken as arm_freq_min=arm_freq? The documentation does not mention anything in this regards, and the fact that CPUFreq's cpuinfo_cur_freq equals scaling_cur_freq instead of the true frequency reported by the firmware/vcgencmd makes it hard to even recognise that something is wrong, also because it has a surprisingly low effect on idle power/temperature (unrelated to the raise after last kernel upgrade, which seems to be related to Ethernet instead, off-topic).

However, it is probably not much harder to fully implement the feature instead of actively ignoring the setting on RPi 5. Thanks for the info and it would be great to have a ping here once it works. I like the feature, especially on older RPi models, being significantly slower with powersave governor until CPUFreq kicks in. On RPi 5 it does not play such a role anymore, but less need for config.txt diversions across RPi models is easier to maintain 🙂.

[popcornmix]

However, it is probably not much harder to fully implement the feature instead of actively ignoring the setting on RPi 5.

Yes - I'll look into this - supporting it is probably quite straightforward.

It does open a wider question of whether we get any benefit from the current scheme of booting at the lower frequency and only switching later in boot if the shift key is not pressed (allowing a bypass of an unreliable overclock).

I suspect few take advantage of that scheme (or have even heard of it), and just booting at the higher clock would benefit more users. But that is a separate questions from "make initial_turbo so something sensible".

[MichaIng]

Sounds good. I would indeed vote for not booting with minimal frequency by default. I guess a scaling governor is not possible, but even just max frequency should be fine:

• This is usually only for a short time, until CPUFreq/scheduler or otherwise set frequency takes over.
• If the RPi does not run stable with the configured max frequency/overclocking, like due to insufficient PSU or voltage, it is probably beneficial to have a related crash/symptoms immediately at boot, rather than later when services are processing and data loss is possible. Adjusting config.txt is simple on any OS, thanks to the FAT partition.
• Booting utilises the CPU, and is indeed accelerated by initial_turbo according to our tests, at last up to RPi 4.
• Our testing users ran their RPi 5's with max frequency for a few weeks, without recognising, even testing overclocking settings, and no one had stability issues (unless of course testing max overclocking limits) 😅.

But from a vendor POV, I understand a conservative approach as well.

Another approach for distributions is of course to change the kernel's default governor: https://github.com/raspberrypi/linux/blob/stable_20240124/arch/arm64/configs/bcm2712_defconfig#L58
Like CONFIG_CPU_FREQ_DEFAULT_GOV_SCHEDUTIL=y. This does not affect the bootloader stage, but that is extremely short anyway, while kernel and early init stage would benefit, in a little more efficient way than just max frequency.

[popcornmix]

This should be fixed with latest testing bootload (installable from rpi-update).

[MichaIng]

Just tested it, and the CPU now clocks down as expected, many thanks 👍. It does so as well before the timeout, so the setting is currently ignored, or this since CPUFreq takes over (stopping turbo mode according to docs)?

EDIT: Tested without CPUFreq, and it works perfectly, 2.4 GHz for 1 minute, 1.5 GHz after 1 minute, when using initial_turbo=60. uptime (CLI) is a few seconds behind actual firmware uptime it seems.