Date: Sat, 27 Feb 2021 13:52:57 -0800 From: Mark Millard <marklmi@yahoo.com> To: Mike Karels <mike@karels.net> Cc: freebsd-arm@freebsd.org, manu@freebsd.org Subject: Re: cpufreq driver stopped working on RPI4 Message-ID: <7D6CCA5B-F24D-48CF-893C-18AD73417E4E@yahoo.com> In-Reply-To: <202102271742.11RHg4r2012120@mail.karels.net> References: <202102271742.11RHg4r2012120@mail.karels.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 2021-Feb-27, at 09:42, Mike Karels <mike at karels.net> wrote: >=20 > Following up on my previous post (below): I tried the ALPHA1 kernel on > a BETA3 system on the RPI4, and it fails to attach the cpufreq driver > as well. So it appears that the problem is in the dtb, etc, not the > kernel. >=20 > It would be nice to get this fixed before the 13.0 release. Without > the cpufreq driver, the CPU is stuck at a low clock rate. In config.txt for an RPi4B I use (as an example, you could use other figures): over_voltage=3D6 arm_freq=3D2000 arm_freq_min=3D2000 sdram_freq_min=3D3200 and in /etc/sysctl.conf I have: # 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 Overall this gives a constant faster frequency for the CPU (and the sdram). (I have a good power supply context for this.) You may or may not be able to tolerate the constant status for frequencies. But there is this alternative to cpufreq use. > Mike >=20 >> To: freebsd-arm@freebsd.org >> From: Mike Karels <mike@karels.net> >> Reply-to: mike@karels.net >> Subject: cpufreq driver stopped working on RPI4 >> Date: Sun, 21 Feb 2021 14:43:27 -0600 >=20 >> I upgraded an older (original) RPI4, 4 GB, to 13.0-BETA3, and merged = my >> previous rc.conf including powerd. Powerd fails to start now, saying >> that there is no cpufreq(4) support. Sure enough, dmesg has the = following >> relevant lines: >=20 >> bcm2835_cpufreq0: <CPU Frequency Control> on cpu0 >> bcm2835_cpufreq0: Unable to find firmware device >> device_attach: bcm2835_cpufreq0 attach returned 6 >> armv8crypto0: CPU lacks AES instructionsbcm2835_cpufreq0: <CPU = Frequency Control> on cpu0 >> bcm2835_cpufreq0: Unable to find firmware device >> device_attach: bcm2835_cpufreq0 attach returned 6 >=20 >> (Yes, armv8crypto is missing a newline.) >=20 >> I checked the most recent system I had on the shelf, which was = 13.0-ALPHA1. >> It has this: >=20 >> bcm2835_firmware0: <BCM2835 Firmware> on simplebus0 >> ofw_clkbus1: <OFW clocks bus> on bcm2835_firmware0 >> gpio0: <Raspberry Pi Firmware GPIO controller> on = bcm2835_firmware0 >> bcm2835_cpufreq0: <CPU Frequency Control> on cpu0 >> bcm2835_cpufreq0: ARM 600MHz, Core 200MHz, SDRAM 400MHz, Turbo OFF >=20 >> Does anyone know what changed to cause this? Was it the FDT update? >=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?7D6CCA5B-F24D-48CF-893C-18AD73417E4E>