Date: Sun, 12 Nov 2017 15:23:39 -0800 From: Mark Millard <markmi@dsl-only.net> To: Claude Buisson <clbuisson@orange.fr>, "Herbert J. Skuhra" <herbert@mailbox.org>, Andreas Schwarz <freebsd.asc@strcmp.org> Cc: Freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: rpi2: cpufreq(4) support lost ? Message-ID: <BC4CC33D-CE5A-4450-93C3-A16F5B6B9F51@dsl-only.net> In-Reply-To: <2cedd4c6-1db0-04e7-b131-b0f0fc2f0500@orange.fr> References: <2bceba56-f6a8-5120-fac5-0d3387a8278d@orange.fr> <87a7zrgvzv.wl-herbert@mailbox.org> <2cedd4c6-1db0-04e7-b131-b0f0fc2f0500@orange.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
[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.] 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: >>>=20 >>> [I am not subscribed to this list - please answser to me] >>>=20 >>> I recently upgraded a RPI2 Model B, from head r323691 armv6 to head >>> r325110 + patch D12907 (lib/libc/gen/tls.c) armv7. >>>=20 >>> In the dmesg, the lines: >>>=20 >>> bcm2835_cpufreq0: <CPU Frequency Control> on cpu0 >>> bcm2835_cpufreq0: ARM 600MHz, Core 250MHz, SDRAM 400MHz, Turbo OFF >>>=20 >>> disappeared, and the log shows: >>>=20 >>> /etc/rc.d/powerd start >>> powerd: no cpufreq(4) support -- aborting: No such file or directory >>>=20 >>> As what seems to be a consequence, the system became much slower. >>>=20 >>> 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? >=20 > Yes: from head r323691 armv6 as documented supra >=20 >>> I tried the rpi2.dtb from the lastest snapshot >>> FreeBSD-12.0-CURRENT-arm-armv7-RPI2-20171109-r325595.img >>> and cpufreq(4) disappeared again. >>>=20 >>> 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: >=20 >>> I tried the rpi2.dtb from the lastest snapshot >>> FreeBSD-12.0-CURRENT-arm-armv7-RPI2-20171109-r325595.img >>> and cpufreq(4) disappeared again. >>>=20 >>> What I am missing ? >>=20 >> The problem obviously exists since the switch to armv7. >=20 > It is also there with recent armv6 builds. I run into the problem with=20= > r325464 (armv6). I always update the dtb when installing a new = world/kernel. >=20 > So, something musst be wrong with the dtb file. I'm using now a file = from=20 > 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.) 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. 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. =3D=3D=3D Mark Millard markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BC4CC33D-CE5A-4450-93C3-A16F5B6B9F51>