RPI4 clock speeds and serial port
Mark Millard
marklmi at yahoo.com
Thu Mar 18 20:01:19 UTC 2021
On 2021-Mar-18, at 12:05, Mark Millard <marklmi at yahoo.com> wrote:
> On 2021-Mar-18, at 10:00, bob prohaska <fbsd at www.zefox.net> wrote:
>
>>> Having now got an 8GB Pi4 to use for FreeBSD the machine seems to
>>> be relatively slow at buildworld, taking some 18 hours for a clean
>>> start buildworld. Sysctl -a | grep freq reports in part:
>>>
>>> ....
>>>
>>> hw.cpufreq.turbo: 0
>>> hw.cpufreq.sdram_freq: 400000000
>>> hw.cpufreq.core_freq: 200000000
>>> hw.cpufreq.arm_freq: 600000000
>>> hw.clock.108MHz-clock.frequency: 0
>>> hw.clock.27MHz-clock.frequency: 0
>>> hw.clock.otg.frequency: 0
>>> hw.clock.osc.frequency: 0
>>> dev.iicbus.0.frequency: 100000
>>> dev.cpufreq.0.freq_driver: bcm2835_cpufreq0
>>> dev.cpufreq.0.%parent: cpu0
>>> dev.cpufreq.0.%pnpinfo:
>>> dev.cpufreq.0.%location:
>>> dev.cpufreq.0.%driver: cpufreq
>>> dev.cpufreq.0.%desc:
>>> dev.cpufreq.%parent:
>>> dev.bcm2835_cpufreq.0.freq_settings: 1500/-1 600/-1
>>> dev.bcm2835_cpufreq.0.%parent: cpu0
>>> dev.bcm2835_cpufreq.0.%pnpinfo:
>>> dev.bcm2835_cpufreq.0.%location:
>>> dev.bcm2835_cpufreq.0.%driver: bcm2835_cpufreq
>>> dev.bcm2835_cpufreq.0.%desc: CPU Frequency Control
>>> dev.bcm2835_cpufreq.%parent:
>>> dev.cpu.0.freq_levels: 1500/-1 600/-1
>>> dev.cpu.0.freq: 600
>>> dev.iichb.0.frequency: 100000
>>>
>>> /boot/msdos/config.txt contains
>>>
>>> root at nemesis:~ # more /boot/msdos/config.txt
>>> [all]
>>> arm_64bit=1
>>> dtparam=audio=on,i2c_arm=on,spi=on
>>> dtoverlay=mmc
>>> dtoverlay=disable-bt
>>> device_tree_address=0x4000
>>> kernel=u-boot.bin
>>>
>>> [pi4]
>>> #hdmi_safe=1
>>> armstub=armstub8-gic.bin
>>>
>>> There is no /boot/msdos/cmdline.txt file.
>>>
>>> Can one change the cpu speed without disturbing the serial console
>>> by using something like
>>>
>>> arm_freq=1750
>>>
>>> in config.txt, provided adequate cooling provisions are made?
>>>
>>> I'd rather not complicate use of the serial console at this point.
>>
>
> I've never had the CPU clock rate or memory clock rate
> mess with the serial console behavior.
I forgot to mention that the claim is for the
context:
dtoverlay=disable-bt
or:
dtoverlay=miniuart-bt
These avoid the miniUART being used for the
serial console. The miniUART is cpu/gpu
speed dependent.
> You are not clear if your build was one that
> reported messages like:
>
> make[1]: "/usr/fbsd/mm-src/Makefile.inc1" line 339: SYSTEM_COMPILER: Determined that CC=cc matches the source tree. Not bootstrapping a cross-compiler.
> make[1]: "/usr/fbsd/mm-src/Makefile.inc1" line 344: SYSTEM_LINKER: Determined that LD=ld matches the source tree. Not bootstrapping a cross-linker.
>
> The builds will take much longer when the bootstrap
> compiler and linker are also built.
>
>
>
> I presume u-boot style booting below, not UEFI/ACPI.
>
> Overall to cut buildworld buildkernel
> times I've controlled:
>
> voltage and current (power)
> cooling
> cpu clock rate
> ram clock rate
> the code generation's tuning
> system built targeting non-debug buildworld buildkernel
> (but I still cause -g to be in use)
>
> The details follow.
>
> I use:
>
> # more /boot/efi/config.txt
> arm_64bit=1
> enable_uart=1
> uart_2ndstage=1
> dtdebug=1
> disable_commandline_tags=1
> disable_overscan=1
> device_tree_address=0x4000
> dtoverlay=disable-bt
> dtoverlay=mmc
> armstub=armstub8-gic.bin
> kernel=u-boot.bin
> gpu_mem_1024=32
> # For speeding things up:
> over_voltage=6
> arm_freq=2000
> arm_freq_min=2000
> sdram_freq_min=3200
>
> The last 4 lines are tied to the use of
> faster clocking. In my context, an
> over_voltage use is required. I've
> not tried to figure out the minimal
> (low amrgin) change, just a sufficient
> one.
>
> Note that the above also controls the
> RAM speed, not just the CPU speed. The
> difference was rather significant for
> my buildworld buildkernel timing
> experiments, even with the cpu frequency
> already controlled to be 2000 MHz.
>
> Your:
>
>>> dev.cpu.0.freq_levels: 1500/-1 600/-1
>
> It not a list of the possible clock speeds.
> It is just a list of which ones are compatible
> with the arm_freq that you assign (or the
> default if unassigned). In other words, for
> example, using arm_freq=2000 will lead to
> seeing a different list of levels.
>
> I'll note that every one of the 6 RPi4B that
> I've had access to has operated at
> arm_freq=2000 just fine when properly configured.
> I run them all that way.
>
> I also use in /etc/sysctl.conf :
>
> # The u-boot'ed RPi4B does not seem to automatically
> # adjust from 600MHz, # so do so manually. Presumes
> # config.txt does over_voltage=6 and arm_freq=2000 .
> # NOTE: without an appropriate over_voltage a
> # dev.cpu.0.freq=2000 will crash the RPi4B on the
> # spot.
> dev.cpu.0.freq=2000
>
> (So I do not use powerd .) This goes along with
> the config.txt having "arm_freq_min=2000". So
> in my context, the RPi4B's run at a basically
> constant speed (cpu and ram).
>
> I use /etc/sysctl.conf above because:
>
> # sysctl -aW | grep freq | more
> kern.acct_chkfreq: 15
> debug.cpufreq.verbose: 0
> debug.cpufreq.lowest: 0
> hw.cpufreq.voltage_sdram_p: 1100000
> hw.cpufreq.voltage_sdram_i: 1100000
> hw.cpufreq.voltage_sdram_c: 1100000
> hw.cpufreq.voltage_core: 1000000
> hw.cpufreq.turbo: 0
> hw.cpufreq.sdram_freq: -1094967296
> hw.cpufreq.core_freq: 200000000
> hw.cpufreq.arm_freq: 2000000000
> dev.cpu.0.freq: 2000
>
> but:
>
> # sysctl -aT | grep freq | more
> debug.cpufreq.verbose: 0
> debug.cpufreq.lowest: 0
> debug.uart_poll_freq: 50
>
> so the setting would not work in
> /boot/loader.conf . (-aT shows what
> loader.conf can set and -aW shows
> what /etc/sysctl.conf can set. Some
> things are listed for both overall,
> others are not.)
>
> (Too bad hw.cpufreq.sdram_freq is displayed
> as a signed value: it really is not.)
>
> The RPi4B's that I have access to all have
> heatsinks and are actively cooled (fans).
> (The detailed case styles vary significantly
> but all are effectively cooled.)
>
> I use CanaKit USB-C 5.1V 3.5A power supplies
> and use a USB3 SSD plugged in directly with
> no external power. The 3.5A is somewhat
> more than the standard RPi* power supply
> has for the RPi4B (3.1A) and I wanted the
> margin for the USB3 SSD use.
>
> I do one more thing to speed up operation
> of the RPI4B, but it is in how code is
> generated by buildworld buildkernel. My
> equivalent of src.conf uses:
>
> # more ~/src.configs/src.conf.cortexA72-clang-bootstrap.aarch64-host
> . . .
> #
> # Use of the .clang 's here avoids
> # interfering with other C<?>FLAGS
> # usage, such as ?= usage.
> CFLAGS.clang+= -mcpu=cortex-a72
> CXXFLAGS.clang+= -mcpu=cortex-a72
> CPPFLAGS.clang+= -mcpu=cortex-a72
> ACFLAGS.arm64cpuid.S+= -mcpu=cortex-a72+crypto
> ACFLAGS.aesv8-armx.S+= -mcpu=cortex-a72+crypto
> ACFLAGS.ghashv8-armx.S+= -mcpu=cortex-a72+crypto
>
> This controls the tuning used in the code
> generation for buildworld and buildkernel.
> Once the resulting system was in use, this
> also had a significant effect on the later
> build times for buildworld buildkernel .
>
> There can be a large difference between a
> cortex-a53's strictly in-order execution
> and the cortex-a72's out of order allowed
> execution. (The same architecture vintage
> allows for both styles.) I expect that
> this difference is why the tuning mattered
> so much: arranging for out of order to be
> an advantage.
>
> I use -mcpu because it sets both the -march
> and the -mtune to match the cpu type and
> is sorter than listing both explicitly.
>
> The kernel configuration is shown below.
>
> # more sys/arm64/conf/GENERIC-NODBG
> #
> # GENERIC -- Custom configuration for the arm64/aarch64
> #
>
> include "GENERIC"
>
> ident GENERIC-NODBG
>
> makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols
>
> options ALT_BREAK_TO_DEBUGGER
>
> options KDB # Enable kernel debugger support
>
> # For minimum debugger support (stable branch) use:
> #options KDB_TRACE # Print a stack trace for a panic
> options DDB # Enable the kernel debugger
>
> # Extra stuff:
> #options VERBOSE_SYSINIT=0 # Enable verbose sysinit messages
> #options BOOTVERBOSE=1
> #options BOOTHOWTO=RB_VERBOSE
> #options KTR
> #options KTR_MASK=KTR_TRAP
> ##options KTR_CPUMASK=0xF
> #options KTR_VERBOSE
>
> # Disable any extra checking for. . .
> nooptions DEADLKRES # Enable the deadlock resolver
> nooptions INVARIANTS # Enable calls of extra sanity checking
> nooptions INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS
> nooptions WITNESS # Enable checks to detect deadlocks and cycles
> nooptions WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed
> nooptions DIAGNOSTIC
> nooptions MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones
> nooptions BUF_TRACKING
> nooptions FULL_BUF_TRACKING
>
>
>
> Just FYI:
>
> # sysctl -a | grep freq | more
> kern.timecounter.tc.ARM MPCore Timecounter.frequency: 54000000
> kern.eventtimer.et.ARM MPCore Eventtimer.frequency: 54000000
> kern.acct_chkfreq: 15
> debug.cpufreq.verbose: 0
> debug.cpufreq.lowest: 0
> debug.uart_poll_freq: 50
> hw.cpufreq.temperature: 34525
> hw.cpufreq.voltage_sdram_p: 1100000
> hw.cpufreq.voltage_sdram_i: 1100000
> hw.cpufreq.voltage_sdram_c: 1100000
> hw.cpufreq.voltage_core: 1000000
> hw.cpufreq.turbo: 0
> hw.cpufreq.sdram_freq: -1094967296
> hw.cpufreq.core_freq: 200000000
> hw.cpufreq.arm_freq: 2000000000
> hw.clock.108MHz-clock.frequency: 0
> hw.clock.27MHz-clock.frequency: 0
> hw.clock.otg.frequency: 0
> hw.clock.osc.frequency: 0
> dev.cpufreq.0.freq_driver: bcm2835_cpufreq0
> dev.cpufreq.0.%parent: cpu0
> dev.cpufreq.0.%pnpinfo:
> dev.cpufreq.0.%location:
> dev.cpufreq.0.%driver: cpufreq
> dev.cpufreq.0.%desc:
> dev.cpufreq.%parent:
> dev.bcm2835_cpufreq.0.freq_settings: 2000/-1 600/-1
> dev.bcm2835_cpufreq.0.%parent: cpu0
> dev.bcm2835_cpufreq.0.%pnpinfo:
> dev.bcm2835_cpufreq.0.%location:
> dev.bcm2835_cpufreq.0.%driver: bcm2835_cpufreq
> dev.bcm2835_cpufreq.0.%desc: CPU Frequency Control
> dev.bcm2835_cpufreq.%parent:
> dev.cpu.0.freq_levels: 2000/-1 600/-1
> dev.cpu.0.freq: 2000
>
> (Again: Too bad hw.cpufreq.sdram_freq is
> displayed as a signed value: it really
> is not signed.)
>
> FYI: The system is based on main 7381bbee29df
> (2021-03-12), the build that fixed the
>
> # ~/fbsd-based-on-what-freebsd-main.sh
> merge-base: 7381bbee29df959e88ec59866cf2878263e7f3b2
> merge-base: CommitDate: 2021-03-12 20:29:42 +0000
> def0058cc690 (HEAD -> mm-src) mm-src snapshot for mm's patched build in git context.
> 7381bbee29df (freebsd/main, freebsd/HEAD, pure-src, main) cam: Run all XPT_ASYNC ccbs in a dedicated thread
> FreeBSD RPi4B 14.0-CURRENT FreeBSD 14.0-CURRENT mm-src-n245445-def0058cc690 GENERIC-NODBG arm64 aarch64 1400005 1400005
I've not done temperate testing in a
while. One quick report I can make
is that for my "always cpu_freq 2000
always sdram_freq 3200" contexts
with the RPI4B only doing whatever
background tasks are involved in
being basically idle but having
the heatsinks and active cooling
(fans):
# sysctl -a | grep temper
hw.cpufreq.temperature: 35012
dev.cpu.0.temperature: 35.0C
in a currently 15.5C or so ambient
context is rather typical.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
More information about the freebsd-arm
mailing list