Re: rpi4 won't overclock

tech-lists <[email protected]> Mon, 7 Sep 2020 15:42:12 +0100
Newsgroups	gmane.os.freebsd.devel.arm
Message-ID	<[email protected]>
Hi,

On Sun, Sep 06, 2020 at 05:31:15PM -0700, Mark Millard wrote:
>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?

Yes, just tried that. It will boot but it fails to boot if I set overclocking parameters in
config.txt. I get to a screen that complains about newer firmware. It doesn't
get as far as u-boot. I took the card out and amended it on another machine,
then put it back in the rpi4. It boots, and config.txt looks like this:

arm_control=0x200
arm_64bit=1
dtoverlay=disable-bt
dtoverlay=mmc
device_tree_address=0x4000
kernel=u-boot.bin
armstub=armstub8-gic.bin
#gpu_mem=16
#over_voltage=6
#arm_freq=2100

>Note: My context is based on head -r363590 .

I'm now using r365391 on the pi4
>
>> 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.)

On my rpi3 12.1-STABLE r363237 GENERIC I have the following in
/boot/msdos/config.txt:

arm_control=0x200
dtparam=audio=on,i2c_arm=on,spi=on
dtoverlay=mmc
dtoverlay=pwm
dtoverlay=disable-bt
device_tree_address=0x4000
kernel=u-boot.bin
#force_turbo=1
gpu_mem=16
arm_freq=1500
over_voltage=4

which normally gives 1.5GHz under load, nothing in /etc/sysctl.conf is setting
this parameter. I have just enabled powerd and rebooted, but it hasn't come
back so I suspect in my case it's applying config.txt but there's a powerd <->
config.txt interaction happening preventing it from booting.


>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.

I'm using dedicated power supplies made for rpi3 and rpi4. Am using heatsinks
on the rpi3 in a clear plastic case on the rpi3 and a FLIRC aluminium heatsink
case on the rpi4.

>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.

I have now got it to 1500 thanks to
https://lists.freebsd.org/pipermail/freebsd-arm/2020-September/022279.html

The very highest temperature it got to was 61 degC in 25 degC ambient with
make -j4 buildworld

>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

I'll try that on the rpi3. Do you use powerd? on either rpi3 or rpi4.
  
>but for the RPi4B with the uefi/ACPI style boot process there
>is no sysctl dev.cpu.0.freq to assign or inspect.

Can you explain what you mean by uefi/ACPI style boot process? Or is there a
link that explains it. I only know of one boot process with freebsd on rpi
boards, and thats via u-boot. On my rpi4 I have that sysctl, and can modify
it:

freebsd@rpi4 ~ % sysctl dev.cpu.0.freq
dev.cpu.0.freq: 600
freebsd@rpi4 ~ % sudo sysctl dev.cpu.0.freq=2000
dev.cpu.0.freq: 600 -> 1500

reebsd@rpi4 ~ % sysctl -a | grep dev.cpu.0.
dev.cpu.0.temperature: 49.0C
dev.cpu.0.freq_levels: 1500/-1 600/-1
dev.cpu.0.freq: 1500
dev.cpu.0.%parent: cpulist0
dev.cpu.0.%pnpinfo: name=cpu@0 compat=arm,cortex-a72
dev.cpu.0.%location: 
dev.cpu.0.%driver: cpu
dev.cpu.0.%desc: Open Firmware CPU

>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.

yeah it seems once set, it stays there. But because freq_levels has only two
values, I can only set one or the other of these values. 2000 is not
available. If I don't set it in the sysctl, speed becomes dynamic according to
load.

>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.)

Thanks, I'll try that next time I rebuild the kernel.

>> 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.

It is useful, many thanks.

How are you booting your rpi4s if not via u-boot? You're setting parameters in
config.txt for the rpi4 ?
-- 
J.
signature.asc (application/pgp-signature, 833 B)