rpi2: cpufreq(4) support lost ?

[Emmanuel Vadot]

On Sun, 12 Nov 2017 15:23:39 -0800
Mark Millard <markmi at dsl-only.net> wrote:

> [This is a Linux *.dt* source issue, not specific to
> amrmv6 vs. armv7: FreeBSD has switched to Linux *.dt*
> source files, 4.13 most recently if I remember right.]

 This we do not use the DTS from Linux for RPI1/2 I doubt that.

> On 2017-Nov-12, at 2:30 PM, Claude Buisson <clbuisson at orange.fr> wrote:
> 
> > On 11/12/2017 20:03, Herbert J. Skuhra wrote:
> >> On Sat, 11 Nov 2017 12:47:47 +0100,
> >> Claude Buisson <clbuisson at orange.fr> wrote:
> >>> 
> >>> [I am not subscribed to this list - please answser to me]
> >>> 
> >>> I recently upgraded a RPI2 Model B, from head r323691 armv6 to head
> >>> r325110 + patch D12907 (lib/libc/gen/tls.c) armv7.
> >>> 
> >>> In the dmesg, the lines:
> >>> 
> >>> bcm2835_cpufreq0: <CPU Frequency Control> on cpu0
> >>> bcm2835_cpufreq0: ARM 600MHz, Core 250MHz, SDRAM 400MHz, Turbo OFF
> >>> 
> >>> disappeared, and the log shows:
> >>> 
> >>> /etc/rc.d/powerd start
> >>> powerd: no cpufreq(4) support -- aborting: No such file or directory
> >>> 
> >>> As what seems to be a consequence, the system became much slower.
> >>> 
> >>> Everything came back to normal when I copied the old rpi2.dtb to the
> >>> new /boot/msdos/
> >> The old rpi2.dtb is from an armv6 build, right?
> > 
> > Yes: from head r323691 armv6 as documented supra
> > 
> >>> I tried the rpi2.dtb from the lastest snapshot
> >>>   FreeBSD-12.0-CURRENT-arm-armv7-RPI2-20171109-r325595.img
> >>> and cpufreq(4) disappeared again.
> >>> 
> >>> What I am missing ?
> >> The problem obviously exists since the switch to armv7.
> >> I use rpi2.dtb from my other RPI2 (stable/11).
> 
> Also there was the note:
> 
> > On 12.11.17, Herbert J. Skuhra wrote:
> > 
> >>> I tried the rpi2.dtb from the lastest snapshot
> >>>  FreeBSD-12.0-CURRENT-arm-armv7-RPI2-20171109-r325595.img
> >>> and cpufreq(4) disappeared again.
> >>> 
> >>> What I am missing ?
> >> 
> >> The problem obviously exists since the switch to armv7.
> > 
> > It is also there with recent armv6 builds. I run into the problem with 
> > r325464 (armv6). I always update the dtb when installing a new world/kernel.
> > 
> > So, something musst be wrong with the dtb file. I'm using now a file from 
> > r323309, where cpufreq is available again.
> 
> FreeBSD's 12.0 has switched to using the Linux
> *.dt* source files, even if they are not functionally
> equivalent to what FreeBSD had before. (I do not
> track 11.x most of the time and so have not checked
> there.)

 Not true, it depends on boards/SoC.
 Even FreeBSD 11 uses Linux DTS for Allwinner for example.

> The way to get functionality back is to submit *.dt*
> changes to Linux that are accepted and later FreeBSD
> will pick up the changes from the Linux update that
> includes the changes, such as from the future 4.14
> update. At least that is my understanding.

 The way to get functionality back is to find the real problem.

> This went so far as dropping support for things that
> did not have Linux support at the time, such as for
> the BPI-M3: the *.dts involved was removed from the
> Makefile. The *.dt* files are still there but a
> *.dts needs a patch. USB support for A83T (which the
> BPI-M3 is an example of) was eliminated from some
> source code in its conversion as well --and needs a
> patch to be enabled again.
>
> (Part of the issue for the BPI-M3 is what FreeBSD
> committers have one vs. not having one to test.)
> 
> Folks that are willing can locally restore BPI-M3
> support. The sysutils/u-boot-sinovoip-bpi-m3 port
> was not removed but has not been modernized to be
> based on sysutils/u-boot-master --but that is from
> lack of Linux support as of 4.13 as far as I can
> tell. (Once 4.14 is grabbed
> sysutils/u-boot-sinovoip-bpi-m3 might update
> at some point.)
> 
> One of the FreeBSD folks has set up for when 4.14
> adds BPI-M3 support. But I do not know about the
> detailed functionality comparison since the *.dt*
> source files might issues similar to the rpi2.
> 
> ===
> Mark Millard
> markmi at dsl-only.net

 All this is mostly wrong and doesn't have anything to do with the
cpufreq problem on RPI2.
 Please stay focus.

> 
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"


-- 
Emmanuel Vadot <manu at bidouilliste.com> <manu at freebsd.org>