Raspberry Pi 5 | CPU frequency remains max with initial_turbo

[mann1x]

Creating a bug report/issue

• [ X] I have searched the existing open and closed issues

Required Information

• DietPi version | cat /boot/dietpi/.version

G_DIETPI_VERSION_CORE=9
G_DIETPI_VERSION_SUB=0
G_DIETPI_VERSION_RC=2
G_GITBRANCH='master'
G_GITOWNER='MichaIng'

• Distro version | echo $G_DISTRO_NAME $G_RASPBIAN

bookworm 0

• Kernel version | uname -a

Linux DietPi5 6.1.0-rpi7-rpi-2712 #1 SMP PREEMPT Debian 1:6.1.63-1+rpt1 (2023-11-24) aarch64 GNU/Linux

• SBC model | echo $G_HW_MODEL_NAME or (EG: RPi3)

RPi 5 Model B (aarch64)

• Power supply used | (EG: 5V 1A RAVpower)

Official Raspberry 5A 27W

• SD card used | (EG: SanDisk ultra)

Sandisk Extreme Pro 128GB

Additional Information (if applicable)

• Was the software title installed freshly or updated/migrated?

Freshly

• Can this issue be replicated on a fresh installation of DietPi?

Didn't try

Steps to reproduce

• Open DietPi-Config
• Change any option Performance. eg. temperature limit to 60c

Expected behaviour

• Rebooting the pi should reflect the changes eg. stress testing the CPU should throttle after 60c

Actual behaviour

• Changes are not applied. eg. temp limit is at default and the CPU does not throttle at 60c

Extra details

• Changes are made in /boot/config.txt but since bookworm the file has been moved to /boot/firmware/config.txt

[MichaIng]

Did you use our firmware migration script when installing the new kernel/firmware packages? It creates symlinks from /boot/config.txt and /boot/cmdline.txt to /boot/firmware.

[Joulinar]

as of now our script did not support CPU temp changed done fot RPi5

[mann1x]

Sure I did use the script... mmm, maybe something messed it up?

our script did not support CPU temp changed done fot RPi5.

Why is there something different for the Pi5?
I didn't check but it looked the same

[MichaIng]

@Joulinar the temp_limit setting should still work. At least I did not see any hint that it would not work anymore.

@mann1x can you verify this:

ls -l /boot/config.txt
grep temp_limit /boot/config.txt /boot/firmware/config.txt

[mann1x]

@Joulinar the temp_limit setting should still work. At least I did not see any hint that it would not work anymore.

@mann1x can you verify this:

ls -l /boot/config.txt
grep temp_limit /boot/config.txt /boot/firmware/config.txt

I have changed it manually of course:

/boot/config.txt:temp_limit=75
/boot/firmware/config.txt:temp_limit=85

I remember now I have seen someone talking about this symlink... now makes sense.
Wonder what could have wiped them out.
I have installed some stuff outside the software manager but not that much and nothing pi specific that could mess there.
Maybe something that accessed the /boot partition for something else but I can't imagine what.

I'm waiting for a 2nd pi5, this week should be able to double check on a fresh install before opening a bug.

Yes the temp_limit works on pi5 and also the throttling flag.
Thermals are quite poor and power management it's quite raw and unsophisticated as per Broadcom but at least runs pretty damn fast and after a very long time goes into proper idling.

[mann1x]

@MichaIng
Sorry I forgot:

ls -l /boot/config.txt
-rw-r--r-- 1 root root 118 Jan 28 18:33 /boot/config.txt

[MichaIng]

Probably I missed one case of sed command when adding --follow-symlinks. Without it, it replaces symlinks with the edited file, instead of editing the target of the symlink. For now:

mv /boot/config.txt /boot/firmware/config.txt
ln -sf firmware/config.txt /boot/config.txt

[mann1x]

Probably I missed one case of sed command when adding --follow-symlinks. Without it, it replaces symlinks with the edited file, instead of editing the target of the symlink. For now:

Uhm, I'm not sure the pi5 would boot with the config.txt almost empty in /boot...
I kept the one in /boot/firmware/.

I guess I have to restore the symlink for cmdline as well.

I have another idea at that might have been, other than sed.
DietPi-Backup & DietPi-Sync.

