Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 26 Sep 2020 00:38:12 -0700
From:      Mark Millard <marklmi@yahoo.com>
To:        freebsd-arm <freebsd-arm@freebsd.org>
Subject:   RPi4B u-boot based booting and hw.cpufreq.voltage_core and dev.cpu.0.freq use: able to use 2000 MHz
Message-ID:  <0578EC2B-D21C-46AA-AD3E-CD13985B18FA@yahoo.com>
References:  <0578EC2B-D21C-46AA-AD3E-CD13985B18FA.ref@yahoo.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

I'll note that the following changes resulted (-: 600 MHz
[before], +: 2000 MHz [after]) on a basically idle RPi4B:

-hw.cpufreq.temperature: 45000
+hw.cpufreq.temperature: 48000

-hw.cpufreq.voltage_core: 951250
+hw.cpufreq.voltage_core: 1006250

-hw.cpufreq.turbo: 0
+hw.cpufreq.turbo: 1

-hw.cpufreq.core_freq: 200000000
+hw.cpufreq.core_freq: 500000000

-hw.cpufreq.arm_freq: 600000000
+hw.cpufreq.arm_freq: 2000000000

-dev.cpu.0.freq: 600
+dev.cpu.0.freq: 2000

Note: over_voltage contributes to hw.cpufreq.voltage_core
and the higher figures are required to be in place before
dev.cpu.0.freq is increased --if things are to work.


Other notes about the configuration:

=>      63  62333889    mmcsd0  MBR  (30G)
        63     32705            - free -  (16M)
     32768    163840  mmcsd0s1  fat32lba  [active]  (80M)
    196608  54525952  mmcsd0s2  freebsd  (26G)
  54722560   7611392            - free -  (3.6G)
=>       0  54525952   mmcsd0s2  BSD  (26G)
         0  54525952  mmcsd0s2a  freebsd-ufs  (26G)

=>       40  468862048    da0  GPT  (224G)
         40       2008         - free -  (1.0M)
       2048  413138944  da0p1  freebsd-ufs  (197G)
  413140992    9437184  da0p2  freebsd-swap  (4.5G)
  422578176     204800  da0p3  ms-basic-data  (100M)
  422782976   46079112         - free -  (22G)

Although a microsd card is involved in booting the u-boot
configuration, the USB3 SSD and the root file system used
on it are the same ones as for the rpi4-uefi-devel ACPI
based booting that I do. For the u-boot based booting,
the kernel loads from the microsd card, not USB. FreeBSD's
lkernel find the USB3 SSD materials, not u-boot or the
bootaa64.efi . There are a few other UFS files that the
very early activity use copies of that are on the microsd
card.


msdos file system:

drwxr-xr-x  25 root  wheel     1024 Sep 25 22:50:25 2020 ..
-rwxr-xr-x   1 root  wheel      164 Sep 25 22:50:16 2020 config.txt
drwxr-xr-x   1 root  wheel     1024 Jul 14 18:43:24 2020 OVERLAYS
-rwxr-xr-x   1 root  wheel    47413 Jul 14 16:01:00 2020 bcm2711-rpi-4-b.dtb
-rwxr-xr-x   1 root  wheel  2277248 Jul 14 16:01:00 2020 start4.elf
-rwxr-xr-x   1 root  wheel     5409 Jul 14 16:00:58 2020 fixup4.dat
-rwxr-xr-x   1 root  wheel     4592 Jul 14 15:57:48 2020 Readme.md
-rwxr-xr-x   1 root  wheel   514272 Jul 13 11:56:54 2020 u-boot.bin
-rwxr-xr-x   1 root  wheel     5888 Jan 30 13:26:30 2020 armstub8-gic.bin
-rwxr-xr-x   1 root  wheel    18693 Nov 22 09:06:44 2019 COPYING.linux
-rwxr-xr-x   1 root  wheel     1594 Nov 22 09:06:44 2019 LICENCE.broadcom
drwxr-xr-x   1 root  wheel     1024 Sep 27 21:05:00 2018 EFI
drwxr-xr-x   1 root  wheel     2048 Dec 31 16:00:00 1979 .

