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 19:01, Mark Millard <marklmi at yahoo.com> wrote:

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

Turns out that gpu_mem=32 works for the 8 GiByte
RPi4B. (Note: I do have a display connected but
no X11m just a console login prompt.)

But gpu_mem=16 prevents further I/O to the microsd
card during the early RPi stages of things, before
FreeBSD is involved:

. . .
rsc 32 fat-sectors 635 c-count 81269 c-size 2 r-dir 2 r-sec 0
Read config.txt bytes      177 hnd 0x00006938 hash '9be9ccf1915ff016'
recover4.elf not found (6)
recovery.elf not found (6)
start4cd.elf not found (6)
start_cd.elf not found (6)
Firmware not found
ERROR: 00000004
. . . 

In my context it then tried booting from the USB3
SSD and that worked. (Only the microsd card had
gpu_mem=16 but I'm not sure if the config.txt
from the USB3 SSD was read or not. The USB3
SSD booting is set up for uefi/ACPI booting
experiments. The microsd card was set up for
u-boot booting experiments [when it gets that
far].)


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