At the beginning I just configured it on the fly without really checking what would do (so easy to do it!).
I wrongly assumed the backup would be an archive at the end.
Therefore I did setup DietPi-Sync to save on my OMV NAS share for backups via Samba, which doesn't support symlinks.
Once realized the mistake I configured it via NFS.
It did struggle for some unknown reason at the beginning, took 2 hours for a 20% sync.
I tinkered, updated, etc etc and at some point started working properly but I'm not really sure how.
Did some reboots of the pi5 and the NAS in between so thought something was just stuck.

Maybe all this could have messed up the backup; I will try to reproduce it with the new pi5 when it comes.

[MichaIng]

Uhm, I'm not sure the pi5 would boot with the config.txt almost empty in /boot...

/boot/config.txt is completely unused, not relevant for boot. Only /boot/firmware/config.txt is relevant. Hence, if you did changes to /boot/config.txt, for them to become effective, you must move it to /boot/firmware/config.txt. The symlink is currently necessary for our scripts to work, since they edit (and need to edit for backwards compatibility) /boot/config.txt. Same is true for cmdline.txt, so check it as well, though it is much less used.

If you ever restored a backup from files stored on a Samba server, then you can consider the whole system to be broken. I guess you would have noticed this already, not sure if it would even boot successfully. Quick check:

ls -l /

/bin must be a symlink to /usr/bin, lib to /usr/lib.

[mann1x]

Thanks, indeed I already moved the changes on the right one.
What I meant is that if you have this issue you end up with an almost empty config.txt in /boot so copying it over the right one in /boot/firmware would likely render the pi5 unbootable, this line you posted:

mv /boot/config.txt /boot/firmware/config.txt

should be, in case:

rm /boot/config.txt

Yes the output is correct for ls -l /, I've never needed a restore thankfully.
The backup on Samba was stopped immediately when I noticed the symlink errors flood.

[MichaIng]

you end up with an almost empty config.txt in /boot

Ah, you mean that copying a symlink to a Samba share creates an empty file there? Then you are right, though it would still boot (defaults are sane) and the problems when you restored a backup from a Samba share are much worse than an empty config file.

I've never needed a restore thankfully.

Then we still need to watch our for the reason of the dereferences symlink. I checked all sed's in dietpi-config, and they all use the --follow-symlinks flag. Also another check through all files in this repository did not provide any missed case:

grep -r 'sed.* -[^ ]*i.*config.txt' | grep -v '\--follow-symlinks'

Might it be possible that you have own scripts or used sed on our own on the config file?

Ah, and was cmdline.txt dereferences as well?

[mann1x]

No I never ran any custom script or used sed.
The only "stray" from a vanilla setup was installing some few additional apt packages, like keepalived.

Sorry; yes cmdline.txt was dereferenced as well.
It seems they are really the only 2 files impacted which is odd. Can't really compare yet.

[MichaIng]

Hmm, unsure at this point. The cmdline.txt is never copied in the first place, but only the symlink generated, by our migration script. So it must have been some dereference like with sed.

I could not find a case in our code base, but probably I missed a script which is was installed earlier, and is not updated on dietpi-update. Or you ran the migration script when there was a bug inside which is not present anymore. Or there is another command which dereferences symlinks, that I do not know about yet. I'll keep this in mind. Check back by times whether the issue re-appears.

[mann1x]

Yes indeed, I suspect maybe the update script cause I think it has been updated at least once since I used it.
Thanks a lot for the support, I will keep an eye on it and try to reproduce the steps I've done previously with the new pi5 just to be sure.

[mann1x]

@Joulinar
Forgot this bit; the initial_turbo on pi5 doesn't work, at least on mine.
Set above zero will keep turbo enabled forever.

[MichaIng]

Hmm, can you verify this again with some console commands, verifying that the CPU frequency is indeed pinned to max? Because initial_turbo=20 is the default on DietPi, and we have a lot of related output in our RPi 5/migration issue, all showing successfully scaled CPU frequencies.

[mann1x]

Sure let me know what.
The reference clock is pinned to the max as reported by vcgencmd measure_clock arm and cpuinfo_cur_freq.
This normally flips between the min and 1500-1800 MHz.
What scale normally is the dynamic clock as reported in scaling_cur_freq.
But the problem is that the voltage will be fixed, like with overclock voltage, to a static value (the max vcore allowed for the configuration).
Always same voltage from vcgencmd measure_volts core.

