Date: Sun, 28 Feb 2021 20:37:46 +0100 From: Emmanuel Vadot <manu@bidouilliste.com> To: mike@karels.net Cc: Mark Millard <marklmi@yahoo.com>, freebsd-arm@freebsd.org, manu@freebsd.org Subject: Re: cpufreq driver stopped working on RPI4 Message-ID: <20210228203746.0d681dc6fa27038c72ef28c1@bidouilliste.com> In-Reply-To: <202102272228.11RMSqgo012921@mail.karels.net> References: <7D6CCA5B-F24D-48CF-893C-18AD73417E4E@yahoo.com> <202102272228.11RMSqgo012921@mail.karels.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Mike, On Sat, 27 Feb 2021 16:28:52 -0600 Mike Karels <mike@karels.net> wrote: > Thanks, Mark. Meanwhile, I just tested BETA4; much to my surprise, > the cpufreq driver configured again. I didn't notice a relevant change, > but it is working... > > Mike Here is the commit you were looking for : https://cgit.freebsd.org/src/commit/?id=1cf282363101f5d99b1dadfb0d3250bbe6f482a5 Note that there is still a problem with xhci, see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252971#c25 for how to fix that for now. I'll update the rpi-firmware ports next week. Cheers, > Mark wrote: > > > On 2021-Feb-27, at 09:42, Mike Karels <mike at karels.net> wrote: > > > > > > 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. > > > > > > 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=6 > > arm_freq=2000 > > arm_freq_min=2000 > > sdram_freq_min=3200 > > > 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=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 > > > 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 > > > > > >> 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 > > > > > >> 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: > > > > > >> 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 > > > > > >> (Yes, armv8crypto is missing a newline.) > > > > > >> I checked the most recent system I had on the shelf, which was 13.0-ALPHA1. > > >> It has this: > > > > > >> 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 > > > > > >> Does anyone know what changed to cause this? Was it the FDT update? > > > > > > === > > Mark Millard > > marklmi at yahoo.com > > ( dsl-only.net went > > away in early 2018-Mar) -- Emmanuel Vadot <manu@bidouilliste.com> <manu@FreeBSD.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20210228203746.0d681dc6fa27038c72ef28c1>