Re: RPI4 clock speeds and serial port

On 2021-Mar-18, at 12:05, Mark Millard <[email protected]> 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@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)

_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[email protected]"