[MichaIng]

The voltage is not tied to the frequency. It is common that the voltage is max, as long as the frequency is not absolute min. It jumps between min and max, max whenever the frequency is only 1 MHz above min (100 MHz as of available p-states).

The CPU frequency should be between 1500 and 2400 MHz. Is it not going above 1800 MHz in your case?

What I meant with contradicting results is e.g.: #6676 (comment)

• Current frequency at 1600 MHz with initial_turbo=20. And there has not been another kernel upgrade since then.
• Though it reads from /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq. Since it is what CPUFreq instructs, and can miss if the firmware overrides it, it may simply not show the actual frequency.

@Joulinar
I need some hours before I can test, so if you have time, could you check this in your case:

cat /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq
vcgencmd measure_clock arm

[Joulinar]

@MichaIng

root@DietPi5:~# cat /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq
1500000
1600000
1600000
1600000
root@DietPi5:~# vcgencmd measure_clock arm
frequency(0)=2400023808
root@DietPi5:~#

[mann1x]

@MichaIng
Indeed it can be high also with a low clock; usually cause when it's being pulled didn't yet went down.

What I meant is that it works as expected normally and also what I would expect for the Turbo mode (it is described somewhere in the Raspberry documentation).
The problem is that it never gets out of it.

Let me check again with a vanilla config.txt because I've tested it almost always with some modifications and maybe always at least with a small bump on arm_freq_min.

[MichaIng]

Indeed it can be high also with a low clock; usually cause when it's being pulled didn't yet went down.

Let's keep voltage and frequency separate. As I said, there is no real dynamic voltage scaling, at least not up to RPi 4 based on what I tested, and based on what has been merged into the RPi documentation accordingly. So even with 1600 MHz, voltage is max, and 1600 MHz is nearly always shown, as of CPU utilisation caused by the commands to read the frequency.

So in Joulinar's case, at least cpuinfo_cur_freq shows expected scaled frequencies in cpuinfo_cur_freq. They also always show 2400 MHz in your case? vcgencmd is a relatively heavy command. Though on my RPi 2 it shows 700 MHz, hence close to min. @Joulinar does it never show anything else than 2400 MHz? And does this change when you remove/comment initial_turbo from config.txt?

[mann1x]

I have exactly the same behavior, every pool is 4 seconds and the boost should last only 20 seconds:

root@DietPi5:~# pistats -c
temp    clock   volt
52.1    2400    0.8703
52.1    2400    0.8703
52.1    2400    0.8703
52.1    2400    0.8703
52.1    2400    0.8703
52.7    2400    0.8703
52.1    2400    0.8703
53.2    2400    0.8703
52.7    2400    0.8703
52.7    2400    0.8703
52.7    2400    0.8703
52.7    2400    0.8703
52.1    2400    0.8703
53.2    2400    0.8703
52.1    2400    0.8703
52.7    2400    0.8703
52.1    2400    0.8703
53.2    2400    0.8703
52.7    2400    0.8703
51.6    2400    0.8703
53.2    2400    0.8703
53.2    2400    0.8703
53.2    2400    0.8703
53.2    2400    0.8703
52.7    2400    0.8703
53.8    2400    0.8703
53.2    2400    0.8703
53.8    2400    0.8703
53.2    2400    0.8703
53.8    2400    0.8703
53.2    2400    0.8703
53.2    2400    0.8703
53.8    2400    0.8703
53.2    2400    0.8703
53.2    2400    0.8703
53.2    2400    0.8703
53.8    2400    0.8703
53.8    2400    0.8703
54.3    2400    0.8703
53.8    2400    0.8703

I wonder if I have the latest eeprom... I have seen somewhere there is one from 24th of Jan but mine is:

CURRENT: Fri Jan 5 15:57:40 UTC 2024 (1704470260)

I have no idea how it works... is there a different eeprom for different memory models? I have the 4GB version

[mann1x]

@MichaIng
In my case, voltage scaling seems to work as expected with the pi5 (at least without the boost).

Seems to be properly reported and there's an obvious and massive difference in temperature and power consumption when it's fixed.

