Date: Sat, 26 Sep 2020 19:01:06 -0700 From: Mark Millard <marklmi@yahoo.com> To: tech-lists <tech-lists@zyxst.net> Cc: freebsd-arm <freebsd-arm@freebsd.org>, Robert Clausecker <fuz@fuz.su> Subject: Re: RPi4B u-boot based booting and hw.cpufreq.voltage_core and dev.cpu.0.freq use: able to use 2000 MHz Message-ID: <19D27F91-F038-4393-90BF-7A439F8BF4B1@yahoo.com> In-Reply-To: <64B39936-7689-4240-A5F9-4DF5EAE4DE42@yahoo.com> References: <0578EC2B-D21C-46AA-AD3E-CD13985B18FA.ref@yahoo.com> <0578EC2B-D21C-46AA-AD3E-CD13985B18FA@yahoo.com> <20200926133934.GD54660@bastion.zyxst.net> <64B39936-7689-4240-A5F9-4DF5EAE4DE42@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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: >=20 >> On Sat, Sep 26, 2020 at 12:37:45AM -0700, Mark Millard via = freebsd-arm wrote: >>> 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). >>>=20 >>> In this context . . . >>>=20 >>> I added over_voltage=3D6 and arm_freq=3D2000 to config.txt and it >>> ends up looking like: >>>=20 >>> arm_control=3D0x200 >>> arm_64bit=3D1 >>> dtoverlay=3Ddisable-bt >>> dtoverlay=3Dmmc >>> device_tree_address=3D0x4000 >>> kernel=3Du-boot.bin >>> armstub=3Darmstub8-gic.bin >>> over_voltage=3D6 >>> arm_freq=3D2000 >>>=20 >>>=20 >>> Booting based on that resulted in: >>>=20 >>> dev.bcm2835_cpufreq.0.freq_settings: 2000/-1 600/-1 >>> dev.cpu.0.freq_levels: 2000/-1 600/-1 >>> dev.cpu.0.freq: 600 >>>=20 >>> And: >>>=20 >>> # sysctl dev.cpu.0.freq=3D2000 >>> dev.cpu.0.freq: 600 -> 2000 >>>=20 >>> worked. (Without the over_voltage it reports 600 and then >>> hangs.) Having /etc/sysctl.conf list dev.cpu.0.freq=3D2000 >>> works. >>=20 >> Exellent! On the basis of your post I went ahead and removed from = config.txt >> three lines, then added two and rebooted. >>=20 >> It's now this: >>=20 >> arm_control=3D0x200 >> arm_64bit=3D1 >> dtoverlay=3Ddisable-bt >> dtoverlay=3Dmmc >> device_tree_address=3D0x4000 >> kernel=3Du-boot.bin >> armstub=3Darmstub8-gic.bin >> over_voltage=3D6 >> arm_freq=3D2000 >>=20 >> before, when it didn't work, it had this: >> [same as above], apart from >> gpu_mem=3D16 >> over_voltage=3D6 >> arm_freq=3D2100 >>=20 >> In creating the freebsd instance I followed these instructions for = 8GB >> = https://lists.freebsd.org/pipermail/freebsd-arm/2020-August/022162.html >> and applied D26344. /etc/rc.conf has powerd loaded >>=20 >> I was particularly interested in getting this clocked to a reasonable = speed as >> it's used to build packages with poudriere based on arm7 and aarch64 = for >> -current. >=20 > The cortex-A72 is largely memory subsystem limited on the > RPi4B compared to, say, the MACCHIATObin Double Shot > running at the same clock rate. >=20 > So I've recently experimented with changing the > sdram_freq_min from the default or 400 to 3200 > (to match sdram_freq): >=20 > # more /microsd_efi/config.txt > arm_control=3D0x200 > arm_64bit=3D1 > dtoverlay=3Ddisable-bt > dtoverlay=3Dmmc > device_tree_address=3D0x4000 > kernel=3Du-boot.bin > armstub=3Darmstub8-gic.bin > over_voltage=3D6 > arm_freq=3D2000 > sdram_freq_min=3D3200 >=20 > A benchmark I use suggests I'll see the fastest RPi4B > buildworld buildkernel times that I've seen yet when I=20 > get around to trying that. ( My benchmarking and testing > is based on powerd or the like not being in use but the > kernel or rpi-firmware could be doing its own thing > given the above and sysctl.conf having > dev.cpu.0.freq=3D2000 .) Preiminary benchmarking indicates that rpi4-uefi-devel's uefi/ACPI context effectively ends up with sdram_freq_min=3D3200 ignored (making no difference). (In my context, it is the same FreeBSD root file system for both types of boots, so only boot-specific code varies.) Thus, it looks like the u-boot context can be better tailored for cutting the buildworld buildkernel time required and so it looks like that is the environment that I will be timing a from-scratch build in. The ACPI context does not have a sysctl interface to the values that the u-boot one has. So u-boot based is more direct for validating what is in use. > I have heatsinks and a fan involved, as well as a > (apparently good) 5.1v 3.5A power supply. My experiments > presume such a context. >=20 > (I've sent out a separate list message about hw.cpufreq.sdram_freq > having a value-display problem and the 3 hw.cpufreq.voltage_sdram_* > values looking to be lower than expected. I've not seen evidence > of problems in operation so far.) >=20 > I'll note that: >=20 > = https://www.raspberrypi.org/documentation/configuration/config-txt/boot.md= >=20 > reports: >=20 > QUOTE > arm_control >=20 > DEPRECATED - use arm_64bit to enable 64-bit kernels. >=20 > Sets board-specific control bits. > END QUOTE >=20 > So I'm likely to experiment with removing that line > from config.txt . >=20 >=20 >> seems very stable so far: >>=20 >> 2:36p.m. up 45 mins, 1 user, load averages: 6.51, 3.57, 2.92 >> Sat 26 Sep 2020 14:36:14 BST >> dev.cpu.0.temperature: 65.0C >> dev.cpu.0.freq_levels: 2000/-1 600/-1 >> dev.cpu.0.freq: 2000 >>=20 >> rpi4 is in a FLIRC case for cooling, no fan. 24 degC/44%rh ambient. >>=20 >=20 >=20 =3D=3D=3D 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?19D27F91-F038-4393-90BF-7A439F8BF4B1>