Open stintel opened 3 years ago
Can you please share your patches with me. I am happy to test them. They don't need to include firmware. Thanks.
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 They are in that public location on the expectation that others will download and use them in their own distributions. There are already LICENCE files from Broadcom and Cypress, although they don't appear to be in the Bullseye branch yet - see https://github.com/RPi-Distro/firmware-nonfree/blob/buster/LICENCE.broadcom_bcm43xx and https://github.com/RPi-Distro/firmware-nonfree/blob/buster/LICENCE.cypress
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. BT is still missing for unknown reasons. Hope Synaptics will do their part upstream too...
Please +1!
This is important! Please expedite it :) thanks!
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 They are in that public location on the expectation that others will download and use them in their own distributions.
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.
but all our firmware suppliers understand that the firmware they supply us will be distributed freely.
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: Would such a link from the official RPi website/repo to that RPi-Distro user/repo already be sufficient to have the firmware(s) used over at the OpenWRT project?
@JamesH65: Sorry for mixing up the foundation and the Limited. Thanks for taking this up into discussion. IMHO it's better to have this more transparent especially with regards to compliance and legal topics. Even the https://github.com/raspberrypi account is only implicitely linked from the RPi website (throughout the RPi documentation and mentioned on the licensing page.
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?
@stintel: Would such a link from the official RPi website/repo to that RPi-Distro user/repo already be sufficient to have the firmware(s) used over at the OpenWRT project?
At this point I'm waiting for advice from the SFC.
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.
@stintel: Would such a link from the official RPi website/repo to that RPi-Distro user/repo already be sufficient to have the firmware(s) used over at the OpenWRT project?
At this point I'm waiting for advice from the SFC.
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 https://github.com/RPi-Distro/firmware-nonfree/commit/dcea7a3c12490f264033e489f8c6b56032d9f249 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 LICENSE
file only mentions Broadcom and not Cypress.
@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 https://github.com/RPi-Distro/firmware-nonfree/commit/dcea7a3c12490f264033e489f8c6b56032d9f249 (by @XECDesign ) and the more recent update by @pelwell at https://github.com/RPi-Distro/firmware-nonfree/commit/fdaf74c780ca7a29b12d62e5b0d37c38c2321e20 - 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 WHENCE
file was made in https://github.com/RPi-Distro/firmware-nonfree/commit/dcea7a3c12490f264033e489f8c6b56032d9f249 - according to https://github.com/RPi-Distro/firmware-nonfree/blob/dcea7a3c12490f264033e489f8c6b56032d9f249/debian/README.source there should be some mention of it, to be sure people know what license is being used:
The upstream source includes the file 'WHENCE' which lists the licence and any source code for each file. The script 'debian/bin/check_upstream.py' will warn about any files that aren't recognised to be distributable based on the information in 'WHENCE' and that haven't been excluded.
Is there some exclusion being made for this Cypress CYW43436-SDIO firmware file? If so, why? If not, where can I find the WHENCE
entry that explains which license is being used?
Note also that neither https://github.com/RPi-Distro/firmware-nonfree/commit/dcea7a3c12490f264033e489f8c6b56032d9f249 nor https://github.com/RPi-Distro/firmware-nonfree/commit/fdaf74c780ca7a29b12d62e5b0d37c38c2321e20 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 brcmfmac43436-sdio.bin
, brcmfmac43436-sdio.clm_blob
, and brcmfmac43436-sdio.txt
files are under. Thanks!
I can see light at the end of the tunnel
https://github.com/RPi-Distro/firmware-nonfree/commit/4db8c5d80daf2220d7824cfa6052f0bb108612ea
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 can see light at the end of the tunnel RPi-Distro/firmware-nonfree@4db8c5d
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 File hierarchy makes license applicable confusing Who do i gotta send these pi3 to in order to get openwrt with wifi image on rpi zero2??? Lolz
@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?
@stintel can you provide an update to this thread on what all is still pending for them to commit your merge
Like I said in https://github.com/raspberrypi/linux/issues/4723#issuecomment-1025142237, 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).
Aside from that, my device wants brcmfmac43436-sdio.bin
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? Which Synaptics chip variant needs which files (includind .txt), and their expected default names. It would help understand the magic behind debian/firmware-brcm80211.postinst
This will greatly help maintainers of non-debian-based distributions on how to make those files available, naming requirements, and eventual needs for symlinks. Thanks a lot for your help.
can you please elaborate on the difference between 43436f and 43436s files, and symlink requirements to plain 43436?
@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 brcmfmac43436-sdio.*
and the other brcmfmac43436s-sdio.*
. The brcmfmac driver, in conjunction with the .dtb
file, loads the correct version for the board based on the SDIO device ID. There is no need for symbolic links or clever installation scripts - that's your department.
Somebody who is experienced enough to maintain a distro shouldn't have issues here.
Which apparently isn't me because I've managed to get it entirely wrong. Just pushed some fixes.
Some explanation about recent changes here
@stintel can you provide an update to this thread on what all is still pending for them to commit your merge
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).
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
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
| [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? I would appreciate testing and feedback (but not here, as that's very much off-topic).
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 ?
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
brcm: add symlink for Pi Zero 2 W NVRAM file The Raspberry Pi Zero 2 W comes with two possible WiFi modules. One of them is the same module as shipped in the original Raspberry Pi 3B and Zero W so lets link them so the devices with that module will work out of the box.
@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 https://github.com/raspberrypi/linux/issues/5156#issuecomment-1238119302 , 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 :-) If I was supposed to be reading all those License Agreements, I wouldn't be using computers - just plain old paper! I bought 4 Pi Zero 2Ws and intended to use them as WiFi routers with OpenWrt. I even bought those kits from Amazon to help me have a great casing. I had to come and read this saga here because I am unable to install OpenWrt because of the firmware licensing saga. @ossguy @stintel - how far are we before we get Pi Zero 2W support? @pelwell will this ever be resolved before covid-22?
@ossguy @stintel - how far are we before we get Pi Zero 2W support?
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:
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
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.