rpi4 won't overclock

[Mark Millard]

tech-lists tech-lists at zyxst.net wrote on
Sun Sep 6 14:58:30 UTC 2020 :

> I can't oc the pi in the usual way with -current on rpi4. Obviously I'm doing
> something wrong, but I don't know what.
> 
> If I put parameters in config_rpi4.txt, they're seemingly ignored.

Yep: config_rpi4.txt is just an example of what the config.txt file
contents should be like for a RPi4B. FreeBSD is not using the [...]
notation to be selective about what applies to what context and is
not using the include mechanism.

So use of config.txt tailoring is involved.

> If I take
> these out of there and put them instead at the bottom of config.txt, the pi
> will fail to boot (I think it's failing u-boot, it says, in VGA, it needs
> newer firmware).

Have you tried making config.txt a strict copy of config_rip4.txt
with no other changes and it still fails to boot?

Note: My context is based on head -r363590 .

> I've installed to rpi4 as per
> 
> https://lists.freebsd.org/pipermail/freebsd-arm/2020-August/022162.html

This is not what I've done since I experiment with uefi/ACPI
based booting and such. Even back when I tried u-boot I did
not do it the above way. (I've not tracked the u-boot based
contexts in some time.) This paragraph mostly is just noting
that I'm of limited/no help on those details.

> The parameters I want to use are:
> 
> arm_freq=2100
> gpu_freq=750
> over_voltage=6

Last I knew, u-boot style booting ignored/overrides what config.txt has
for the likes of arm_freq and probably more. It is set up for changing
settings from FreeBSD later --but FreeBSD may have no equivalent of
over_voltage=6 for all I know. (The FreeBSD u-boot based RPi3B that I
have access to behaves similarly for FreeBSD. boot -s always ends
up at a 600 MHz before something I put in /etc/sysctl.conf changes
the setting.)

The uefi/ACPI alternative for the RPi4B does use use the config.txt
settings, even as seen via boot -s. (This is the environment I
normally experiment with for the RPi4B.)

I use over_voltage=6 and arm_freq=2000 on multiple RPi4B's. (I do not
adjust gpu_freq.) This makes the clock rate match a MACCHIATObin Double
Shot and has been reliable on the RPi4B's (4 GiB and 8 GiB). (Memory
subsystem properties make the MACCHIATObin faster at various
activities.)

I did do some margin testing initially and figures around 2100 were
not reliable for keeping the RPi4B's operating. Of course, various
things can contribute to what setting work with some margin for
environment variability. I've got heatsinks, fans, and (apparently)
good power.

So far as I know, using the uefi/ACPI and the over_voltage=6 and
arm_freq=2000 leads to a context that runs at an essentially fixed
frequency, even when idle.

> Even with make -j4 it sits stubbornly at 0.6GHz.

It has been a long time since I've tried u-boot based for
the RPi4B.

For the OPi+2E, Rock64, RPi3B I use in /etc/sysctl.conf :

dev.cpu.0.freq=1008 # OPi+2E
dev.cpu.0.freq=1200 # Rock64 and RPi3B

but for the RPi4B with the uefi/ACPI style boot process there
is no sysctl dev.cpu.0.freq to assign or inspect.

So far as I know, the dev.cpu.0.freq assignments lead to
fix frequency operation: as I have not done anything
explicit to cause dynamic changes. Again: heatsinks, fans,
and good power.

I'll note that my experiments with timing rebuilds (from
scratch) ended up with times being shortest for -j3 for
the RPi4B. (Not surprising given the memory subsystem
properties from what I can tell.)

> The cpu is usually below 40
> degC in a 20 degC environment. It'll go to 46 degC when make buildkernel runs.
> 
> I've tried much lower parameters with the same result. What am I doing wrong?

Overall, I do not know. But maybe some of the above will be
of use.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)