[Bug 261147] sysutils/rpi-firmware/ RPI Zero 2 W boot files

From: <bugzilla-noreply_at_freebsd.org>
Date: Sun, 02 Apr 2023 21:58:49 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261147

--- Comment #9 from Mark Millard <marklmi26-fbsd@yahoo.com> ---
(In reply to Mark Millard from comment #8)

I'll note that main got a kernel fix for what was
leading to crashes for RPi* firmware that was much
newer than what FreeBSD normally uses (as in the
rpi-firmware port). So it may be possible to
experiment with newer RPi* firmware that explicitly
includes Zero 2 W materials. (No claim is the
kernel might need updates for the official .dtb
file.):

A commit in branch main references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=9873b171697033f9f19608d98bcd1c16cacb92af

commit 9873b171697033f9f19608d98bcd1c16cacb92af
Author:     Mark Millard <marklmi26-fbsd@yahoo.com>
AuthorDate: 2023-02-17 20:30:35 +0000
Commit:     Mitchell Horne <mhorne@FreeBSD.org>
CommitDate: 2023-02-24 17:20:40 +0000

    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.

    PR:             268835
    Reviewed by:    mhorne
    MFC after:      1 week

 sys/arm/broadcom/bcm2835/bcm2835_dma.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

stable/13 got the update later but releng/13.2 did
not get the update. So it will be about another, say,
year before there is a releng/13.* with the fix. Thus,
likely, FreeBSD will not progress the RPi* firmware
vintage for at least that long, not wanting to break
releng/13.2 . (Although, releng/14.0 would have the
fix in place and should happen much sooner.)

-- 
You are receiving this mail because:
You are the assignee for the bug.