Missing wireless firmware files for the Raspberry Pi Zero 2 W

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Libera.chat.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1980668/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

[ 20.358361] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43436-sdio.raspberrypi,model-zero-2-w.bin failed with error -2
is a red herring.

The kernel tries to load a firmware file based on the board name but fails and falls back to load brcm/brcmfmac43436-sdio which is correct since brcmfmac43436-sdio.raspberrypi,model-zero-2-w.bin would just be a symlink to that file.

Jammy fw version is 9.88.4.65. There's an update in upstream raspberrypi firmware-nonfree bullseye branch. So can you remove any brcm firmware files you manually downloaded and use brcmfmac43436-* from https://github.com/RPi-Distro/firmware-nonfree/tree/bullseye/debian/config/brcm80211/brcm, reboot and check that you're running brcm fw 9.88.4.77. Let us now if that works better.

As Juerg's noted, the error message is indeed safely ignored, and there's a new firmware for the wifi chip upstream. I spent a bit of time on Friday trawling through the history in the upstream firwmare repos and came across a couple of intriguing commits.

Specifically, the commit [1] which updates the wifi firmware notes it is for certain variants of the Pi Zero 2W (there's an associated issue [2] which is an interesting read). The second fascinating commit [3] was, curiously, in the boot firmware. The interesting bit of that commit is "firmware: platform: over-voltage Zero 2 W by two pips". The associated bug [4] indicates that there is a suspicion (unconfirmed at the time of writing) that on some models of the Zero 2W the voltage calibration is marginal and this *may* result in unreliable wifi performance, so the firmware update bumped the voltage handling by default.

I've now built an experimental linux-firmware-raspi package with the bumped wifi and boot firmwares incorporated. It can be found with builds for kinetic and jammy in ppa:waveform/firmware [5]. I would be interested to hear if this firmware package improves your wifi. To test:

  $ sudo add-apt-repository ppa:waveform/firmware
  $ sudo apt install linux-firmware-raspi
  $ sudo reboot

To revert to the current jammy firmware (in case of issues):

  $ sudo add-apt-repository -r ppa:waveform/firmware
  $ sudo apt install linux-firmware-raspi=6-0ubuntu3
  $ sudo reboot

One other thing that may be worth trying is explicitly setting the wifi region (this can make a considerable difference to reliability in certain regions). Currently there's no "good" way of doing this since the crda package was removed upstream (the act of placing the region in /etc/default/crda no longer works). The wifi region can be set ephemerally with "sudo iw reg set" but the only method of persisting it (currently [6]) is to modify the kernel command line. Thankfully though, this isn't terribly difficult on a Pi.

Assuming "FR" is your region, the following would set the region in your current session, and persist it for future boots:

  $ sudo apt install iw
  $ sudo iw reg set FR
  $ sudo sed -i -e 's/$/ cfg80211.ieee80211_regdom=FR' /boot/firmware/cmdline.txt

If it's not too much trouble, I'd be interested to hear if either of these fixes improves things in isolation. In other words, assuming the wifi region is currently unset, I'd be interested to know if *just* updating the firmware fixes things and then if not, if fixing the wifi region improves things (and if so, perhaps roll back the firmware and see if it's still fixed?). This is simply because backporting firmwares is always a bit of a risky business and if wifi issues can be fixed by regulatory domain alone, that's a much safer alternative!

[1]: https://github.com/RPi-Distro/firmware-nonfree/commit/28bad1ec2ef72a33bf84d5c35d1eabc6951506ad

[2]: https://github.com/RPi-Distro/firmware-nonfree/issues/23

[3]: https://github.com/raspberrypi/firmware/commit/274d0c8ac0ec0850193618dce55c005832f918ea

[4]: https://github.com/raspberrypi/firmware/issues/1723

[5]: https://launchpad.net/~waveform/+archive/ubuntu/firmware

[6]: A facility to add the wi...

Thanks a lot Juerg and Dave for your answers and sorry for my late reply, I first had to reinstall Ubuntu 22.04 after finally having found how to install Ubuntu 21.10 to check whether it worked better or not. This took me some time and it appears that it does not work better with Ubuntu 21.10. I gave more explanations regarding this experiment and other things I noticed here: https://answers.launchpad.net/ubuntu/+question/702320

First, sorry for my misunderstanding of the boot logs regarding the firmware load error, I did not notice that despite this error message the right firmware is correctly loaded.

I tried to manually install the firmware files from GitHub as you suggested Juerg. I checked the firmware version in the boot logs and it is the expected one. This unfortunately did not improve the network stability.

I also tried to install the package update as you suggested Dave. I get the exactly same firmware version in the boot logs. As far as I understand, they are the same file, but you packaged them to make the install and uninstall easier, is this correct? The device is now running with this package, and it unfortunately did not change anything.

It remains me to check with the right Wi-Fi region. I was not able to do it for now. I hoped I could connect to the device just after the boot to set the region (sometimes it works for a few minutes), but that did not work. I am going to bring the device back to the house, connect to it and make the change persistent in order to get it directly boot with the right version. I'll let you know when I have tested that.

As I explained in my other post here https://answers.launchpad.net/ubuntu/+question/702320, I think there is a recent change in the device environment that causes some interference. That could explain why the connection is unstable and the throughput very low when the connection is working whereas it worked better a few months ago when I initially installed the device (the connection was stable, the throughput was not very high but clearly satisfying for my use case).

But there is something that remains quite strange and that makes me thing that there may be an hardware or a software issue, it's the fact that the device is generally able to connect at boot but only for a limited time (between a few seconds and multiple hours). After that period, it gets disconnected and is generally no longer able to connect again. What could explain that the connection is only possible after a fresh boot?

Thanks again for the time you spent on this issue and your answers!

Status changed to 'Confirmed' because the bug affects multiple users.

Dave, I tried to change the Wi-Fi region and it did not change anything.

But, a few days after having tested that, I improved my IOT project (improved the software and added a new sensor) and that unexpectedly fixed the issue. I don't see why the python software that the device runs would prevent the Wi-Fi from working, so I assume there was a wiring issue (not sure about that though). I explained a little more here: https://answers.launchpad.net/ubuntu/+question/702320

Once again, thanks to any people that answered to this ticket!

I'm setting this to Invalid given the suspicion that this ended up being a hardware issue and not a software one.