JovianPyx
Posts: 132
Joined: Fri Nov 20, 2015 9:34 pm

Pi4B Raspbian Buster Ignores arm_freq_min in config.txt

Tue Apr 28, 2020 5:02 pm

This is very weird. I have two Pi4B 4GB machines, one is a server, the other is a workstation. Both are at the most up to date Raspbian software versions. I can overclock both. The workstation goes to 1900 MHz, and the server goes to 2000 MHz (didn't try higher).

The issue is with the server only (which doesn't have the GUI installed). The server ignores the arm_min_freq=900 parameter I put into config.txt. It is the only line specifying arm_min_freq in config.txt (checked with grep). Yet, the machine always sets the value to arm_freq divided by 2. Currently, it's running at 1000 MHz as the min freq with arm_freq set to 2000. When I set arm_freq to 1900, arm_freq_min goes to 950. I can see this value is also in /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_min_freq.

The workstation min is set to 900 and arm_freq is set to 1900. Given the server's behavior, I expected the min freq to be 950 as it was on the server, but it remains at the value I set in config.txt, 900.

I'm stymied because I did:

Code: Select all

sudo apt update
sudo apt dist-upgrade
and rebooted for each machine today. I expected both machines to then be at the same version level and would behave the same.

While this isn't really something that needs fixing (CPU temperature is always below 50C), it would be nice to understand what is happening. Any clue out there as to what is going on?

JovianPyx
Posts: 132
Joined: Fri Nov 20, 2015 9:34 pm

Re: Pi4B Raspbian Buster Ignores arm_freq_min in config.txt

Tue Apr 28, 2020 10:20 pm

I have more information which seems also part of the answer.

I dumped out all of the text files in /sys/devices/system/cpu/cpufreq/policy0/

Among them were some that were interesting.
./scaling_driver:
For the server, it is 'cpufreq-dt'.
For the workstation is 'BCM2835 CPUFreq'.

./scaling_available_frequencies:
For the server, it is
1000000 1333333 2000000
For the workstation, it is
900000 1900000

There are also usage statistics which said that for a small time_in_state, the 133333 value had 38 ticks. So it appears that the cpufreq-dt scaling driver actually has 3 states and apparently lives in all three. The workstation has a different driver which seems to support only two speed states.

So I believe I know why this is happening - Of course the question is, which is most up to date and how can I fix the one that's not up to date?

JovianPyx
Posts: 132
Joined: Fri Nov 20, 2015 9:34 pm

Re: Pi4B Raspbian Buster Ignores arm_freq_min in config.txt

Wed Apr 29, 2020 4:56 pm

Again a bit more. After scouring the internet to understand why the two systems have different scaling drivers, I found that the driver is not a loadable module. It is compiled into the kernel. Further, I was able to find the strings 'cpufreq-dt' in the server's kernel8 file and 'BCM2835 CPUFreq' in the workstation's kernel8 file. Seeing that I realized I have two different kernel8 files. Checking the versions, I see the server with 4.19.97-v7l+ and the workstation with 4.19.75-v7l+. So the server's behavior is the most up to date (but goes against the documentation for clock governor and scaling).

Of course, now I have to wonder how that happened since I've religiously applied updates to both machines on a regular basis.

I searched about updating the kernel, but the method is rpi-update which has a warning that I shouldn't try it unless instructed by a Raspberry Pi engineer.

If it matters, the workstation has a HiFiBerry audio card, but I believe it's driver is a loadable module.

-- OR -- Should I just leave it alone... I am thinking that at some point, the kernel on the workstation will get upgraded to the same as the server.

I'd love to hear from people who can advise on this subject.

Return to “Troubleshooting”