[MichaIng]

In my case, voltage scaling seems to work as expected with the pi5 (at least without the boost).

You mean that it dynamically scales with multiple values between min and max? Probably it has changed for RPi 5 or for all models with a kernel update. Would be good of course, however, not relevant for this topic.

You can update to latest EEPROM with:

FIRMWARE_RELEASE_STATUS=latest rpi-eeprom-update -a

The binaries for all RPi 5 variants, so I doubt it makes a difference, but I cannot rule it out either. However, Joulinar has a 4 GB variant as well.

[MichaIng]

You can also set an offset delta in config.txt

That works and worked as well before with over_voltage instead of over_voltage_delta. The only difference between them is that the latter takes values in 1 mV instead of 25 mV. But good that it scales now with more intermediate states.

So it can be controlled also by cpufreq.

That part is new indeed, and makes sense as well, if it works as documented.

I will have issues leading to r/o file system while trying to apply the new kernel update 6.1.73.
pstate: 604000

Probably 600 MHz does not run stable on RPi 5. If initial_turbo also effectively pinned the frequency to 2400 MHz in your case, the idle freq setting never had any effect, at least that would explain it. Try to raise this to 1000 MHz, or 1500 MHz, the default.

Okay so this looks like a firmware bug, and actually I have kinda déjà-vu, as, IIRC, it was the very same with RPi 4, or all RPi models, some time ago. ... oh, it was actually before RPi 4 release: raspberrypi/firmware#1005

Just one thing is different, between that old issue and between your two results: cpuinfo_cur_freq reporting non-max frequencies in Joulinar's case, while it did report the same as vcgencmd in that old issue. Does cpuinfo_cur_freq as well report max frequency in your case @mann1x, if initial_turbo is set?

[mann1x]

No it doesn't report the max frequency, only vcgencmd:

root@DietPi5:~# cat /sys/devices/system/cpu/cpu[0-3]/cpufreq/cpuinfo_cur_freq
1500000
1600000
1600000
1600000

[MichaIng]

Okay thanks, at least consistency across results now. But quite strange that cpuinfo_cur_freq does not report the correct frequency now. This is actually a 2nd bug, though probably one with the kernel, instead of with the firmware.

I will replicate this later, just to be sure, and then report at the RPi firmware repo.

I'll ship a live patch as well to disable initial_turbo on all RPi 5 systems. I wonder how much difference this makes for idle CPU temperature.

[mann1x]

I have the official case with the small heatsink and the fan on top (not the active cooler).
The clock is set at max because setting arm_core_min to 2400 will make report cpuinfo_curr_freq the max clock as well and the idle temperature is exactly the same.

The delta versus the default configuration is around +3° C for me.

Without initial_turbo:

temp    clock   volt
53.2    1600    0.7200
53.2    1600    0.7200
53.8    1600    0.7200
53.2    1600    0.7640
53.2    1600    0.7200
53.2    1600    0.7200
53.2    1600    0.7640
51.6    1600    0.7640
53.8    1600    0.7200
53.2    1600    0.7200
53.2    1600    0.7200
52.7    1600    0.7640
53.2    1600    0.7200
53.2    1600    0.7200
52.7    1600    0.7640
52.1    1600    0.7640

With initial_turbo=20:

temp    clock   volt
54.9    2400    0.8732
54.3    2400    0.8732
55.4    2400    0.8732
57.1    2400    0.8732
56.0    2400    0.8732
56.5    2400    0.8732
56.5    2400    0.8732
56.0    2400    0.8732
56.0    2400    0.8732
56.0    2400    0.8732
57.1    2400    0.8732
56.5    2400    0.8732
57.1    2400    0.8732
56.5    2400    0.8732
56.5    2400    0.8732
56.5    2400    0.8732
57.1    2400    0.8732
56.5    2400    0.8732
57.1    2400    0.8732
56.0    2400    0.8732

With initial_turbo=20 and arm_freq_min=2400:

temp    clock   volt
56.0    2400    0.8728
56.5    2400    0.8728
56.5    2400    0.8728
58.7    2400    0.8728
57.1    2400    0.8728
56.5    2400    0.8728
56.5    2400    0.8728
56.5    2400    0.8728
56.5    2400    0.8728
56.0    2400    0.8728
56.5    2400    0.8728
57.1    2400    0.8728
56.5    2400    0.8728

