I have diagnosed the problem as follows.
My broadcom 43455 adapter needs:
1. a different brcm43455-sdio.txt file from the one supplied in ubuntu,
which is a cypress provided version.
2. a different brcm43455-sdio.bin file from the one supplied in ubuntu,
that again is a cypress provided version
3. a different brcm43455-sdio.clm_blob file from the one supplied in
ubuntu
Now, 1 and 2 are no issue: I can supply the files needed by my hardware and put
them side to side to the ubuntu supplied ones. This is because the system will
seek `brcm43455-sdio.AZW-Z83 II.{txt, bin} first.
Incidentally, the txt file can be easily taken from the nvram of my system,
while the bin file is the one that is supplied in armbian, libreelec etc, that
for some reason is not the same as the cypress one found in ubuntu.
The real problem is 3. And this is because without the file made for my
hardware, the wifi will work in the 2.4 GHz band, but not in the 5GHz
band. However the file name for this does not appear to be adapted to my
system. Namely, if I put a 'brcm43455-sdio.AZW-Z83 II.clm_blob' file
side to side to 'brcm43455-sdio.clm_blob' that will be ignored.
This makes it impossible to place board specific brcm files *side to
side* the those currently specified by the distro (unless I miss
something). If this is the case, then there are two possible
workarounds:
1. Make a deb file with a diversion for the clm_blob file
2. Use the brcmfmac module option `alternative_fw_path` to specify and
alternative firmware path for my brcm hardware and put my bin, txt and clm_blob
files there
However, I really tend to think that these are just ugly workarounds for
what is ultimately an issue with the brcmfmac kernel module. If the
module can determine that for by board the filename should be
`brcm43455-sdio.AZW-Z83 II.{txt,bin}` for the txt and bin pieces of the
firmware, then why cannot it look at `brcm43455-sdio.AZW-Z83
II.clm_blob` before falling back to `brcm43455-sdio.clm_blob`? That
would make it easy to put different firmwares in the the brcm firmware
directory side by side and make the framework that is already there for
the txt and bin files actually useful.
Please consider reopening the issue, passing it to the brcmfmac
maintainers.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-firmware in Ubuntu.
https://bugs.launchpad.net/bugs/2013027
Title:
Issues over broadcom brcmfmac43455 firmware
Status in linux-firmware package in Ubuntu:
Incomplete
Status in linux-firmware-raspi2 package in Ubuntu:
Invalid
Bug description:
Hi, I have a Kodlix Z83-II minicomputer that employs a broadcom
chipset for WIFI.
The only way to make wifi on that PC work is to use the firmware from
the windows image, even if that chipset is apparently managed in
ubuntu.
With the firmware files provided by ubuntu you get no 5GHz for wifi.
The problem is that every time ubuntu updates the firmware package,
firmware files dropped in /lib/firmware get overwritten, linking to
some file in the cypress sub-directory.
- Ideally, Ubuntu should provide all the firmware files that might be
needed. Maybe this is not possible as there is a too large variety of
different firmwares for broadcom chipsets or licesing issues
preventing distribution.
- As a second possibility, there should be a way to drop files in
/lib/firmware 'side to side' to the distro ones, without having the
risk of finding the manually added files rewritten. This implies that
different pieces of hardware use firmware files with different
filenames. Don't know if this is truly possible, as I do not know how
the linux kernel decides the name of the firmware to load.
- In cases like mine, it seems that the ubuntu firmware package puts
in place symlinks to have brcmfmac43455 files point to the
corresponding cypress cyfmac43455 files. Possibly, the package could
avoid creating the symlinks if a brcmfmac43455 file is manually placed
in lib/firmware.
- As a last resort, I think that the documentation in
`/usr/share/doc/linux-firmware` should be augmented to describe the
most appropriate way to prevent custom firmware files from being
rewritten: marking files not-writable? introducing diversions?
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/2013027/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
