[Bug 261147] sysutils/rpi-firmware/ RPI Zero 2 W boot files
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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 on the CC list for the bug.