Please submit brcmfmac43436-sdio and brcmfmac43436s-sdio to linux-firmware.git #4723
Comments
|
Can you please share your patches with me. I am happy to test them. They don't need to include firmware. Thanks. |
What patches are you talking about? If it's OpenWrt related better take this to the OpenWrt IRC channel, ML or forum. |
|
Please do this +1! |
|
if I buy a Raspberry Pi Zero 2 am I legally allowed to use other distros? as the purchasee where is the appropriate place for me to obtain the driver? is this legal? |
|
The firmwares for all of our WLAN/BT devices can be found in our firmware-nonfree repo: https://github.com/RPi-Distro/firmware-nonfree/tree/bullseye/debian/config/brcm80211 I'm still trying to get a LICENCE file from Synaptics (43456), and our part of Cypress are now Infineon so that should probably be updated, but all our firmware suppliers understand that the firmware they supply us will be distributed freely. |
|
Cypress/Infineon seem to be regularly updated upstream now, at least for the WLAN part. |
|
Please +1! |
|
This is important! Please expedite it :) thanks! |
Is there a connection between the Raspberry Pi Foundation and that repo? Why would it be under a separate org/user (https://github.com/RPi-Distro) and not under this github org/user (https://github.com/raspberrypi). I'm with @stintel: this should be hosted in the officially linked repos not some other repo.
Once again: then why aren't those distributed through an offical repo/org/user? How would firmware suppliers know that this repo is the official hub of the Raspberry Pi Foundation? Is there an official statement that RPi-Distro is the place to go for firmware used in 3rd party applications? |
|
RPI-distro and raspberrypi are both official repo's of Raspberry Pi Ltd, none of the repo's you mention are Foundation, who do not deal with any of this stuff. It could be argued its not as clear as it could be, and it might be worth getting some links on the Abouts for the root pages to refer to the other pages we also maintain. Will discuss. |
|
@stintel: @JamesH65: Additionally I think it would be a nice addition to have OpenWRT listed in the 3rd party section of the RPi website. OpenWRT as of now supports almost all Raspberry Pi models on the market and (if I haven't missed any model) with only the Zero 2 W missing (yet...). Just like with RetroPie the projects one can build using a Pi with OpenWRT are just fantastic. Especially now with the Zero 2 W's form factor and performance.
|
|
no mention of this Ltd entity on the website about page... only pi foundation maybe thats the reason people are so confused? |
|
It's a pity this is still unsolved :-/ |
|
It's funny you should mention that, the Raspberry Pi github.io page has just gone live: https://raspberrypi.github.io/ It clearly lists all three of our organisations, including RPi-Distro. |
Did you receive feedback from them? How about the comment from @pelwell? Wouldn't that suffice as official statement of this RPi-Distro repo being officially affiliated with Raspberry? |
|
Sometime before covid 2 comes out would be good. I am stuck with 4 pi zero 2's that were intended for a mesh network using openWRT |
|
Are there any news regarding this issue? |
|
RPi-Distro is an official Raspberry Pi repo, as listed above. If you are waiting on us to do something else you will be waiting a long time. |
|
@Nordiii Unfortunately @stintel is still waiting for an answer from SFC. Such a shame this is still on halt. The Zero2 is such a great device and I have it sitting here doing nothing for almost half a year now. https://forum.openwrt.org/t/any-news-regarding-pi-zero-2/115633/10 |
|
This is Denver from Software Freedom Conservancy. I have a few questions that will hopefully get us closer to clarifying the licensing situation with the modules at issue here. In particular: @pelwell @XECDesign Which license is the "Cypress CYW43436-SDIO firmware" distributed under? I see that this firmware was first added by @XECDesign in RPi-Distro/firmware-nonfree@dcea7a3 but no mention was made of the license there. Now we could guess and say it's https://github.com/RPi-Distro/firmware-nonfree/blob/dcea7a3c12490f264033e489f8c6b56032d9f249/debian/config/brcm80211/LICENSE but that doesn't seem right because that @pelwell The files you linked to earlier (at https://github.com/RPi-Distro/firmware-nonfree/blob/buster/LICENCE.broadcom_bcm43xx and https://github.com/RPi-Distro/firmware-nonfree/blob/buster/LICENCE.cypress ) are not near this Cypress CYW43436-SDIO firmware file at all in the directory hierarchy and not even in the same branch, so I'd be hard-pressed to assume that they apply to the files added in RPi-Distro/firmware-nonfree@dcea7a3 (by @XECDesign ) and the more recent update by @pelwell at RPi-Distro/firmware-nonfree@fdaf74c - so at best there is confusion as to which is the correct license file to use, and at worst we might not have permission at all. Moreover, I'm confused as to why no mention of the
Is there some exclusion being made for this Cypress CYW43436-SDIO firmware file? If so, why? If not, where can I find the Note also that neither RPi-Distro/firmware-nonfree@dcea7a3 nor RPi-Distro/firmware-nonfree@fdaf74c have a Signed-off-by line, which is customary for confirming that you are signing off on the licensing situation being settled. It would be nice to see an updated commit with a Signed-off-by line from @pelwell or @XECDesign that resolves the above licensing concerns. Please do let me know if I can clarify anything here. I merely want to ensure that we know what license the |
Add a build of 7.45.241 with a reduced feature set that supports 19 clients in AP mode, while simultaneously allowing it to connect in STA mode. This is intended for applications such as Internet-in-a-Box that don't require advanced features. It is up to the user or distribution to rename the file or create a suitable symbolic link in order to use this cut-down firmware. Signed-off-by: Phil Elwell <[email protected]>
|
I can see light at the end of the tunnel |
Would you say this commit indicates official OpenWRT support for RPiZero2 before the end of this year? |
I don't know to be honest. We're only a formality away from having this as technically the OpenWRT code for zero2 was already there and working. This would be much quicker if people behaved like professionals by reacting/answering/discussing the issue. There's more conversation in here by people that just want to use OpenWRT on their Zero 2s than the actual guys that could make that happen. Would be really cool if @pelwell and @XECDesign could take some minutes respond to @ossguy. His questions are from 6 weeks ago... Not even a single response since. |
|
What questions still remain after the publication of the Synaptics license, and the information that it applies to the 43456, 43436 and 43436P? |
|
@ossguy @stintel any questions left? I see that still there's no sign-off in the commits and the WHENCE file issue is still active. But then again the copyright file contains the license. Not sure if this is sufficient. Excuse my ignorance I'm just a user that wants to use openwrt on the zero2. I don't have any clue about licenses and all the legal mumbojumbo and I especially don't care about the personal quarrels going on in this thread and subthreads (maybe I'm too old for that). I just hope we can finally marry a great software (openwrt) to a great hardware (zero2). It's been quite a while now. |
|
So WHENCE file not mentioned |
|
@stintel can you provide an update to this thread on what all is still pending for them to commit your merge |
|
@andreasbrett should we push for this to be merged before end of summer? |
Like I said in #4723 (comment), I'm waiting for advice from SFC. Aside from that, my device wants brcmfmac43436-sdio.bin, which is not available in the bullseye branch. It seems to be available in the buster branch, but the changes in 4db8c5d80daf2220d7824cfa6052f0bb108612ea don't apply to that. For those who really can't wait to run OpenWrt on their Zero 2 W, see the rpiz2w branch of my staging tree. I would appreciate testing and feedback (but not here, as that's very much off-topic). |
By default, that would end up being a symlink to brcmfmac43436f-sdio.bin in our distro. |
|
@XECDesign can you please elaborate on the difference between 43436f and 43436s files, and symlink requirements to plain 43436? This will greatly help maintainers of non-debian-based distributions on how to make those files available, naming requirements, and eventual needs for symlinks. |
@pelwell should be able to. There are no symlink requirements. This is just how I've added the ability to switch between the two firmware flavours. Other distro maintainers can package things however they feel is most appropriate for them. Somebody who is experienced enough to maintain a distro shouldn't have issues here. |
|
Zero 2 W uses two different of the 43436 for reasons of supply - one that takes |
Which apparently isn't me because I've managed to get it entirely wrong. Just pushed some fixes. Some explanation about recent changes here |
just to confirm your staging branch setup => [envirornment] vitual box (ubuntu) | [install depends] sudo apt install binutils bzip2 diff find flex gawk gcc-6+ getopt grep install libc-dev libz-dev make4.1+ perl python3.6+ rsync subversion unzip which -y | [download source] git clone <stintel-4322052.tar.gz> | [package definitions] ./scripts/feeds update -a | [install symlinks] ./scripts/feeds install -a | [choose opts{docker,luci,usb3,usb chipsets etc, ex4}] make menuconfig | [compile] make => and then once image is installed to sd/usb we need to copy bin files to (/lib/firmware/brcm/) Does this about sum it up? |
https://openwrt.org/contact - I'm most active on IRC. Do not use the corporate contact. |
|
I will keep this thread alive. Any word yet? |
|
also waiting for this, any progress for this ? |
So you can copy the files in after build using a Linux VM or you can build image with a files folder and drop those in there and image tar will already have them. NOTE: I am un able to get pure access point mode to work with built in wifi still. Ended up adding a alfa awus036achm |
|
incidentally noticed this PR in upstream linux-firmware
@pelwell Isn't this a bit awkward as parts are supposedly different? (and sha512sum for https://github.com/RPi-Distro/firmware-nonfree/ .bin files are) |
|
We run Synaptics firmware on the Synaptics part and Infineon firmware on the Infineon part, but they both identify as 43430A1 and appear to be compatible. |
|
Thanks for feedback. So, are we saying:
and both are 43430 compatible (same as Pi3B & PizeroW) and could eventually be symlinked to that one? |
|
No - both 43436(P) and 43436S are from Synaptics. 43436 appears as 43430B0, and 43436S is 43430A1. The PR above is about the 43438/43436S distinction, where both appear as 43430A1. |
|
Would really help brcmfmac driver instantiates fully/clearly what firmware is required for what #5156 (comment) , particularly for those later 43436 devices. Thanks for those additional info: very tricky to sort-out and get detailed & clear view in one single place at once (like a table with Pi device, related wifi parts variants, related firmware files, eventual compat/link). |
|
Hmm, how I wish this wasn't complicated. It's the 1st time ever I have had to read something about License Agreements instead of just clicking NEXT :-) |
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=e9f9cd14cc71826957877999fd063dd080de4751 |
|
Just another hapless end user that'd like to build a project on RPiZ2 & OpenWRT without spinning up a distro image toolchain [and trying to figure out the licensing implications] here. @ossguy [as the SFC rep] can you offer direction to @stintel on how to proceed? @pelwell posted several responses related to your questions (without tagging you) and asked what still required clarification. Thanks! |
|
OpenWrt supports the RPi2 already. Just need to inject the firmware in the image. This documented in the commit message. I'm laying in the sofa right now doing a Terminator marathon so you'll have to find that commit yourself. |
|
@stintel no worries enjoy the show (T2 is epic)! I was more hoping @ossguy would chime-in so the Pi Zero 2w image could join those officially supported by OpenWRT and the firmware could be distribute through OpenWRT channels. I know you've done the work to support the arch in the OpenWRT snapshots and I'm grateful for it, however the hidden away / temporal nature of snapshots (cannot add new kmods next day when snapshot refreshes) and lack of support in firmware-selector make it a bit of a slog to use as a project base. For those with an established project if you want to use the Pi Zero 2 W's wifi w/ a snapshot build you'll need to do this on your running router hardware: |
|
Licensing of the Wi-Fi firmware is the contention. You get it, no?
…On Sun, Mar 12, 2023, 23:37 deftdawg ***@***.***> wrote:
@stintel <https://github.com/stintel> no worries enjoy the show (T2 is
epic)! I was more hoping @ossguy <https://github.com/ossguy> would
chime-in so the Pi Zero 2w image could join those officially supported by
OpenWRT and the firmware could be distribute through OpenWRT channels.
I know you've done the work to support the arch in the OpenWRT snapshots
<https://downloads.openwrt.org/snapshots/targets/bcm27xx/bcm2710/> and
I'm grateful for it, however the hidden away / temporal nature of snapshots
(cannot add new kmods next day when snapshot refreshes) and lack of support
in firmware-selector <https://firmware-selector.openwrt.org/> make it a
bit of a slog to use as a project base.
For those with an established project if you want to use the Pi Zero 2 W's
wifi w/ a snapshot build you'll need to do this on your running router
hardware:
mkdir -p /lib/firmware/brcm
cd /lib/firmware/brcm
mount -o rw,remount /
wget https://github.com/RPi-Distro/firmware-nonfree/raw/bullseye/debian/config/brcm80211/brcm/brcmfmac43436-sdio.bin
wget https://github.com/RPi-Distro/firmware-nonfree/raw/bullseye/debian/config/brcm80211/brcm/brcmfmac43436-sdio.txt
wget https://github.com/RPi-Distro/firmware-nonfree/raw/bullseye/debian/config/brcm80211/brcm/brcmfmac43436s-sdio.bin
wget https://github.com/RPi-Distro/firmware-nonfree/raw/bullseye/debian/config/brcm80211/brcm/brcmfmac43436s-sdio.txt
reboot
# wlan0 should now be available
—
Reply to this email directly, view it on GitHub
<#4723 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAGK4XUAAN5PRGV7XVH2UW3W3Y63JANCNFSM5IOJGFGQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Hey all. I noticed that since the discussion started the Synaptic licence was added to the rpi fw repo. I've decided to make a MR upstream: But we'll probably need some one from the RPi foundation/company to weigh in. To me the new licence looks good but I'm not a lawyer nor a relevant party here :) /cc @pelwell Thanks in advance for looking into it 🙇 |
|
You should at least give the licence file the correct company name - they are Synaptics, not Synaptic. |
If I understand correctly, 43436 has the same hardware and the same ID as 43430B0. And if I understand correctly there are two firmware Synaptics and Infineon for the same hardware 43436/43430B0 and two firmware for the same hardware 43436s/43430A1. Is that correct? I'm not sure what is the reason to keep 4 firmware for 2 pairs of hardware identical chips? |
and others
Describe the bug
The firmware required for the Raspberry Pi Zero 2 wireless chip should be published in linux-firmware.git so that distros can ship it without having to worry about being sued by whoever owns the IP.
The text was updated successfully, but these errors were encountered: