Re: Raspberry Pi POE+ hat overlay

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.
>> 
> 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=1 in config.txt which boosts the cpu frequency up to 1800 for this board.
> 
> 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=stable/13&id=5b6edfc577fbb4e9703c112713c7fb472e144346
( https://bugs.freebsd.org/268835 )
and
https://cgit.freebsd.org/src/commit/?h=stable/13&id=aa399ad3e554223b8bf741c3933c38dec92eaf20
( 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 = {
  
  static devclass_t bcm_dma_devclass;
  
-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.

===
Mark Millard
marklmi at yahoo.com