Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#999485: firmware-brcm80211: Please add brcmfmac43456-sdio.* files for wifi support in Raspberry p400
310 views
Skip to first unread message
Gunnar Wolf
Nov 11, 2021, 2:40:04 PM11/11/21
to
Package: firmware-brcm80211
Version: 20210818-1
Severity: normal
Tags: newcomer
The Raspberry Pi p400 is very similar to the 4 family, but the Wifi
chip is a slightly different model, and is thus not recognized when
running with Debian, not even with firmware-brcm80211.
We need the addition of three files, all three of them available in
RPi-Distro's firmware-nonfree repository in Github
(https://github.com/RPi-Distro/firmware-nonfree/tree/master/brcm/):
brcmfmac43456-sdio.bin
brcmfmac43456-sdio.clm_blob
brcmfmac43456-sdio.txt
Thank you very much!
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.8.0-3-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Version: 20210818-1
Severity: normal
Tags: newcomer
The Raspberry Pi p400 is very similar to the 4 family, but the Wifi
chip is a slightly different model, and is thus not recognized when
running with Debian, not even with firmware-brcm80211.
We need the addition of three files, all three of them available in
RPi-Distro's firmware-nonfree repository in Github
(https://github.com/RPi-Distro/firmware-nonfree/tree/master/brcm/):
brcmfmac43456-sdio.bin
brcmfmac43456-sdio.clm_blob
brcmfmac43456-sdio.txt
Thank you very much!
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.8.0-3-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Gunnar Wolf
Apr 9, 2022, 7:00:03 PM4/9/22
to
Please note I'm currenlty shipping the required files in
raspi-firmware -- I believe their right place is in
firmware-brcm80211, so please just ping me (or better, raise a bug on
raspi-firmware) whent they are added to this package.
Thanks!
raspi-firmware -- I believe their right place is in
firmware-brcm80211, so please just ping me (or better, raise a bug on
raspi-firmware) whent they are added to this package.
Thanks!
Rich
Apr 21, 2022, 2:00:04 AM4/21/22
to
FYI to anyone with a Pi 400, stealing the raspi-firmware from sid (raspi-firmware_1.20220331+ds-1 as of this writing) and rebooting results in working wifi on bullseye.
Cherrypicking these three files on their own from upstream rpi-firmware didn't, so still something to be debugged about what needs to change...
- Rich
Diederik de Haas
Nov 10, 2022, 5:50:03 AM11/10/22
to
Diederik de Haas
Dec 5, 2022, 2:10:04 PM12/5/22
to
Control: retitle -1 Please add brcmfmac43456-sdio.* files as it's not just used in RPi devices
From https://bugs.debian.org/1023741:
> I completely agree that firmware-brcm80211 is the right place and
> raspi-firmware is the wrong place as this is about firmware for wifi
> devices which are f.e. also used on Pine64 devices.
Gunnar indicated that he's willing to remove the files from raspi-firmware,
but they still need to be added to firmware-brcm80211, so pretty please?
> I completely agree that firmware-brcm80211 is the right place and
> raspi-firmware is the wrong place as this is about firmware for wifi
> devices which are f.e. also used on Pine64 devices.
Gunnar indicated that he's willing to remove the files from raspi-firmware,
but they still need to be added to firmware-brcm80211, so pretty please?
Salvatore Bonaccorso
Jan 31, 2023, 1:30:04 PM1/31/23
to
Hi Diederik, hi Gunnar,
So I looked at this, and don't think the firmware-nonfree packages
should take it over. Why? The firmware files are not part of
linux-firmware.git .
Would they fit into a separate source package not associated with
raspi-config?
The other option is that they get included upstream in
linux-firmware.git by upstream?
Regards,
Salvatore
should take it over. Why? The firmware files are not part of
linux-firmware.git .
Would they fit into a separate source package not associated with
raspi-config?
The other option is that they get included upstream in
linux-firmware.git by upstream?
Regards,
Salvatore
Diederik de Haas
Jan 31, 2023, 4:40:05 PM1/31/23
to
Hi Salvatore and Gunnar,
On Tuesday, 31 January 2023 19:17:43 CET Salvatore Bonaccorso wrote:
> > Gunnar indicated that he's willing to remove the files from
> > raspi-firmware,
> > but they still need to be added to firmware-brcm80211, so pretty please?
>
> So I looked at this, and don't think the firmware-nonfree packages
> should take it over. Why?
> The firmware files are not part of linux-firmware.git .
I understand that reasoning and as said on IRC, that was the reason that I did
not know how to deal with that and therefor couldn't make a MR myself.
> Would they fit into a separate source package not associated with
> raspi-config?
I do strongly think they do not belong in the raspi-firmware package for the
reason I retitled this bug and retitled my response Subject. Another reason is
that the raspi-firmware package makes (several) assumptions, namely that they
are only used/usable on RPi devices and have a /boot/firmware directory (where
a FAT partition is mounted, although that part is not checked for).
I have previously expressed my concerns/doubts about that, but that's outside
the scope of this bug.
It also looks 'weird' to install the raspi-firmware package while you only care
about the wifi firmware and not care about RPi's at all.
> The other option is that they get included upstream in
> linux-firmware.git by upstream?
Gunnar knows I'm not much of a fan of Raspberry Pi Foundation (RPF) and that
was confirmed once again by their typical reaction to this exact request.
I'm too 'lazy' to look it up, so I'll paraphrase it:
"It works for us (so fsck off). Can't you just use our files?"
Regards,
Diederik
On Tuesday, 31 January 2023 19:17:43 CET Salvatore Bonaccorso wrote:
> > Gunnar indicated that he's willing to remove the files from
> > raspi-firmware,
> > but they still need to be added to firmware-brcm80211, so pretty please?
>
> So I looked at this, and don't think the firmware-nonfree packages
> should take it over. Why?
> The firmware files are not part of linux-firmware.git .
not know how to deal with that and therefor couldn't make a MR myself.
> Would they fit into a separate source package not associated with
> raspi-config?
reason I retitled this bug and retitled my response Subject. Another reason is
that the raspi-firmware package makes (several) assumptions, namely that they
are only used/usable on RPi devices and have a /boot/firmware directory (where
a FAT partition is mounted, although that part is not checked for).
I have previously expressed my concerns/doubts about that, but that's outside
the scope of this bug.
It also looks 'weird' to install the raspi-firmware package while you only care
about the wifi firmware and not care about RPi's at all.
> The other option is that they get included upstream in
> linux-firmware.git by upstream?
was confirmed once again by their typical reaction to this exact request.
I'm too 'lazy' to look it up, so I'll paraphrase it:
"It works for us (so fsck off). Can't you just use our files?"
Regards,
Diederik
Gunnar Wolf
Feb 1, 2023, 10:30:04 PM2/1/23
to
Hi!
Diederik de Haas dijo [Tue, Jan 31, 2023 at 10:33:41PM +0100]:
raspi-nonfree came from a "coherent" set of firmware sources provided
by a single upstream. It is a distorsion that peopleinterested in
brcmfmac firmware have to install raspi-firmware if they have
different hardware.
> > The other option is that they get included upstream in
> > linux-firmware.git by upstream?
>
> Gunnar knows I'm not much of a fan of Raspberry Pi Foundation (RPF) and that
> was confirmed once again by their typical reaction to this exact request.
>
> I'm too 'lazy' to look it up, so I'll paraphrase it:
> "It works for us (so fsck off). Can't you just use our files?"
I doubt we will find true RPF fans here 😉
Diederik de Haas dijo [Tue, Jan 31, 2023 at 10:33:41PM +0100]:
> > Would they fit into a separate source package not associated with
> > raspi-config?
>
> I do strongly think they do not belong in the raspi-firmware package for the
> reason I retitled this bug and retitled my response Subject. Another reason is
> that the raspi-firmware package makes (several) assumptions, namely that they
> are only used/usable on RPi devices and have a /boot/firmware directory (where
> a FAT partition is mounted, although that part is not checked for).
> I have previously expressed my concerns/doubts about that, but that's outside
> the scope of this bug.
> It also looks 'weird' to install the raspi-firmware package while you only care
> about the wifi firmware and not care about RPi's at all.
Right, I agree this should be a package of its own. I didn't know
> > raspi-config?
>
> I do strongly think they do not belong in the raspi-firmware package for the
> reason I retitled this bug and retitled my response Subject. Another reason is
> that the raspi-firmware package makes (several) assumptions, namely that they
> are only used/usable on RPi devices and have a /boot/firmware directory (where
> a FAT partition is mounted, although that part is not checked for).
> I have previously expressed my concerns/doubts about that, but that's outside
> the scope of this bug.
> It also looks 'weird' to install the raspi-firmware package while you only care
> about the wifi firmware and not care about RPi's at all.
raspi-nonfree came from a "coherent" set of firmware sources provided
by a single upstream. It is a distorsion that peopleinterested in
brcmfmac firmware have to install raspi-firmware if they have
different hardware.
> > The other option is that they get included upstream in
> > linux-firmware.git by upstream?
>
> Gunnar knows I'm not much of a fan of Raspberry Pi Foundation (RPF) and that
> was confirmed once again by their typical reaction to this exact request.
>
> I'm too 'lazy' to look it up, so I'll paraphrase it:
> "It works for us (so fsck off). Can't you just use our files?"
Salvatore Bonaccorso
Feb 4, 2023, 4:20:04 PM2/4/23
to
Hi,
On Wed, Feb 01, 2023 at 09:20:57PM -0600, Gunnar Wolf wrote:
> Hi!
>
> Diederik de Haas dijo [Tue, Jan 31, 2023 at 10:33:41PM +0100]:
> > > Would they fit into a separate source package not associated with
> > > raspi-config?
> >
> > I do strongly think they do not belong in the raspi-firmware package for the
> > reason I retitled this bug and retitled my response Subject. Another reason is
> > that the raspi-firmware package makes (several) assumptions, namely that they
> > are only used/usable on RPi devices and have a /boot/firmware directory (where
> > a FAT partition is mounted, although that part is not checked for).
> > I have previously expressed my concerns/doubts about that, but that's outside
> > the scope of this bug.
> > It also looks 'weird' to install the raspi-firmware package while you only care
> > about the wifi firmware and not care about RPi's at all.
>
> Right, I agree this should be a package of its own. I didn't know
> raspi-nonfree came from a "coherent" set of firmware sources provided
> by a single upstream. It is a distorsion that peopleinterested in
> brcmfmac firmware have to install raspi-firmware if they have
> different hardware.
So I guess we can close this bug here, and the files can be shipped
with a new dedicated source package containing the firmware files,
since the last option of having them merged upstream in
linux-firmware.git seems unrealistic for now?
Regards,
Salvatore
p.s.: sorry misstyped initially the origin source package, was obviously
not meaning raspi-config, so raspi-firmware.
On Wed, Feb 01, 2023 at 09:20:57PM -0600, Gunnar Wolf wrote:
> Hi!
>
> Diederik de Haas dijo [Tue, Jan 31, 2023 at 10:33:41PM +0100]:
> > > Would they fit into a separate source package not associated with
> > > raspi-config?
> >
> > I do strongly think they do not belong in the raspi-firmware package for the
> > reason I retitled this bug and retitled my response Subject. Another reason is
> > that the raspi-firmware package makes (several) assumptions, namely that they
> > are only used/usable on RPi devices and have a /boot/firmware directory (where
> > a FAT partition is mounted, although that part is not checked for).
> > I have previously expressed my concerns/doubts about that, but that's outside
> > the scope of this bug.
> > It also looks 'weird' to install the raspi-firmware package while you only care
> > about the wifi firmware and not care about RPi's at all.
>
> Right, I agree this should be a package of its own. I didn't know
> raspi-nonfree came from a "coherent" set of firmware sources provided
> by a single upstream. It is a distorsion that peopleinterested in
> brcmfmac firmware have to install raspi-firmware if they have
> different hardware.
with a new dedicated source package containing the firmware files,
since the last option of having them merged upstream in
linux-firmware.git seems unrealistic for now?
Regards,
Salvatore
p.s.: sorry misstyped initially the origin source package, was obviously
not meaning raspi-config, so raspi-firmware.
Diederik de Haas
Feb 4, 2023, 5:00:05 PM2/4/23
to
On Saturday, 4 February 2023 22:12:24 CET Salvatore Bonaccorso wrote:
> > Right, I agree this should be a package of its own. I didn't know
> > raspi-nonfree came from a "coherent" set of firmware sources provided
> > by a single upstream. It is a distorsion that peopleinterested in
> > brcmfmac firmware have to install raspi-firmware if they have
> > different hardware.
>
> So I guess we can close this bug here, and the files can be shipped
> with a new dedicated source package containing the firmware files,
> since the last option of having them merged upstream in
> linux-firmware.git seems unrealistic for now?
We could do that, but wouldn't it make more sense to reassign it to wnpp (?)
> > Right, I agree this should be a package of its own. I didn't know
> > raspi-nonfree came from a "coherent" set of firmware sources provided
> > by a single upstream. It is a distorsion that peopleinterested in
> > brcmfmac firmware have to install raspi-firmware if they have
> > different hardware.
>
> So I guess we can close this bug here, and the files can be shipped
> with a new dedicated source package containing the firmware files,
> since the last option of having them merged upstream in
> linux-firmware.git seems unrealistic for now?
and turn it into a RFP type bug?
That way we would preserve the history (and thus useful info) of this issue.
My 0.02
Salvatore Bonaccorso
Feb 5, 2023, 10:30:05 AM2/5/23
to
Hi Diederik,
Sure, we can do that as well. Drawback is that the initial mail does
not contain the details for the RFP, but it is a sensible idea.
Thank you. Regards,
Salvatore
not contain the details for the RFP, but it is a sensible idea.
Thank you. Regards,
Salvatore
Diederik de Haas
Feb 5, 2023, 4:40:05 PM2/5/23
to
Hi Salvatore,
On Sunday, 5 February 2023 16:17:58 CET Salvatore Bonaccorso wrote:
> > > So I guess we can close this bug here, and the files can be shipped
> > > with a new dedicated source package containing the firmware files,
> > > since the last option of having them merged upstream in
> > > linux-firmware.git seems unrealistic for now?
> >
> > We could do that, but wouldn't it make more sense to reassign it to wnpp
> > (?) and turn it into a RFP type bug?
> >
> > That way we would preserve the history (and thus useful info) of this
> > issue.
> Sure, we can do that as well. Drawback is that the initial mail does
> not contain the details for the RFP, but it is a sensible idea.
Please follow your initial idea. If need be, we can always reference this bug
in the new RFP bug. It's not like closing this bug will make it disappear from
the face of the earth ;-)
You (seem to) know what can and needs to be done, while I don't.
Regards,
Diederik
On Sunday, 5 February 2023 16:17:58 CET Salvatore Bonaccorso wrote:
> > > So I guess we can close this bug here, and the files can be shipped
> > > with a new dedicated source package containing the firmware files,
> > > since the last option of having them merged upstream in
> > > linux-firmware.git seems unrealistic for now?
> >
> > We could do that, but wouldn't it make more sense to reassign it to wnpp
> > (?) and turn it into a RFP type bug?
> >
> > That way we would preserve the history (and thus useful info) of this
> > issue.
> Sure, we can do that as well. Drawback is that the initial mail does
> not contain the details for the RFP, but it is a sensible idea.
in the new RFP bug. It's not like closing this bug will make it disappear from
the face of the earth ;-)
You (seem to) know what can and needs to be done, while I don't.
Regards,
Diederik
James Addison
May 8, 2023, 6:00:06 AM5/8/23
to
Package: firmware-brcm80211
Followup-For: Bug #999485
X-Debbugs-Cc: gw...@gwolf.org, didi....@cknow.org, 102...@bugs.debian.org
> The other option is that they get included upstream in
> linux-firmware.git by upstream?
As an update about this: in the past it seems that one of the blockers for
upstreaming was an unclear licensing situation for the firmware. The other,
maybe more important blocker is that it tends to be (as I understand it)
vendors themselves who are expected to offer files to the linux-firmware.git
repo.
There is now a license available for the brcmfmac43456 firmware: it's included
in the relevant RPF package metadata, in the usual copyright file:
https://archive.raspberrypi.org/debian/pool/main/f/firmware-nonfree/firmware-nonfree_20221012-1~bpo11+1+rpt1.debian.tar.xz
(since we're talking about non-free firmware, I don't think that there is a
DFSG compatibility concern with packaging this, although the linux-firmware.git
maintainers likely have their own acceptance criteria. even so, if/when we
are creating another package, we should probably distribute the same license
file now that it's available. I can prepare a patch if that'd be helpful,
since I'm risking creating work by mentioning it)
There don't appear to be many Synaptics contributors active on the Linux
kernel mailing lists re: wireless devices.. so I'm not sure what the best way
to approach them to ask about submitting the firmware upstream would be.
RPF have also had inbound requests to upload the firmware, but I don't think
that it's their responsibility (or right) to do that.
And finally a kind of meta-point: I've found the name 'firmware' kinda
confusing while trying to install and correctly configure my RPi. It seems to
me like we're referring to two types of firmware: firmware used by kernel
modules (as in: linux-firmware.git, firmware-brcm80211, brcmfmac, etc), but
also boot-time-firmware required during all the weirdness to get the RPi
system to load a kernel and initrd.
Is there another term for the latter, to disambiguate it when we talk about it
and name packages? Software that's like firmware and used to boot the system?
Followup-For: Bug #999485
X-Debbugs-Cc: gw...@gwolf.org, didi....@cknow.org, 102...@bugs.debian.org
> The other option is that they get included upstream in
> linux-firmware.git by upstream?
upstreaming was an unclear licensing situation for the firmware. The other,
maybe more important blocker is that it tends to be (as I understand it)
vendors themselves who are expected to offer files to the linux-firmware.git
repo.
There is now a license available for the brcmfmac43456 firmware: it's included
in the relevant RPF package metadata, in the usual copyright file:
https://archive.raspberrypi.org/debian/pool/main/f/firmware-nonfree/firmware-nonfree_20221012-1~bpo11+1+rpt1.debian.tar.xz
(since we're talking about non-free firmware, I don't think that there is a
DFSG compatibility concern with packaging this, although the linux-firmware.git
maintainers likely have their own acceptance criteria. even so, if/when we
are creating another package, we should probably distribute the same license
file now that it's available. I can prepare a patch if that'd be helpful,
since I'm risking creating work by mentioning it)
There don't appear to be many Synaptics contributors active on the Linux
kernel mailing lists re: wireless devices.. so I'm not sure what the best way
to approach them to ask about submitting the firmware upstream would be.
RPF have also had inbound requests to upload the firmware, but I don't think
that it's their responsibility (or right) to do that.
And finally a kind of meta-point: I've found the name 'firmware' kinda
confusing while trying to install and correctly configure my RPi. It seems to
me like we're referring to two types of firmware: firmware used by kernel
modules (as in: linux-firmware.git, firmware-brcm80211, brcmfmac, etc), but
also boot-time-firmware required during all the weirdness to get the RPi
system to load a kernel and initrd.
Is there another term for the latter, to disambiguate it when we talk about it
and name packages? Software that's like firmware and used to boot the system?
James Addison
May 8, 2023, 12:40:06 PM5/8/23
to
Package: firmware-brcm80211
Followup-For: Bug #999485
X-Debbugs-Cc: gw...@gwolf.org, didi....@cknow.org, 102...@bugs.debian.org
Dear Maintainer,
Followup-For: Bug #999485
X-Debbugs-Cc: gw...@gwolf.org, didi....@cknow.org, 102...@bugs.debian.org
> There is now a license available for the brcmfmac43456 firmware: it's included
> in the relevant RPF package metadata, in the usual copyright file:
>
> https://archive.raspberrypi.org/debian/pool/main/f/firmware-nonfree/firmware-nonfree_20221012-1~bpo11+1+rpt1.debian.tar.xz
distribution with Debian.
It does the following:
* Adds a new entry to the debian/copyright file that adds the updated license
and mentions the download origin (similar to the existing entry). The file
pattern is specific to the 43456-class firmware files.
* Moves the LICENSE file to LICENSE.Broadcom as a disambiguation.
* Adds a LICENSE.Synaptics file, matching the contents of debian/copyright.
And some notes:
* Although this is an updated license, I've confirmed that the firmware file
*contents* have *not* changed the raspi-firmware-1.20220830+ds upload
(before the license was available). The content hashes stay the same, at:
c5bc73bfee9085c2ba1e5f52bc811cabae81cd16df2d1e866aa646ee7fe83534 brcmfmac43456-sdio.bin.base64
08f7ed881894d41f1e50ed0446fb9868c1019b92f8ad582e6cc361577a3e57a6 brcmfmac43456-sdio.clm_blob.base64
44e0bb322dc1f39a4b0a89f30ffdd28bc93f7d7aaf534d06d229fe56f6198194 brcmfmac43456-sdio.txt
* I've placed the copyright year for Synaptics as Y2020, the year that the
acquisition of Broadcom by Synaptics took place.
If that approach sounds sensible (or not!) please let me know and I can adjust
it and/or upload the patch here/elsewhere.
0 new messages