Hello,
I have a small new net book (Pendo 14"; nearly identical to Aldi Surfer 14) with a UEFI-only boot. Testing with Opensuse Tumbleweed (21-JUly, kernel 4.12) shows all device drivers are installed OK, except for the SDIO (mmc bus) Broadcom wifi/BT combo. The vendor/device ID reported by Win10 is 02d0-a9bf; and is the brcm43455-sdio chipset.

The Brcm 43455 device is detected OK by the brcmfmac driver, and the brcmfmac43455-sdio.bin firmware is loaded OK. The driver complains that the brfmac43455-sdio.txt file cannot be found.

The txt file is derived from the machine's nvram. How do I go about creating the brfmac43455-sdio.txt file?

Can I get a template text file, and fill in the data values derived from the Win10 device manager?

Thank You

Welcome.
I have avoided Broadcom for years due to intransigence on their behalf. I see reports things have improved ... hmmm.
This popped up on a quick search - should be of interest. Still looks pretty ugly.
I would be surprised if Tumbleweed didn't already have linux-firmware available at least, but I'm not an OpenSUSE user.

rowand,

Welcome to LQ.

I am not an openSUSE user either.

Broadcom BCM43455 firmware (brcm/brcmfmac43455-sdio.bin)

Package: firmware-brcm80211 (20161130-3) [non-free]

Binary firmware for Broadcom 802.11 wireless cards

This package contains the binary firmware for wireless network cards supported by the brcmsmac or brcmfmac driver.

https://packages.debian.org/sid/firmware-brcm80211

antiX normally recognises Broadcom cards automatically, but I cannot guarantee that it will do so with this card.

http://antix.mepis.org/index.php?title=Main_Page

https://distrowatch.com/?newsid=09863

Cypress Data Sheet:

http://www.cypress.com/file/298786/download

It is the text FW file that is missing, one of the very few devices that requires this extra file. The binary FW file ships with the Tumbleweed kernel.

The text file contains info that applies to the particular machine, such as MAC address, board revision numbers, etc. This device info is contained in the machine's NVRAM. None of the drivers that require the extra text file get/make it themselves. Thus how do I get a plain english version of the NVRAM contents?

I doubt if anitX (which is 32bit) will boot on a UEFI-only machine. I suspect the boot32 file in the EFI partition needs to be replaced and the Grub2 loader used exclusively.

The answer is the text data is supplied by the manufacturer, which Broadcom refuse to do.

The generic Apac file, in Win10, is \windows\system32\drivers\4345r6nvram.txt Do not edit the file with vi or emacs. Copy it, as is, to /lib/firmware/brcm/brcmfmac43455-sdio.txt. The name root must match the brcmfmac43455-sdio.bin file. It is best to use the Win10 version as it has been altered to meet the local legal requirements. Transmit power, max channels, etc. Any MAC may appear in the text file as it is ignored.

The Wifi works fine after booting. Unfortunately if the system is put to sleep or hibernated, wifi does not return when wakened. This may not be a fault of the Brcmfmac driver.

Well it is - the driver probably isn't being called ...
Likely systemd is in control, but it is possible another power manager is also getting involved. Let's hope not.
You might want to run this past the openSUSE fora. In the meantime, have a read of this - the Arch linux docs are exceptionally good.

The NetworkManager service does restart after a suspend. The wlan0 interface does not. Halting the NM, re-probing brcmfmac, and restarting NM does not work. Thus it is not the same cause as found in Ubuntu 16/17. Brcmfmac is not well tested, so I will file a request somewhere.

Did you try reloading the module for the wireless? That should reload the firmware. If it works, you can edit uswsusp.conf to unload the module on suspend and reload it on wake up. I'd say you did pretty well with that machine!

I tried unloading brcmfmac manually and doing a suspend, and then modprobe. The kernel message was the interface was registered again, yet wlan0 does not show with iwconfig. I understand brcmfmac may well do this itself, as several Brcm cards have power problems. Some are fixed by this trick, but the 43455 is not fixed.

I tried turning off power saving for the card. No good.

The issue may be deeper in the SDIO/USB system. One kernel message after resume was "Interrupt 9 is disabled" as nothing has claimed it.

I will file a kernel bugzilla.

The Aldi Surfer 14 does not used the bcm43455 as it is verboten in Germany.

So like you I bought a laptop with an open source driver broadcom but found out the firmware container that compressed it was proprietary. That was made for it was actually. that laptop was 1997 ok. since the the kernel world made there own and hit and miss. why miss the location of the firmware. seems every distro from hotplug up keeps moving stuff.

what now are you in some systemd world ok. look keep it simple the device and the kernel have to make a hand shake. yes even native. by default older broadcom stuff is blacklisted . you want to use the firmware cutter then blacklist the native one. you want to use the native one. put the /lib/firmware where the kernel can load it.
I keep this simple. Here. Broadcom and the people built this website a long long time ago it still works.
time to learn linux not apt-get http://linuxwireless.org/en/users/Drivers/b43/

Your advice seems to apply to kernels prior to 3.13. For these older kernels, the firmware for SDIO chips, such as bcm4329, was copied to /lib/firmware/brcm/brcmfmac-sdio.bin. This is no longer the case for K4.11 onwards.

I have done some reading, which I'd rather not do, and a large number of these Brcm chips seem to require two reset signals to put them in an operable state after power on.

As you say, the kernel subsytems for wifi cards is now extremely complex. I wrote the first working driver for the SMC91c97 ether PCMCIA card back in 1997 under kernel 1.2.?? (look for email name xcsrdh in very old kernel code to verify my claim). I wrote this since ether cards at the time were $300 and being a scientist in Australia I could not afford a new one.

rowand,

Isn’t the link provided by syg00 in post #2 of any help for current kernels?

https://wireless.wiki.kernel.org/en/...vers/brcm80211

Broadcom brcmfmac driver

Support for both 32 and 64 bit Linux kernels

Firmware installation

Current
For SDIO driver you need to copy the nvram for your system and place it in /lib/firmware/brcm. The nvram file name depends on the chip you have. The kernel log will tell you the exact file name. For the USB driver no nvram file is needed.

The firmware files are located in the linux-firmware repository and can be copied as is to /lib/firmware/brcm.
NVRAM from EFI

Some new devices are storing the nvram which is needed in addition to the firmware by the driver in an EFI variable and the Windows driver can access it (this file should be optional in the case of PCIe devices).

Currently brcmfmac does not support this automatically. First mount the efi vars into sysfs:

The content of the nvram is in this file:

The tip offered in that page to find the NVRAM text file for bcm43455 is wrong.

Actually there is no requirement for the NVRAM (text) file to be in efivars and on most machines it is not. Broadcom in particular seem to want to keep everything secret. Even in Win10 the text file was provided by Apack?.

Upon wake up from sleep the brcmfmac driver reports the interface (wlan0) to be registered with the kernel. It is not. This is a bug in brcmfmac.

Now that you know that yours is the newer one run dmesg look for the error. and you will see what the kernel and that device is doing.