I can confirm that recent changes in FreeBSD have led to this issue. In fact, everything was functioning correctly when I was using FreeBSD 14 Current from two weeks ago. This is unrelated to the updates in the Raspberry Pi firmware, as I manually replaced the latest firmware and htop was displaying temperature and frequency accurately. However, everything went awry after installing alpha1 today. I am using a Raspberry Pi 4B 8GB version 1.5. Below is the compilation log of my kernel and world. At least the system compiled from the source code on that day was working fine, so it should be the recent change that has affected the outcome. ---------------------------------- >>> World build completed on Fri Aug 4 19:04:06 CST 2023 >>> World built in 62132 seconds, ncpu: 4, make -j4 --------------------------------- -------------------------------------------------------------- >>> Kernel build for GENERIC completed on Fri Aug 4 20:00:09 CST 2023 -------------------------------------------------------------- >>> Kernel(s) GENERIC built in 3105 seconds, ncpu: 4, make -j4 -------------------------------------------------------------- ------------- root@ykla:~ # service powerd restart powerd not running? Starting powerd. powerd: no cpufreq(4) support -- aborting: No such file or directory /etc/rc.d/powerd: WARNING: failed to start powerd root@ykla:~ #
I only see Intel, AMD and general ACPI drivers listed in cpufreq(4), so to me that error message makes some sense. but you're saying this is a regression. We've had some dts changes recently: https://freshbsd.org/freebsd/src/branch/main?q=dts
Could you be explicit about each of (the combination): the RPi* firmware version, the u-boot version, and the FreeBSD version used in the boot, for each stage listed: A) from two weeks ago B) manually replaced the latest firmware C) installing alpha1 today I'm having trouble following the evidence here. For reference . . . The most recent change below sys/arm/broadcom is: author Tetsuya Uemura <t_uemura@macome.co.jp> 2023-05-28 12:56:21 +0000 committer Mitchell Horne <mhorne@FreeBSD.org> 2023-05-29 18:47:12 +0000 commit 9d35469e9a6892b3845f66d3513f5c528fe68a77 (patch) . . . bcm2835_gpio: Handle BCM2711 pin configuration . . . And below sys/arm64/broadcom is: author Justin Hibbits <jhibbits@FreeBSD.org> 2022-08-19 16:03:42 +0000 committer Justin Hibbits <jhibbits@FreeBSD.org> 2023-01-31 21:26:34 +0000 commit b7459fb0adaf05268b5da9a8772a4fb0250bba65 (patch) . . . Mechanically convert genet(4) to IfAPI . . . So if it is the kernel, it is from changes outside the broadcom areas and would likely not be specific to RPi*'s.
(In reply to Mina Galić from comment #1) FreeBSD does not use the dts files from that area for for RPi*'s. It uses materials from the sysutils/rpi-firmware port, that in turn gets it from the RPi* github materials. FreeBSD has: sys/arm/broadcom/bcm2835/bcm2835_cpufreq.c specifically for the RPi*'s.
(In reply to Mark Millard from comment #3) that should be documented then, for naïve people like me
My 8 GiByte RPi4B v1.5 boot logs show: Aug 11 13:37:06 generic kernel: bcm2835_cpufreq0: <CPU Frequency Control> on cpu0 Aug 11 13:37:06 generic kernel: bcm2835_cpufreq0: Unable to find firmware device Aug 11 13:37:06 generic kernel: device_attach: bcm2835_cpufreq0 attach returned 6 That is this code that has not changed: static int bcm2835_cpufreq_attach(device_t dev) { struct bcm2835_cpufreq_softc *sc; struct sysctl_oid *oid; /* set self dev */ sc = device_get_softc(dev); sc->dev = dev; sc->firmware = devclass_get_device( devclass_find("bcm2835_firmware"), 0); if (sc->firmware == NULL) { device_printf(dev, "Unable to find firmware device\n"); return (ENXIO); } . . . This does look to me like devclass_find is internal FreeBSD infrastructure about its own internals, not RPi* specific. If so, the problem seems likely more general than RPi*'s.
(In reply to Mark Millard from comment #5) The problem is clearly RPI related, I don't see the firmware device being probed. Can someone share a verbose boot log and the running dtb (sysctl -b hw.fdt.dtb | dtc -I dtb -O dts), thanks.
(In reply to Emmanuel Vadot from comment #6) From a message list exchange: . . . Two other failures: bcm2835_cpufreq0: <CPU Frequency Control> on cpu0 bcm2835_cpufreq0: Unable to find firmware device device_attach: bcm2835_cpufreq0 attach returned 6 . . . I'll append the full dmesg.boot. Mike ---<<BOOT>>--- . . . ofwbus0: <Open Firmware Device Tree> simplebus0: <Flattened device tree simple bus> on ofwbus0 ofw_firmware0: <OFW Firmware Group> on simplebus0 The above line does not match the historical identification: simplebus3: <Flattened device tree simple bus> on ofwbus0 simple_mfd0: <Simple MFD (Multi-Functions Device)> mem 0x7d5d2000-0x7d5d2eff on simplebus0 bcm2835_firmware0: <BCM2835 Firmware> on simplebus0 ofw_clkbus1: <OFW clocks bus> on bcm2835_firmware0 The modern result outputs no line like: bcm2835_firmware0: <BCM2835 Firmware> on simplebus0 The older result did not output a line like: ofw_firmware0: <OFW Firmware Group> on simplebus0 In other words the RPi* support was broken by the following change effectively disabling having bcm2835_firmware to be found by bcm2835_cpufreq: author Emmanuel Vadot <manu@FreeBSD.org> 2022-12-06 10:57:37 +0000 committer Emmanuel Vadot <manu@FreeBSD.org> 2023-08-08 13:13:31 +0000 commit fdfd3a90b6ceba838a40c3c51472883e7de8a440 (patch) . . . ofw: Add a ofw_firmware driver Some SoCs have an external firmware doing power management, clock and other stuffs. (Xilinx, ARM Juno etc ...) The way it is represent in the DTB is usually having a 'firmware' node under the root node and have some nodes under it with the correct compatible strings. The firmware node itself doesn't have any compatible strings. This driver is simple subclassed from simplebus and attaches at BUS_PASS_BUS + BUS_PASS_ORDER_MIDDLE so early drivers (like clock drivers) can still have a change to attach early. Reviewed by: andrew Sponsored by: Beckhoff Automation GmbH & Co. KG Differential Revision: https://reviews.freebsd.org/D37612 ofw_clkbus0: <OFW clocks bus> on ofw_firmware0 ofw_clkbus1: <OFW clocks bus> on ofwbus0 clk_fixed0: <Fixed clock> on ofw_clkbus1 clk_fixed1: <Fixed clock> on ofw_clkbus1 . . .
Can someone test this patch please : https://people.freebsd.org/~manu/0001-ofw_firmware-Only-match-if-there-is-no-compatible.patch Thanks.
(In reply to Mark Millard from comment #7) I'll note that I've not checked for analogous examples of ofw_firmware displacing other forms of pre-existing ???_firmware instances outside the bcm2835_cpufreq code, including not checked outside the RPi* specific code at all. If we are lucky, the RPi* code will be the only area with the oddity.
(In reply to Emmanuel Vadot from comment #8) Confirmed for 8 GiByte RPi4B rev 1.5 example (showing new): simplebus3: <Flattened device tree simple bus> on ofwbus0 simple_mfd0: <Simple MFD (Multi-Functions Device)> mem 0x7d5d2000-0x7d5d2eff on simplebus0 bcm2835_firmware0: <BCM2835 Firmware> on simplebus0 ofw_clkbus1: <OFW clocks bus> on bcm2835_firmware0 . . . Also, there was no: gpioled0: <PWR> failed to map pin
(In reply to Mark Millard from comment #10) Also: # powerd is silent instead of complaining. (I do not normally use it, thus the explicit command.)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=69f8cc60aa1e3140f41a75c859333a3d56c947fb commit 69f8cc60aa1e3140f41a75c859333a3d56c947fb Author: Emmanuel Vadot <manu@FreeBSD.org> AuthorDate: 2023-08-13 06:28:13 +0000 Commit: Emmanuel Vadot <manu@FreeBSD.org> CommitDate: 2023-08-13 09:19:44 +0000 ofw_firmware: Only match if there is no compatible If there is a compatible string it likely means that the firmware needs a dedicated driver (like on RPI*). PR: 273087 Tested-by: Mark Millard <marklmi26-fbsd@yahoo.com> Sponsored by: Beckhoff Automation GmbH & Co. KG Fixes: fdfd3a90b6ce ("ofw: Add a ofw_firmware driver") sys/dev/ofw/ofw_firmware.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
(In reply to commit-hook from comment #12) Thank you.