[MichaIng]

Okay, not a dramatic difference, but not nothing either. Since the trip points are at 50 °C and 60 °C, the fan speed should be the same in both cases as well.

[mann1x]

Well, it's not a big delta indeed.
If the fan spins up & down mainly depends on the ambient temperature where the pi5 is running and mine is not really low, probably around 22-24c.

Configured with the minimum frequencies can gain 1-2c and after a long while with low load can go down to 47-48c.
Without running monitoring probably even lower because I see it completely disappearing from the battery load of the small UPS where it's connected.
For reference, on mine undervolted at -5000 it's still stable at 2800 MHz and reduce the temperature by 1c.

temp    clock   volt
49.4    1800    0.8014
48.8    1800    0.7885
48.3    1100    0.8014
48.8    1800    0.8014
48.8    1800    0.8014
48.3    1800    0.8014
48.8    1800    0.8014
48.3    1800    0.8014
49.4    1800    0.7885
48.8    1800    0.7885
48.8    1800    0.7885
49.4    1800    0.8014
48.8    1800    0.8014
48.8    1800    0.8014
48.3    1800    0.7885
48.8    1800    0.8014
49.4    1800    0.7200
49.4    1800    0.7885
48.8    1800    0.7949
49.4    1800    0.8014
48.3    1800    0.8014
48.8    1800    0.7885
48.3    1800    0.8014
49.4    1800    0.7885
48.8    1100    0.8014

[terminet85]

My temp dropped about 8-10 °C when I removed initial turbo. I guess the difference with you is that I've edited my fan profile, so fan start early to spin instead the stock values:

#Fan
dtparam=fan_temp0=30000,fan_temp0_speed=100 
dtparam=fan_temp1=40000,fan_temp1_speed=150
dtparam=fan_temp2=57500,fan_temp2_speed=200
dtparam=fan_temp3=65000,fan_temp3_speed=255 

[MichaIng]

initial_turbo issue reported: raspberrypi/firmware#1864

[mann1x]

@MichaIng

I have bug which is specific to dietpi, it can't be reproduced on raspbian with the same kernel.
Would be nice if someone could try to reproduce it.

The network I/O is slower than it should be; the answer to ping is about 2/3 ms, it should be below 1 ms same as raspbian.
I use a 2.5G USB NIC and, while testing the OC, I noticed the throughput with iperf was below the usual:

[SUM] 0.0000-13.0212 sec 3.25 GBytes 2.14 Gbits/sec

Luckily, there's an easy and very weird solution
Just add to /boot/firmware/config.txt

isp_freq=910

That's enough to fix it somehow....
Ping answers are back to normal below 1 ms and the USB NIC works properly:

[SUM] 0.0000-12.6394 sec 3.31 GBytes 2.25 Gbits/sec

The power consumption of the pi5 is now 2.7W instead of 2.2W and, unlike before, there's no way to reduce it.

[MichaIng]

isp_freq=910 is/should be the default: https://www.raspberrypi.com/documentation/computers/config_txt.html#overclocking
You can check back with and without this setting applied via:

vcgencmd get_config isp_freq

Did you apply any other overlocking settings? AFAIK gpu_freq overrides all default GPU block frequencies, which were not set explicitly.

[mann1x]

isp_freq=910 is/should be the default: https://www.raspberrypi.com/documentation/computers/config_txt.html#overclocking You can check back with and without this setting applied via:

vcgencmd get_config isp_freq

Did you apply any other overlocking settings? AFAIK gpu_freq overrides all default GPU block frequencies, which were not set explicitly.

Yes it's the default, that's why the solution is weird...
It's the same without any other settings except the defaults.

If it's explicitly set to 910 works fine, as it should.
Not an issue on raspbian.

[MichaIng]

Did you check back the value with this command with and without the setting applied? And when you say "Raspbian", do you mean Raspberry Pi OS 32-bit or 64-bit, and did you compare with the same DietPi?

[mann1x]

The value reported is always 910:

root@DietPi5:~# vcgencmd get_config isp_freq
isp_freq=910

2 different Pi5; 4GB with NOOBS and Pi OS 64-bit, 8GB with DietPi 9.0.2

