Date: Mon, 13 Nov 2017 10:54:30 +0100 From: Emmanuel Vadot <manu@bidouilliste.com> To: Mark Millard <markmi@dsl-only.net> Cc: Claude Buisson <clbuisson@orange.fr>, "Herbert J. Skuhra" <herbert@mailbox.org>, Andreas Schwarz <freebsd.asc@strcmp.org>, Freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: rpi2: cpufreq(4) support lost ? Message-ID: <20171113105430.720cdb0f887138b89c8e271e@bidouilliste.com> In-Reply-To: <BC4CC33D-CE5A-4450-93C3-A16F5B6B9F51@dsl-only.net> References: <2bceba56-f6a8-5120-fac5-0d3387a8278d@orange.fr> <87a7zrgvzv.wl-herbert@mailbox.org> <2cedd4c6-1db0-04e7-b131-b0f0fc2f0500@orange.fr> <BC4CC33D-CE5A-4450-93C3-A16F5B6B9F51@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 12 Nov 2017 15:23:39 -0800 Mark Millard <markmi@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@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" -- 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?20171113105430.720cdb0f887138b89c8e271e>