The RPi4B files with Jul 14 dates were likely from the rpi4-uefi-devel
v1.17 release. They are not from a /usr/ports/sysutils/rpi-firmware/
build. (I removed the v1.17 RPI_EFI.fd while setting this up.)

# ls -laTt OVERLAYS/
total 9
drwxr-xr-x  1 root  wheel  1024 Jul 14 18:43:24 2020 .
-rwxr-xr-x  1 root  wheel  1073 Jul 14 18:43:14 2020 disable-bt.dtbo
-rwxr-xr-x  1 root  wheel  1819 Jul 14 16:01:00 2020 miniuart-bt.dtbo
-rwxr-xr-x  1 root  wheel  1221 Nov 22 09:06:44 2019 mmc.dtbo
drwxr-xr-x  1 root  wheel  2048 Dec 31 16:00:00 1979 ..

(Looks like I still have a /usr/ports/sysutils/rpi-firmware/ based
mmc.dtbo . Likely that vintage is not a requirement and matching
close to the July material dates would be okay.)

I'll note that I got disable-bt.dtbo from the raspberry pi github
areas, deliberately matching timeframes. rpi4-uefi-devel does not
include it, nor mmc.dtbo.

# ls -laTt EFI/BOOT/bootaa64.efi 
-rwxr-xr-x  1 root  wheel  705776 Sep 20 20:41:44 2020 EFI/BOOT/bootaa64.efi

bootaa64.efi I updated ( copy of loader.efi ).


As for UFS on the microsd card:

# ls -laT
total 32
drwxr-xr-x   6 root  wheel      512 Sep 25 21:17:39 2020 .
drwxr-xr-x  25 root  wheel     1024 Sep 25 22:50:25 2020 ..
drwxrwxr-x   2 root  operator   512 Jul 19 16:35:45 2020 .snap
-r--r--r--   1 root  wheel     6170 Feb  1 04:48:34 2020 COPYRIGHT
drwxr-xr-x  24 root  wheel     1536 Sep 25 22:06:40 2020 boot
drwxr-xr-x   2 root  wheel      512 Sep 25 21:38:41 2020 etc
drwx------   2 root  wheel      512 Nov 27 09:46:08 2019 lost+found

boot is a complete copy of the head -r365932 one on the USB3 SSD's
ufs file system ( other than managing boot/entropy ). I'll not list
its contents here.

# ls -ldT etc/*
-rw-r--r--  1 root  wheel  236 Sep 25 21:50:27 2020 etc/fstab
-rw-r--r--  1 root  wheel   37 Dec 31 16:00:18 2009 etc/hostid

Both these match the USB3 SSD's /etc/ files by content.

# more etc/fstab
/dev/gpt/RPi4Broot      /               ufs rw,noatime          1 1
#
/dev/label/RPi4root     /microsd_ufs    ufs rw,noatime,noauto   1 1
#
/dev/gpt/RPi4Bswap      none            swap sw                 0 0
#
/dev/msdosfs/RPI4BEFI   /usb_efi        msdosfs rw,noatime      0 0
/dev/label/RPi4boot     /microsd_efi    msdosfs rw,noatime,noauto       0 0

I use various types of labels to identify partitions and/or
file systems (gpt, glabel label, msdosfs). The /dev/gpt/ ones
and the /dev/msdosfs/ one are on the USB3 SSD. The /deve/label/
ones are on the microsd card.

I avoided using /boot/efi notation, making usb [for uefi/ACPI)
vs. microsd (for u-boot) explicit instead and allowing both
to be mounted at the same time in their normal places (when
booted via u-boot).


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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0578EC2B-D21C-46AA-AD3E-CD13985B18FA>