Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 28 Feb 2021 13:51:09 -0800
From:      Mark Millard <marklmi@yahoo.com>
To:        Mike Karels <mike@karels.net>
Cc:        freebsd-arm <freebsd-arm@freebsd.org>, Emmanuel Vadot <manu@freebsd.org>
Subject:   Re: cpufreq driver stopped working on RPI4
Message-ID:  <97C171BF-1CB3-4FCF-B7D4-EF3E75CC8AA3@yahoo.com>
In-Reply-To: <20210228203746.0d681dc6fa27038c72ef28c1@bidouilliste.com>
References:  <7D6CCA5B-F24D-48CF-893C-18AD73417E4E@yahoo.com> <202102272228.11RMSqgo012921@mail.karels.net> <20210228203746.0d681dc6fa27038c72ef28c1@bidouilliste.com>

next in thread | previous in thread | raw e-mail | index | archive | help


On 2021-Feb-28, at 11:37, Emmanuel Vadot <manu at bidouilliste.com> =
wrote:


> Hi Mike,
>=20
> On Sat, 27 Feb 2021 16:28:52 -0600
> Mike Karels <mike@karels.net> wrote:
>=20
>> 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...
>>=20
>> 		Mike
>=20
> Here is the commit you were looking for :=20
> =
https://cgit.freebsd.org/src/commit/?id=3D1cf282363101f5d99b1dadfb0d3250bb=
e6f482a5
>=20
> Note that there is still a problem with xhci, see
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D252971#c25 for how =
to
> fix that for now. I'll update the rpi-firmware ports next week.

I'll note that for the xhci issue:

=
https://github.com/Hexxeh/rpi-firmware/commit/ca28024e2a78d6b1a05db5bbb77f=
6543fe569957
=
https://github.com/raspberrypi/firmware/commit/787227279ea72eb4bbf9ab077bd=
17336fe2158d8

was the release of the update to master for the 2 copies
but another firmware bugfix for a problem that messed up use
of DMA channel 6 got a release the next day (2021-Feb-25):

=
https://github.com/Hexxeh/rpi-firmware/commit/f73375d989151f7568e634140d3c=
4a13044921b2
=
https://github.com/raspberrypi/firmware/commit/5985247fb75681985547641d661=
96c77499f26b9

There is no tagged version in https://github.com/raspberrypi/firmware/
yet (as of when I just looked).


https://github.com/pftf/RPi4 has picked up the changes in v1.23
for with its EDK2 builds and has updated EDK2 again in v1.24 .

> Cheers,
>=20
>> Mark wrote:
>>>> 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.
>>=20
>>> In config.txt for an RPi4B I use (as an example, you
>>> could use other figures):
>>=20
>>> over_voltage=3D6
>>> arm_freq=3D2000
>>> arm_freq_min=3D2000
>>> sdram_freq_min=3D3200
>>=20
>>> and in /etc/sysctl.conf I have:
>>=20
>>> # 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
>>=20
>>> Overall this gives a constant faster frequency
>>> for the CPU (and the sdram). (I have a good power
>>> supply context for this.)
>>=20
>>> You may or may not be able to tolerate the constant
>>> status for frequencies. But there is this alternative
>>> to cpufreq use.
>>=20
>>=20
>>>> 		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?


=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?97C171BF-1CB3-4FCF-B7D4-EF3E75CC8AA3>