Bug #845
closed
brcm wifi driver not working on 3b+ boards.
Added by Hammel almost 3 years ago. Updated 7 months ago.
100%
Description
This was working on the RPi used with the 7" touchscreen. But now it's not working with the boards working with the TFT displays.
Need to investigate what broke.
Updated by Hammel almost 3 years ago
See this rpi forum post. Apparently I might need to fallback to older firmware.
wget https://archive.raspberrypi.org/debian/pool/main/f/firmware-nonfree/firmware-brcm80211_20161130-3+rpt3_all.deb ar firmware*.deb tar xf data.tar.gz cp lib/firmware/brcm/* to RPi
The downloaded .deb is in rpi2/extras/netconfig.
Updated by Hammel almost 3 years ago
- % Done changed from 0 to 10
According to this thread, specifically this post, the firmware was broken on 3b+ and 4's with an update pushed on Jan 25h. I"m using a Jan 8th download, so rebuilding the firmware might fix this problem. Maybe. However, this is from the RPi firmware-nonfree repo, which I"m not currently using. So I should add that to the dev platform build first.
Using platform-nonfree should allow me to change how I grab the brcm firmware and .txt files. Currently they are in fw.cfg, which might need more special case handing on where to grab them from.
Updated by Hammel over 2 years ago
Checking brcmfmac43455-sdio.bin in the non-free repo, it appears that the Jan25th commit is the last one. So maybe bumping back to the one before that is sufficient? If so, I can use the fw.cfg as I have been.
But wait - that has been pulling from the non-free repo all this time! The problem is it's probably pulling from master. The one I probably want is
https://github.com/RPi-Distro/firmware-nonfree/raw/7533cd1f124f07d87ca6fd11a4a2143748ed806c/brcm/brcmfmac43455-sdio.bin
along with
https://github.com/RPi-Distro/firmware-nonfree/raw/7533cd1f124f07d87ca6fd11a4a2143748ed806c/brcm/brcmfmac43455-sdio.clm_blob
and
https://raw.githubusercontent.com/RPi-Distro/firmware-nonfree/7533cd1f124f07d87ca6fd11a4a2143748ed806c/brcm/brcmfmac43455-sdio.txt
I need to grab these on a test system, reboot and see if bringing up the wifi client manually works. FYI - currently bringing up the wifi client manually fails. If you run iwlist scan you get the following in dmesg:
[ 422.529171] ieee80211 phy0: brcmf_run_escan: error (-52)
[ 422.534527] ieee80211 phy0: brcmf_cfg80211_scan: scan error (-52)
Updated by Hammel over 2 years ago
- Status changed from New to In Progress
- % Done changed from 10 to 40
I got the device working manually today. I ran the following command to disable power management;
iw wlan0 set power_save offThen restarted wpa_supplicant
wpa_supplicant -B -c /etc/wpa_supplicant.conf -Dnl80211 -iwlan0 &and finally brought up the interface
ifup wlan0I came up on the NG-mixed network with dynamic channel width (20/40MHz).
This test used the older firmware. I need to put the latest firmware back on and try it again to see if that works with the power-management fix.
Either way, I'll need an update to disable the power-management. This should only happen if I'm using the brcmfmac driver for wifi. Not sure if the change should go in S40network, which would need a test to determine what wifi driver is in use, or in modules.conf (which current has brcmfmac commented out because the driver is loaded by a DTS overlay now).
Updated by Hammel over 2 years ago
There is an old stackexchange discussion that says power management is off by default now, but apparently it's not. Perhaps that's because the new firmware has it fixed but breaks something else, so I went back to the old firmware which might have power management enabled but doesn't have the new firmware bug. It's just a possibility.
It also suggests adding the following to /etc/network/interfaces.
allow-hotplug wlan0
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
wireless-power off
and suggests that power management should be disabled for all wifi devices, even usb ones. That would mean I don't really need to test for which wifi is up, but rather just disable power management for all of them.
Updated by Hammel over 2 years ago
- % Done changed from 40 to 70
I was way off on this one. It's the clm_blob file that was missing from the build. Leave it out and the driver doesn't load. Add it in and everything is fine. It's a one line fix.
Need to verify this on a second device, just to be certain.
Updated by Hammel over 2 years ago
Nope, a clean build with just the clm blob didn't work with master branch firmware, with or without disabling power management.
Next up: try with the back rev'd firmware instead.
Updated by Hammel over 2 years ago
Just did a comparison of the node that works and the one that doesn't - and I can find no software differences. I ran sum's on all the firmware files and they match. I have all the same firmware files by name. I have the same wpa_supplicant and interfaces files.
That said, the files from the .deb I have do not match what I have in the build. Also, the non-firmware git log shows various changes this year so maybe I can pull from an earlier version that way.
It's still not really resolved after all.
Updated by Hammel over 2 years ago
- % Done changed from 70 to 80
- I switched SD cards to see if the first would work in the second and found that the MAC was not added to the mac filter list on the router.
- The second had eth0 enabled in /etc/network/interfaces.
So I enabled eth0 in the first and now both are working. Apparently, you have to enable eth0 (and possibly try to dhcp it) before wlan0 works. Going to test this again on both devices to be certain.
Updated by Hammel over 2 years ago
I give up - everything seems to be working fine now. Maybe it was the router being finicky. But the addition of the clm blob seems to be all that was needed to make the driver happy. And new builds on each of three different boards all come up cleanly now. I retried the build with pisentry and it came up just fine this time. And this without eth0 enabled. I'm going to do a build with eth0 enabled by default in the dev platform and then again in pisentry to make sure enabling that doesn't break anything. Then I'll push the changes and close this issue.
Updated by Hammel over 2 years ago
- Status changed from In Progress to Closed
- % Done changed from 80 to 100
Changes tested successfully, committed and pushed.
Closing issue.
Updated by Hammel over 2 years ago
- Status changed from Closed to In Progress
- % Done changed from 100 to 90
This just isn't stable. I've got a Pi with a TFT that only gets the wifi up for brief periods, if at all, but never long enough to configure it to the local router.
I have power management disabled on it, forced via the init script (instead of /etc/network/interfaces). I have eth0 enabled since that, at one point, seemed to be required to get the device to be seen at all on the Pi. But there are errors in /var/log/messages about brcmf_vif_set_mgmt_ie: vndr set ie error that need to be investigated.
Honestly, I think trying to drop back to an earlier set of firmware blobs is really the next step. It's also possible the bug is in hostapd but I doubt it.
One last test: manually add wpa_supplicant config and see if the interface comes up and stays up. If it does, then it's hostapd and/or how pinet configures the AP.
Changing wpa_supplicant didn't work, but adding eth0 to interfaces did. I need to fix the interfaces file in pinet then, because apparently having eth0 up makes wlan0 come up.
Updated by Hammel over 2 years ago
Tried older firmware but that didn't work at all. The new firmware works fine as a client. But it seems to fail as an AP.
One report says to try this version to avoid crashing the firmware:
http://archive.raspberrypi.org/debian/pool/main/f/firmware-nonfree/firmware-brcm80211_20190114-1+rpt4_all.deb
There are also more 20190114 releases at the same site going up through 2021. But the report says bugs start with firmware-brcm80211_20190114-1+rpt6_all so using rpt4 is a good bet to try.
Might also try adding brcmfmac.debug=0x100000 in config.txt.
Updated by Hammel over 2 years ago
Still not making any progress on this.
Here's another reported issue from a few years ago that sounds just like my issue. The implication here is that I possibly have to fall back to a 4.19 kernel and associated firmware.
I can enable debug with -s -dd for hostapd, which gives lots of additional info in /var/log/messages.
The test device has eth0 enabled at 81.
Updated by Hammel over 2 years ago
- Priority changed from Immediate to Urgent
- Severity changed from 02 - High to 03 - Medium
I've tried everything I can think of short of trying to fall back to 4.19.x and nothing has worked. So for now, I'm giving up on brcm and going back to dongles.
Just add this to config.txt:
dtoverlay=disable-wifiUpdate: a wifi dongle worked fine. So it's really just the brcm wifi that's messed up.
Updated by Hammel 11 months ago
- Priority changed from Urgent to Immediate
- Target version changed from 2.0 - Harkonnen to 3.0 - Corrino
- Severity changed from 03 - Medium to 05 - Very Low
At the end of the 2.0 release cycle the brcm driver started working again. It's unclear why, but I need to validate that it stays that way after updating kernel and buildroot builds for 3.0.