They both have the same kernel:
6.1.0-rpi8-rpi-2712 #1 SMP PREEMPT Debian 1:6.1.73-1+rpt1 (2024-01-25) aarch64 GNU/Linux

[MichaIng]

Do they have the same EEPROM/bootloader version as well? In case:

FIRMWARE_RELEASE_STATUS=latest rpi-eeprom-update -a

[mann1x]

Yes both the same, the 5th of Jan:

root@DietPi5:~# rpi-eeprom-update -a
BOOTLOADER: up to date
   CURRENT: Fri Jan  5 15:57:40 UTC 2024 (1704470260)
    LATEST: Fri Jan  5 15:57:40 UTC 2024 (1704470260)
   RELEASE: default (/lib/firmware/raspberrypi/bootloader-2712/default)
            Use raspi-config to change the release.

I checked cause I was curious if running the Pi OS would update the eeprom to the 24th Jan release.

[MichaIng]

I checked cause I was curious if running the Pi OS would update the eeprom to the 24th Jan release.

No need to install RPi OS to check this. We use the same repo and same package, so DietPi systems get exactly the same kernel and bootloader packages offered at exactly the same time 😉.

This is also why I am confused that both behave differently as you say regarding the USB Ethernet speed, on top of the wired solution of applying isp_freq=910 which is the default and reported by vcgencmd as the currently applied value, regardless whether you set it explicitly or not. And then of course the fact that isp_freq is about the image sensor frequency, hence has (should have) absolutely nothing to do with USB or network. The problem is that I have no USB Ethernet adapter to test this.

Does anyone else here have a USB Ethernet adapter to test, at best a 2.5G one?

Onboard Ethernet performs normal? And you can perfectly toggle the USB NIC speed by adding/removing the setting? And how did you actually found out that this particular setting toggles it, given that it is (should be) completely unrelated? 😄

[mann1x]

I just tried it again on the Pi 5, which got debian, eeprom and dietpi updates in the meantime and it does work normally.
There's no need to set it at 910 now.

Not sure how the video clock is connected but it's not surprising with this SoC; some unusual things, like access to the L2 cache goes thru the Videocore.

I found it out because I constantly monitor ping answers times to check for instability.
One Pi 5 was answering as expected at 1ms, the other instead at 3-4ms.
You can check this way with the onboard 1G NIC, you just need to be locally connected on the same network switch.

This is the normal answer:

root@solidpc:~# ping 192.168.178.11
PING 192.168.178.11 (192.168.178.11) 56(84) bytes of data.
64 bytes from 192.168.178.11: icmp_seq=1 ttl=64 time=0.409 ms
64 bytes from 192.168.178.11: icmp_seq=2 ttl=64 time=0.400 ms
64 bytes from 192.168.178.11: icmp_seq=3 ttl=64 time=0.367 ms
64 bytes from 192.168.178.11: icmp_seq=4 ttl=64 time=0.600 ms
64 bytes from 192.168.178.11: icmp_seq=5 ttl=64 time=1.04 ms
64 bytes from 192.168.178.11: icmp_seq=6 ttl=64 time=0.410 ms
64 bytes from 192.168.178.11: icmp_seq=7 ttl=64 time=0.368 ms
^C
--- 192.168.178.11 ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 6012ms
rtt min/avg/max/mdev = 0.367/0.512/1.035/0.225 ms

Specifying isp_freq=910 could toggle this behavior, 100% reproducible.

[MichaIng]

Ah good, probably the bootloader update fixed this as well. Just checked, and the one which fixes also initial_turbo is applied automatically on all systems on boot, as it is in "default":

/lib/firmware/raspberrypi/bootloader-2712/default/pieeprom-2024-02-16.bin

And yes, I wouldn't rule it out either that the video core frequency affects other things. It is known that the core frequency core_freq affects the software UART ttyS0, indirectly RAM speed, at least on older RPi models, and such. That it is the ISP frequency in particular was strange, but of course possible. And we saw other weird bugs as well in this pretty new kernel, when using rarely used settings (like initial_turbo) or in less tested/obvious system behaviour, like the USB NIC speed. But in such cases, I always want to double and triple check before reporting the RPi devs, and of course when it is only replicable on DietPi.