BDS clock settings menu doesn't actually overclock > 1500 MHz

[jlinton]

It looks like the firmware is ack'ing the request for higher clock rates >1500 but not actually changing the clock rate.

I noticed this while running perf stat where perf computes a rough clock frequency from the perf cpu cycles counter. It was claiming the machine was at 1.5Ghz despite the firmware saying it was at 2Ghz. The lmbench mhz utility reported similar clock rates. So, I manually overclocked with arm_freq in the config.txt file matching the uefi setting. Everything behaves as before, but now the perf stat sleep 1 reports the overclocked frequency. It also crashes in random places with the higher clock frequencies without additional voltage as one would expect from an overclocked machine.

This is with the apr 20th 2020 firmware (although I think it was happening with some of the older versions as well).

[jlinton]

It may be that having any value in arm_freq is enough to remove the 1.5Ghz clamp, but I need to verify that fully.

[bzy-080408]

Sometimes the frequency may be reduced due to low power

[bzy-080408]

由于电力不足

[worproject]

If you set an intermediate frequency (eg. 1327), what does perf stat say?

[bzy-080408]

If you set an intermediate frequency (eg. 1327), what does say?perf stat

I don`t no .I think maybe this value is not greater than 1500, then it should be valid

[bzy-080408]

and when I run ubuntu server live CD on it I think it can do it

[andreiw]

I found that if setting through config.txt, it doesn't matter what the UEFI setting is. That's definitely a difference in behavior from Pi 3.

I.e for 2GHz:

force_turbo=0 arm_freq=2000 over_voltage=6

[jlinton]

So, there is a field in the set clock mailbox "skip setting turbo" which is likely at least part of the problem here.

If I clear it with recent vc4 firmware my CPPC code works, if its get set by uefi during boot, it locks the clock at either the factory 1.5 Ghz, or the manually entered clock rate in config.txt. The worse part is that once its "locked" further calls to the firmware don't seem to change it.

[jlinton]

     //
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
index afda5ffaa6..848e3d830c 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
@@ -413,7 +413,7 @@ ApplyVariables (

   if (Rate != 0) {
     DEBUG ((DEBUG_INFO, "Setting CPU speed to %u MHz\n", Rate / FREQ_1_MHZ));
-    Status = mFwProtocol->SetClockRate (RPI_MBOX_CLOCK_RATE_ARM, Rate, 1);
+    Status = mFwProtocol->SetClockRate (RPI_MBOX_CLOCK_RATE_ARM, Rate, 0);^M
     if (Status != EFI_SUCCESS) {

[worproject]

So setting it to 0 fixes the issue? On a Pi 3 it's the opposite.

[jlinton]

Yes, this is a pi4. Firmware from a month or so ago. I get the impression that this is one of those things that changes depending on which vc4 firmware your running.

(I wish the vc4 firmware splatted its version number) the sha1 of mine is: sha1sum start4.elf 4682394c076bd26a2a57b034dda28b4c3bb93658 start4.elf

[worproject]

https://github.com/raspberrypi/firmware/issues/1521

I think it's better to remove the overclocking option from UEFI, as we don't have access to the over_voltage settings anyway.