Date: Tue, 16 May 2023 10:11:58 -0700 From: Mark Millard <marklmi@yahoo.com> To: Doug Rabson <dfr@rabson.org> Cc: freebsd-arm@freebsd.org Subject: Re: Raspberry Pi POE+ hat overlay Message-ID: <CDF641F7-351E-418B-98F0-329087BF969E@yahoo.com> In-Reply-To: <CACA0VUhdi2%2BGXpjmco0%2B5801t0Vso50Bat1UxJ2a4RJChxkU9w@mail.gmail.com> References: <CACA0VUh9-7o55pXcyn=Ep9mPexAkgjKLEKUh6HqMovTxe2_R0Q@mail.gmail.com> <E615D3BE-C12D-4960-BB01-AD2D40CA90A5@yahoo.com> <CACA0VUjCyhPCxBTn6h_HMOGjdFnivi5bnq4jgcg4i0bKY%2BF0PA@mail.gmail.com> <D6869D48-5661-4054-90D8-2B394CA5D25E@yahoo.com> <77CD0716-3BC8-47EB-8743-F2BD9CA43D31@yahoo.com> <432A1A16-9FE5-4339-AB38-8F3E03A5D4EF@yahoo.com> <CACA0VUhDwx%2BRmHU_OSFfGhjfbbbiy6HpurGL7WjM_i%2B0U7UpBQ@mail.gmail.com> <CACA0VUhdi2%2BGXpjmco0%2B5801t0Vso50Bat1UxJ2a4RJChxkU9w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 16, 2023, at 09:19, Doug Rabson <dfr@rabson.org> wrote: >> On Sat, 13 May 2023 at 13:45, Doug Rabson <dfr@rabson.org> wrote: >> I was able to build an updated rpi-firmware port based on 1.20210805 = and this boots successfully on pi400 as well as rpi4. With this, I can = load the rpi-poe-plus overlay and I just need to try and reverse = engineer the undocumented mailbox API by reading the Linux code. >>=20 > I have a first approximation of a fan driver which works with the = 1.20210805 firmware (actually, I substituted rpi-poe-plus.dtbo from = 1.20210831 which just changes the fan levels for the POE+). I'm testing = with an rpi4B rev 1.5 with 'make -j4 buildworld' and the fan is keeping = the cpu temperature below 65 degrees which is nice, especially since I = set arm_boost=3D1 in config.txt which boosts the cpu frequency up to = 1800 for this board. >=20 > Does anyone have a pointer to the problem with firmware later than = 20210805? Would it make any kind of sense to try to get the fix into = releng/13.2 as an errata? I doubt that FreeBSD would do a 13.2-RELEASE errata for a bug that is RPi* specific. But that should not block checking my assumptions. It might be more likely as an extra errata if another one was deemed essential so that an update would be happening anyway. (But I do not know if they do such things for fixes with narrower applicability.) Relevant from stable/13 are: = https://cgit.freebsd.org/src/commit/?h=3Dstable/13&id=3D5b6edfc577fbb4e970= 3c112713c7fb472e144346 ( https://bugs.freebsd.org/268835 ) and = https://cgit.freebsd.org/src/commit/?h=3Dstable/13&id=3Daa399ad3e554223b8b= f741c3933c38dec92eaf20 ( https://reviews.freebsd.org/D38756 ) The 1st of the 2 is the actual fix (essential), quoting: bcm_dma: attach at an earlier bus pass The sdhci_bcm driver attach routine relies on bcm_dma already being attached, in order to allocate a DMA channel. However, both drivers attached at the default pass so this is not guaranteed. Newer RPI firmware exposes this assumption, and the result is a NULL-dereference in bcm_dma_allocate(). To fix this, use BUS_PASS_SUPPORTDEV for bcm_dma. . . . diff --git a/sys/arm/broadcom/bcm2835/bcm2835_dma.c = b/sys/arm/broadcom/bcm2835/bcm2835_dma.c index cab8639bb607..af86647704f6 100644 --- a/sys/arm/broadcom/bcm2835/bcm2835_dma.c +++ b/sys/arm/broadcom/bcm2835/bcm2835_dma.c @@ -766,5 +766,6 @@ static driver_t bcm_dma_driver =3D { =20 static devclass_t bcm_dma_devclass; =20 -DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, bcm_dma_devclass, 0, = 0); +EARLY_DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, = bcm_dma_devclass, 0, 0, + BUS_PASS_SUPPORTDEV + BUS_PASS_ORDER_MIDDLE); MODULE_VERSION(bcm_dma, 1); The 2nd deals with improving error handling to avoid "NULL softc"s leading to crashes. But that is not essential to allowing more recent firmware. =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CDF641F7-351E-418B-98F0-329087BF969E>