RPi4B u-boot based booting and hw.cpufreq.voltage_core and dev.cpu.0.freq use: able to use 2000 MHz

[Mark Millard]

On 2020-Sep-26, at 13:20, Mark Millard <marklmi at yahoo.com> wrote:

> On 2020-Sep-26, at 06:39, tech-lists <tech-lists at zyxst.net> wrote:
> 
>> On Sat, Sep 26, 2020 at 12:37:45AM -0700, Mark Millard via freebsd-arm wrote:
>>> I got access to a 4 GiByte RPi4B that does not have modernized
>>> eeprom contents. With it I was able to do a u-boot based boot
>>> of head -r365932 based on the msdosfs on a older microsd card
>>> that had materials from 2020-Jul-13 (u-boot.bin) and 14 (RPi4B
>>> materials). I updated EFI/BOOT/bootaa64.efi . The u-boot.bin
>>> is from my build of sysutils/u-boot-rpi4/ (no local changes).
>>> 
>>> In this context . . .
>>> 
>>> I added over_voltage=6 and arm_freq=2000 to config.txt and it
>>> ends up looking like:
>>> 
>>> arm_control=0x200
>>> arm_64bit=1
>>> dtoverlay=disable-bt
>>> dtoverlay=mmc
>>> device_tree_address=0x4000
>>> kernel=u-boot.bin
>>> armstub=armstub8-gic.bin
>>> over_voltage=6
>>> arm_freq=2000
>>> 
>>> 
>>> Booting based on that resulted in:
>>> 
>>> dev.bcm2835_cpufreq.0.freq_settings: 2000/-1 600/-1
>>> dev.cpu.0.freq_levels: 2000/-1 600/-1
>>> dev.cpu.0.freq: 600
>>> 
>>> And:
>>> 
>>> # sysctl dev.cpu.0.freq=2000
>>> dev.cpu.0.freq: 600 -> 2000
>>> 
>>> worked. (Without the over_voltage it reports 600 and then
>>> hangs.) Having /etc/sysctl.conf list dev.cpu.0.freq=2000
>>> works.
>> 
>> Exellent! On the basis of your post I went ahead and removed from config.txt
>> three lines, then added two and rebooted.
>> 
>> It's now this:
>> 
>> arm_control=0x200
>> arm_64bit=1
>> dtoverlay=disable-bt
>> dtoverlay=mmc
>> device_tree_address=0x4000
>> kernel=u-boot.bin
>> armstub=armstub8-gic.bin
>> over_voltage=6
>> arm_freq=2000
>> 
>> before, when it didn't work, it had this:
>> [same as above], apart from
>> gpu_mem=16
>> over_voltage=6
>> arm_freq=2100
>> 
>> In creating the freebsd instance I followed these instructions for 8GB
>> https://lists.freebsd.org/pipermail/freebsd-arm/2020-August/022162.html
>> and applied D26344. /etc/rc.conf has powerd loaded
>> 
>> I was particularly interested in getting this clocked to a reasonable speed as
>> it's used to build packages with poudriere based on arm7 and aarch64 for
>> -current.
> 
> The cortex-A72 is largely memory subsystem limited on the
> RPi4B compared to, say, the MACCHIATObin Double Shot
> running at the same clock rate.
> 
> So I've recently experimented with changing the
> sdram_freq_min from the default or 400 to 3200
> (to match sdram_freq):
> 
> # more /microsd_efi/config.txt
> arm_control=0x200
> arm_64bit=1
> dtoverlay=disable-bt
> dtoverlay=mmc
> device_tree_address=0x4000
> kernel=u-boot.bin
> armstub=armstub8-gic.bin
> over_voltage=6
> arm_freq=2000
> sdram_freq_min=3200
> 
> A benchmark I use suggests I'll see the fastest RPi4B
> buildworld buildkernel times that I've seen yet when I 
> get around to trying that. ( My benchmarking and testing
> is based on powerd or the like not being in use but the
> kernel or rpi-firmware could be doing its own thing
> given the above and sysctl.conf having
> dev.cpu.0.freq=2000 .)

Preiminary benchmarking indicates that rpi4-uefi-devel's
uefi/ACPI context effectively ends up with
sdram_freq_min=3200 ignored (making no difference).
(In my context, it is the same FreeBSD root file system
for both types of boots, so only boot-specific code
varies.)

Thus, it looks like the u-boot context can be better
tailored for cutting the buildworld buildkernel time
required and so it looks like that is the environment
that I will be timing a from-scratch build in.

The ACPI context does not have a sysctl interface
to the values that the u-boot one has. So u-boot
based is more direct for validating what is in use.

> I have heatsinks and a fan involved, as well as a
> (apparently good) 5.1v 3.5A power supply. My experiments
> presume such a context.
> 
> (I've sent out a separate list message about hw.cpufreq.sdram_freq
> having a value-display problem and the 3 hw.cpufreq.voltage_sdram_*
> values looking to be lower than expected. I've not seen evidence
> of problems in operation so far.)
> 
> I'll note that:
> 
> https://www.raspberrypi.org/documentation/configuration/config-txt/boot.md
> 
> reports:
> 
> QUOTE
> arm_control
> 
> DEPRECATED - use arm_64bit to enable 64-bit kernels.
> 
> Sets board-specific control bits.
> END QUOTE
> 
> So I'm likely to experiment with removing that line
> from config.txt .
> 
> 
>> seems very stable so far:
>> 
>> 2:36p.m.  up 45 mins, 1 user, load averages: 6.51, 3.57, 2.92
>> Sat 26 Sep 2020 14:36:14 BST
>> dev.cpu.0.temperature: 65.0C
>> dev.cpu.0.freq_levels: 2000/-1 600/-1
>> dev.cpu.0.freq: 2000
>> 
>> rpi4 is in a FLIRC case for cooling, no fan. 24 degC/44%rh ambient.
>> 
> 
> 




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