From owner-freebsd-arm@freebsd.org Thu Mar 18 19:06:05 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 068DB5A91C9 for ; Thu, 18 Mar 2021 19:06:05 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4F1c1m0GS0z4c2P for ; Thu, 18 Mar 2021 19:06:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1616094362; bh=cufPjXKVasZmci9+ESHn+MiBOcKV9EKy/JR/LeVXYwv=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=X5t4lfMO041c/dGqboi3iUPmpghSeoUx/KER5jGOqYuVTh7Fg1AhaLACeSG5QOwaGFekkB8RBEsxq/e4oH2jfah+/DoBK8b2XRBJ3eGN/H8s4Ty11Vqp8S/jAxAfqyxoLhkPne9Ar5KnE+4yPAXuRFwXialnHYXl29fUHkTXnwc609W9lHq9LWoGK6elP/lI4x1MPSnPWkYGp/NUmeMNU7cpuegLaOU2iCjfBaczPjQjz8c06ClzhDvy3CrbR5vaAJnJFK6Q/efYDRaZp1HYNcjoUs+7NGbWXhBmnbPo+I2LW5D8FEsrI9fGrE8YQYqd0gL7JtdGFjyQGPTEng1fWw== X-YMail-OSG: iUZQzMQVM1nUVnxRnAEaTVFulVzDetHDyuBtmk3cYj0jpGewRl0ZhHwLZpp3iQA Iu.L6rYNKLJrVXi_5Ls.4DFylFMHTjY0Kn.FfvcA.OYQUt54asn06wOraQd4AOYPbDrhoWBv0G_U o6ZYoqtfmZdyHfyLsS2BR2Tavx4Ax_VCeKAZYkjNXR1DMMbuMemzaIum945I.HUkAU6L3ZFaS0pj PWacSBVa7U1O3IqCr4WUSmTRbfNqZ6VWZ2wrj.8.NxaP_bQzwW7g_rS2bmBI.sNjPwM7hDE8oVed EX2BxjWlM3O8HFKD.b7JZkk5wX_Tx.1OK8RJtBhaaf4p5e2qs8_xRMXZ.4cqf9t9i6iL6RmG.FmJ NojtStO31QN_Ea.AkjAs8jmLgyJbIzjuHqp8mPaL3IgYh4lfADYw2B6ZOt4OzzgFCbjCjDe5HVFB iNrXZliiqhc2xg9_DcP1r3LoM0bTO.EBmxCLnAgmO3tkMRNr.cG_R13_n3QytzMBmyz4dlT3U.Eb pGdD1C8l5TQ7UfGDQ8L4Um_0UnuSEr2ttI_pZAuq4we0SvFveWBpve5Bs0Q7PbTuhJrjw.DOQ6ID LW7eTQHDCuRYC9.5Di2vM5cnCaM3CbvIJ5Lxmv33M3LClJDM8rCzZY2gmOIplIDno7am.wUXTAS. eLD9fqYv44G6eIQKfggT9JhE55gDuJLjI4pYVgz4IAE_lcc0DZXmEnpYUGDq1ryagb5HiK1Lgge4 4WKqrtFHn63_D2hbUeDx05iB9i3i6RuIfSa49uG03igsenrj1E3sd6cvr_5Vp7Tk5wXGnzFi4viH iQFodqzfOZIlkKOjkdik8FSwIhqrKzolzJEP1oECQkceC.wj5ryqDyBmmdDsM2TanfXq6oiSG54S DovGSUC_xpy1ck2Rk5nFnNIFnJ6Nm8IDbUzTwup58FTC_aCoSWIYq0ZJS3BSYReQNqCgcnc_DsEJ lJ2oYPXD45sgn7iZVhcJisrLQkbjQIMJWrReQuUJIzF_eYzT1lEMO4hMQ4ZQRkg42ZE06SzcQq.k 38hAPyp5o2K0xDgrY5xNzGWrcSxF56MH1InBIbtthDTbv4nt3xfSvJOXjl38WvSxq4Juv0be5jKB DsfG1h4YV1Pj6NybHduHOzt0ammFNsBG6L4n51k3hCGi8DyMWySV71M.od_jWTCI47sewBBtFWx9 LNBkn3CILxpNYJaQcOPRWLEojQ5iLoNkeV0mEF6POktkpY7hKXT4nHn4MIoe1WnKYS7jnG0CfMW1 m2KIDwDlkyfYHRkXP4c1yhOE5vKkgPfEQwjuV0UTEZouXgap7I4S1nklHU892f2NsPuCnUpdnO.m PcndgYCEBaOuVhcx3ULHjdLJuwhOMSJ5ih0CoRSO3fBSgMlUEHSTX2qkl7ROwq34nxMv1Hq6ldNO PtVJvQ0cnqjVdclWsedxRvXq1MEk6pZ5SR5VmRK5qVms4jPwZql.vgkug8AqgQOE8h3YnHNZFYc1 kD.E80MRT.OXhRgWcb_MgHaltEmjC7usxvHfwsSem6TkzIAXgQEUI9FdztImtmoX4pbMI1a9Nae6 3_JUw8tGuO64J3__IP6OJOuRANEkIpAyO_6WrvQCgda.KefEd40wnLwRoElLcOxP8.T8JnTW8vlm TpdzIidrQusH4VIWnK_yvLJ.FIZet1YxKvmguC7HSRI5eRS8OcME735oVGw4MK.bFgcHqE0F0D8t QonxZ1JckZXlq1n5I.e7wiBCA5hzLsj0S6hDCElj.b_VSbK.TJjAGPO2Jo6uq7wFJumrd_etjo44 f2T.WW7z38HM4_b8bl7oqzsxtqZIvDkyWCQ3ApZPFpkg6Ge9d6aA4bT1RR1T7n17qnrSg__znc6O 6J8zFElJwxekBzpQqJqvuZit5tju87oLi_6GAfoOQzmZqGEh_sRLjSbmiE.cPvTDuoPNVm7dYsz7 WxGp3MJ89706ieNHiHivUHUT8ogmpjtP8XTYKF_ENMCk7TI5EDc8o_tAjbDnuxSjihtJ4h5v8Fkx 9uSJcMyxcP..68R0K2RnO1lFijaoNz2fDqi99Brv4W2uHyqA.B6FctYYzmUZeu0bObu.fVdSJ08h GDOuUNtlHIEiqzsH92.by4nvZGFbTUzzixKRJFpTqAizNlmENl9g_PKG8RH7cHxc3Ru_MNveNSdM 5SoRrqr6B4KffDs9lbmdtDmQSG3klbQw9alMMkQYSB4Iz3Oscq17.sbemFGj3deNR23jK5vbz1px Cf1oh7N3YRC.JlKl4uuliurUE6eJWsN0wN1RatoNEVYC844M78FoPeBsjfPCOxduTfasiPJSaHG2 8MzLr1g6d3OKh80Yv66nicOx3uutJJg02ZASwPXbm3sqdBc_MpV4l9DMefKmc0E8VQiapcoX7ycW f9aX96.CMNinRdM0XSwgYfZxw2sM7UbiOsMdA6BTEJJV41E7_p.I2Dxlx8psxe.IIzIfzDjPeMN5 attgZuVdkiUAJZvSSqSFNsqZB1FiW4U86e.7xDvESqIa.7JLGk4nRz6WZbDGep1Y2vZAl0W5iBu5 m8QhUSudG_4KPLfey1PqmLdvBpFfovvg- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Thu, 18 Mar 2021 19:06:02 +0000 Received: by smtp403.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID a9e3c7ee89747a99ef9bc160db753f70; Thu, 18 Mar 2021 19:05:57 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Subject: Re: RPI4 clock speeds and serial port From: Mark Millard In-Reply-To: <20210318170053.GA26688@www.zefox.net> Date: Thu, 18 Mar 2021 12:05:54 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <9FFA0A51-C0B7-4121-95CA-B98669809007@yahoo.com> References: <20210318170053.GA26688@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Rspamd-Queue-Id: 4F1c1m0GS0z4c2P X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.64.206:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.64.206:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.206:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.206:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Porting FreeBSD to ARM processors List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 19:06:05 -0000 On 2021-Mar-18, at 10:00, bob prohaska 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: >>=20 >> .... >>=20 >> 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:=20 >> dev.cpufreq.0.%location:=20 >> dev.cpufreq.0.%driver: cpufreq >> dev.cpufreq.0.%desc:=20 >> dev.cpufreq.%parent:=20 >> dev.bcm2835_cpufreq.0.freq_settings: 1500/-1 600/-1 >> dev.bcm2835_cpufreq.0.%parent: cpu0 >> dev.bcm2835_cpufreq.0.%pnpinfo:=20 >> dev.bcm2835_cpufreq.0.%location:=20 >> dev.bcm2835_cpufreq.0.%driver: bcm2835_cpufreq >> dev.bcm2835_cpufreq.0.%desc: CPU Frequency Control >> dev.bcm2835_cpufreq.%parent:=20 >> dev.cpu.0.freq_levels: 1500/-1 600/-1 >> dev.cpu.0.freq: 600 >> dev.iichb.0.frequency: 100000 >>=20 >> /boot/msdos/config.txt contains >>=20 >> root@nemesis:~ # more /boot/msdos/config.txt >> [all] >> arm_64bit=3D1 >> dtparam=3Daudio=3Don,i2c_arm=3Don,spi=3Don >> dtoverlay=3Dmmc >> dtoverlay=3Ddisable-bt >> device_tree_address=3D0x4000 >> kernel=3Du-boot.bin >>=20 >> [pi4] >> #hdmi_safe=3D1 >> armstub=3Darmstub8-gic.bin >>=20 >> There is no /boot/msdos/cmdline.txt file. >>=20 >> Can one change the cpu speed without disturbing the serial console >> by using something like=20 >>=20 >> arm_freq=3D1750 >>=20 >> in config.txt, provided adequate cooling provisions are made? >>=20 >> I'd rather not complicate use of the serial console at this point. >=20 I've never had the CPU clock rate or memory clock rate mess with the serial console behavior. 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=3Dcc matches the source tree. Not bootstrapping a = cross-compiler. make[1]: "/usr/fbsd/mm-src/Makefile.inc1" line 344: SYSTEM_LINKER: = Determined that LD=3Dld 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=3D1 enable_uart=3D1 uart_2ndstage=3D1 dtdebug=3D1 disable_commandline_tags=3D1 disable_overscan=3D1 device_tree_address=3D0x4000 dtoverlay=3Ddisable-bt dtoverlay=3Dmmc armstub=3Darmstub8-gic.bin kernel=3Du-boot.bin gpu_mem_1024=3D32 # For speeding things up: over_voltage=3D6 arm_freq=3D2000 arm_freq_min=3D2000 sdram_freq_min=3D3200 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=3D2000 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=3D2000 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=3D6 and arm_freq=3D2000 . # NOTE: without an appropriate over_voltage a # dev.cpu.0.freq=3D2000 will crash the RPi4B on the # spot. dev.cpu.0.freq=3D2000 (So I do not use powerd .) This goes along with the config.txt having "arm_freq_min=3D2000". 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 CFLAGS # usage, such as ?=3D usage. CFLAGS.clang+=3D -mcpu=3Dcortex-a72 CXXFLAGS.clang+=3D -mcpu=3Dcortex-a72 CPPFLAGS.clang+=3D -mcpu=3Dcortex-a72 ACFLAGS.arm64cpuid.S+=3D -mcpu=3Dcortex-a72+crypto ACFLAGS.aesv8-armx.S+=3D -mcpu=3Dcortex-a72+crypto ACFLAGS.ghashv8-armx.S+=3D -mcpu=3Dcortex-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=20 # # GENERIC -- Custom configuration for the arm64/aarch64 # include "GENERIC" ident GENERIC-NODBG makeoptions DEBUG=3D-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=3D0 # Enable verbose sysinit = messages #options BOOTVERBOSE=3D1 #options BOOTHOWTO=3DRB_VERBOSE #options KTR #options KTR_MASK=3DKTR_TRAP ##options KTR_CPUMASK=3D0xF #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:=20 dev.cpufreq.0.%location:=20 dev.cpufreq.0.%driver: cpufreq dev.cpufreq.0.%desc:=20 dev.cpufreq.%parent:=20 dev.bcm2835_cpufreq.0.freq_settings: 2000/-1 600/-1 dev.bcm2835_cpufreq.0.%parent: cpu0 dev.bcm2835_cpufreq.0.%pnpinfo:=20 dev.bcm2835_cpufreq.0.%location:=20 dev.bcm2835_cpufreq.0.%driver: bcm2835_cpufreq dev.bcm2835_cpufreq.0.%desc: CPU Frequency Control dev.bcm2835_cpufreq.%parent:=20 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=20 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 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)