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

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)