[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#984489: firmware-brcm80211: newer versions fail to load on raspberry pi 4b with "brcmf_sdio_htclk: HT Avail timeout"



Package: firmware-brcm80211
Version: 20210208-3
Severity: important

The version of firmware-brcm80211 in bullseye (specifically 20201218-3)
works fine on my Rasperry Pi 4 board. However, the version in sid does
not. Specifically, the brcmfmac kernel driver fails to load with some
clock errors. Here's snippets from boot dmesg:

[    0.000000] Linux version 5.10.0-3-arm64 (debian-kernel@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP Debian 5.10.13-1 (2021-02-06)
[    0.000000] Machine model: Raspberry Pi 4 Model B Rev 1.1

[...]

[   10.308867] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[   10.318818] usbcore: registered new interface driver brcmfmac
[   10.322875] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
[   10.335422] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
[   10.343356] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4])
[   10.350443] vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops [vc4])
[   10.358185] vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops [vc4])
[   10.365828] vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops [vc4])
[   10.373704] vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops [vc4])
[   10.376815] brcmfmac mmc0:0001:1: firmware: direct-loading firmware brcm/brcmfmac43455-sdio.bin
[   10.384437] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
[   10.398479] brcmfmac mmc0:0001:1: firmware: direct-loading firmware brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.txt

[...]

[   11.462064] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (1000000): clkctl 0x50

[...]

[   12.471809] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (1000000):
clkctl 0x50


You can specifically see that the driver times out after one second
with that error message, then times out again with the error and gives
up. No wlan0 is available.

There are some pretty major firmware updates between those two
versions, and they are generally Good. However, there's also some minor
updates to the raspi4 board file
/lib//firmware/brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.txt

If we revert the line "boardflags3=0x48200100" in that file back to
what was in the 20201218-3 version (so it would instead be
"boardflags3=0x44200100"), and then reboot, the driver now loads:


[   13.342844] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[   13.353195] usbcore: registered new interface driver brcmfmac
[   13.465495] brcmfmac mmc0:0001:1: firmware: direct-loading firmware brcm/brcmfmac43455-sdio.bin
[   13.472403] vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops [vc4])
[   13.488397] hub 1-1:1.0: 4 ports detected
[   13.488428] vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops [vc4])
[   13.500413] brcmfmac mmc0:0001:1: firmware: direct-loading firmware brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.txt
[   13.673868] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[   13.812345] usb 1-1.3: new high-speed USB device number 3 using xhci_hcd
[   13.856502] brcmfmac mmc0:0001:1: firmware: direct-loading firmware brcm/brcmfmac43455-sdio.clm_blob
[   13.869572] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Sep 18 2020 02:27:58 version 7.45.221 (3a6d3a0 CY) FWID 01-bbd9282b
[...]
[   23.951744] br0: port 2(wlan0) entered blocking state
[   23.953859] br0: port 2(wlan0) entered disabled state
[   23.956221] device wlan0 entered promiscuous mode
[   23.961230] br0: port 3(wlan1) entered blocking state
[   23.963358] br0: port 3(wlan1) entered disabled state
[   23.966488] device wlan1 entered promiscuous mode
[   29.417766] br0: port 2(wlan0) entered blocking state
[   29.419853] br0: port 2(wlan0) entered forwarding state



I'm not sure if the driver needs fixing, or if the boardflags need
fixing, but the boardflags thing seems to be a functional workaround
for users hitting this issue. Thanks to Steev Klimaszewski for helping
me figure out the workaround.


Reply to: