Re: RPI bwfm: checksum error

[Luke Ross <luke%lukeross.name@localhost>]

Hi,

Thanks for your reply!

On Sat, 2021-03-13 at 17:40 +0000, Michael van Elst wrote:
> luke%lukeross.name@localhost (Luke Ross) writes:
> 
> > bwfm0: checksum error
> 
> > I've found both the 0W and the 3A+ (slightly different wifi chip
> > model)
> > exhibit the same error. It's been this way for me for quite a
> > while, up
> > to and including a run with HEAD build 202103121650Z (earmv6hf)
> > today.
> 
> For me it works fine with -current, -9 needs a pullup.
> 
> RPI0w,RPI3 use:
> 
> -r--r--r--  1 root  wheel   388739 Jan  1 15:17 brcmfmac43430-
> sdio.bin
> 
> and RPI3+,RPI4 use:
> 
> -r--r--r--  1 root  wheel   488193 Jan  1 15:17 brcmfmac43455-
> sdio.bin
> 
> -- 

I've hit this issue for quite a while, but my latest experiment was to
write this image, decompressed, to an SD:

http://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/202103121650Z/evbarm-earmv6hf/binary/gzimg/rpi.img.gz

Then I set up /etc/wpa_supplicant.conf and enabled it. I'm using the
firmware supplied in the image, unmodified:

-r--r--r--  1 root  wheel  388739 Mar 12 20:30
/libdata/firmware/if_bwfm/brcmfmac43430-sdio.bin
-r--r--r--  1 root  wheel  488193 Mar 12 20:30
/libdata/firmware/if_bwfm/brcmfmac43455-sdio.bin

MD5 (/libdata/firmware/if_bwfm/brcmfmac43430-sdio.bin) =
ba679a85c1dc76e9775603af45440bc0
MD5 (/libdata/firmware/if_bwfm/brcmfmac43455-sdio.bin) =
0324fe9ce34b6c6c44cc5fd77a669d39

Kernel messages for bwfm on boot:

[     1.461289] bwfm0 at sdmmc1 function 1
[     1.982157] bwfm0: Firmware file default:    brcmfmac43430-sdio.bin
[     1.982157] bwfm0: Firmware file model-spec: brcmfmac43430-
sdio.raspberrypi,model-zero-w.bin
[     2.052412] bwfm0: Found Firmware file: brcmfmac43430-sdio.bin
[     2.092601] bwfm0: NVRAM file default:    brcmfmac43430-sdio.txt
[     2.092601] bwfm0: NVRAM file model-spec: brcmfmac43430-
sdio.raspberrypi,model-zero-w.txt
[     2.092601] bwfm0: Found NVRAM file: brcmfmac43430-
sdio.raspberrypi,model-zero-w.txt
[     4.056557] bwfm0: CHIPACTIVE
[     4.156725] bwfm0: wl0: Oct 23 2017 03:55:53 version 7.45.98.38
(r674442 CY) FWID 01-e58d219f
[     4.156725] bwfm0: address b8:27:eb:d1:0a:8d

There are various ways to get the driver unhappy - about 33% of the
time this will do it:

# ftp
https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/earmv6hf/9.1/All/.pkgcache

...but the most reliable way to reproduce it seems to be via pkgin:

PKG_PATH=http://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/earmv6hf/9.1/All/
export PKG_PATH
pkg_add -v pkgin
vi /usr/pkg/etc/pkgin/repositories.conf and set to
https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/$arch/9.0/All

and then: pkgin update

Something about pkgin (perhaps libfetch?) appears to particularly
trigger this behaviour rapidly, although it's far from the only way.

Possibly-useful information: I have native IPv6 routing, although the
problem still occurs if I force IPv4 by passing "-4" to ftp. I mention
this as I note that the OpenBSD bwfm driver had some purported fixes
for IPv6 handling committed in Nov 2020.

With regards,

Luke