At the moment. none - this device isn't supported yet (which shouldn't come as a surprise, considering that this device has only been available for 11 days).
Development happens on master, so that's where it will be merged first (and backports to 21.02 are unlikely).
--
No, OpenWrt doesn't have early access under NDA.
Yes, there are already early attempts to get this device working.
Thanks for the information SLH.
Kindly,
Chris
Thanks. Can't wait for its release.
I've been told I cannot add the bcm43436-firmware package due to licensing issues. Raspberry Pi foundation will have to submit it to linux-firmware.git before we can support the Raspberry Pi Zero 2 in OpenWrt. I have thus rejected the patch series and removed the rpizero2 branch from my staging tree.
Feel free to upvote https://github.com/raspberrypi/linux/issues/4723
Out of curiosity, which clause in https://github.com/RPi-Distro/firmware-nonfree/blob/bullseye/debian/config/brcm80211/LICENSE was specifically pointed out as objectionable vs. the restrictions in https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/LICENCE.broadcom_bcm43xx ? I can't see any discussion on your patchwork link
I've been in the process of trying to better support other variations on the Pi (obtaining the firmware blobs from https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/cypress instead of cypress-firmware which is ancient - in fact it looks like Cypress sold that division to Infineon and now you have to go to forum posts by Infineon?), and being able to pull in from RPi-Distro as an alternative would be highly beneficial.
The linux-firmware team has made it fairly explicit that board-specific clm_blob files won't ever be put in the repository ( https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/cypress?id=04f71fe564552c22dc7ece0d2b8afc11b33de392 ) which would mean that it would be ideal to fix any potential licensing issues with the RPi-Distro license, vs. require the files to be submitted to linux-firmware which will result in being forced to use generic clm_blob files.
I am assuming, however, that the firmware not being in linux-firmware is why the Pi foundation themselves haven't upstreamed http://lists.openwrt.org/pipermail/openwrt-devel/2021-November/037097.html - there's precedence for OpenWRT including non-upstreamed patches sourced from the Pi Foundation.
As a side note - https://github.com/raspberrypi/linux/commit/281498c24f49f6bd0725b163b2dfc78079dd2196#diff-ffce630590e253b5f402e964a1085c5709e56a2ba5e060579fe68cfd87988fe7 appears to solve country code issues with the Pi on OpenWRT.
https://github.com/RPi-Distro/firmware-nonfree is a fork, there is no guarantee that they comply with what is written in the README. Aside from that https://github.com/RPi-Distro/firmware-nonfree/commit/dcea7a3c12490f264033e489f8c6b56032d9f249 has no SoB.
It hasn't really been a fork since https://github.com/RPi-Distro/firmware-nonfree/commit/7402e8d1b9436e5ae8efb370dcb2e0476a453c7d - they added quite a bit of logic to differentiate upstream files from their own changes, including adding a license file specific to their own additions (which is the one that I linked).
You're saying that because it's a "fork" (and I use that term loosely because deleting every local copy of a file that is duplicated upstream really is not what I consider to be a fork...), that the license README that they themselves added specifically for the files they added which are not present upstream is not valid?
Also, could you please define SoB? Googling "SoB license" - well... let's just say that doesn't work and in fact you shouldn't do it from a corporate work environment...
Edit: signed-off-by????
I suspect that the Pi Foundation will not upstream binaries that are hardware-specific (such as the clm_blob files), nor will upstream accept such hardware-specific files. So ideally, it might be good to approach Phil and company to find a way to make the Pi-specific repo acceptable license-wise for OpenWRT - such as stating what you feel is missing license-wise?
https://github.com/iiab/iiab/issues/2853 makes it clear that one-size-fits-all firmware blobs for brcmfmac SDIO devices isn't something that can be achieved even for base firmware - and those tradeoffs affect OpenWRT too (optimization for client vs. AP usage...)
Edit 2: Would the most recent 43455 blobs be acceptable since these do have signed-off-by metadata in their commits? Obviously that doesn't help you, but it does help my use case. https://github.com/RPi-Distro/firmware-nonfree/commit/dc406650e840705957f8403efeacf71d2d7543b3
Someone, who is legally authorized to do this by the copyright holder, will have to sign off on those binaries and at least assist on their submission to the upstream linux-firmware.git.
It is pretty obvious that Phil Elwell is legally authorized by the copyright holder. His more recent commits have had the proper signed-off-by-metadata, and I am positive that the lack of that in older commits was an oversight on his and Serge's part.
For older commits, what is the proper process for "fixing" that oversight (which I am 90% certain is an oversight) - I'm willing to go forward with pursuing a request of this rectification avenue with Phil, since I've already asked him some questions regarding the rpi-distro blobs (as I was unaware of @stintel 's work when I was working on some issues I've been having with pi4). Note that I'm pretty sure that asking them to rebase their commits to fix the messages is not going to be taken kindly...
Upstreaming to linux-firmware is not an option for clm_blob files - linux_firmware makes it clear that they only accept generic (read: severely feature-reduced) files. For example, 80 MHz channels are supported by the Raspberry Pi using device-specific clm_blob files, but not generic worldwide clm_blob files. Even for non-clm_blob files - it's clear that there are tradeoffs for the base firmware files that could result in a technical (not legal) issue that is acceptable for Raspberry Pi targets, but not acceptable for a repository that tries to make things as generic as possible. (As an example, see the discussion I linked regarding tradeoff of firmware features vs. number of clients that can connect in AP mode.)
Also, as an observation, you're not likely to get traction by posting an issue against the wrong repo. https://github.com/RPi-Distro/firmware-nonfree/issues would be the correct place for a request to fix up/clarify firmware licensing questions (including missing signed-off-by metadata)
I can post an issue there, but it might be better if @stintel does since he's the one that specifically has an issue with the licensing documentation and did the bringup work?
It is still my opinion that asking them to upstream to linux-firmware won't work, given that the blobs in question have board-specific customizations and linux-firmware only accepts generic blobs - but hopefully they will be willing to address whatever licensing clarifications are required.
I disagree. There is nothing on https://github.com/RPi-Distro that refers to the Raspberry Pi Foundation, not even a link to the website. There is such a link on https://github.com/raspberrypi/. I therefore conclude RPi-Distro is a community effort and thus I doubt they are legally authorized to publish this firmware.
All commits to the Broadcom blobs part of that repo come from @raspberrypi.org email addresses
Phil Elwell is an engineer at the Raspberry Pi foundation and also senior forum moderator, and is the maintainer of anything related to wifi for that board. https://forums.raspberrypi.com/memberlist.php?mode=viewprofile&u=121689&sid=3b58951569add563b2bfd60d698359f3
When asked where to find a trackable repository that updated firmware can be obtained from, Phil pointed to that repo: https://forums.raspberrypi.com/viewtopic.php?t=291824&start=50#p1940763
Also see https://github.com/raspberrypi/linux/issues/1325#issuecomment-217358527 and https://github.com/RPi-Distro/firmware-nonfree/issues/1
It is clear that the position of the Raspberry Pi foundation is that it is Broadcom/Cypress' responsibility to submit to linux-firmware, not theirs. It's also clear that Phil Elwell is legally authorized to redistribute firmwares, otherwise he would have been fired years ago given how clearly visible his redistribution efforts are.
Again - what is the process for handling the oversight of prior commits missing the signed-off-by entry? Phil's team is being more careful about those now, but fixing the historical commits can't be done without rebasing their repo which it's pretty obvious they're not going to do.
Ask a lawyer.
I am asking YOU what will make YOU comfortable with that repo.
Again, I'm willing to spend some time pursuing improvements/clarifications regarding licensing of that repo by asking Phil for reasonable clarification/changes.
By "reasonable" I mean:
Edit: Also, by the way https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin specifically references open source work, so I suspect some might consider it to be not applicable to binary blobs published on a closed-source redistribution license. I was going to ask XECDesign to add signed-off-by tags, however I'm going to hold off on that - if you really want to enforce SoBs on someone else's repo (note that the SoB process is one developed for kernel contributions, that some other projects have adopted, but many haven't, it's not actually legally necessary. Google doesn't enforce that policy for Android commits, for example.)
Simple: confirmation by a lawyer that I can publish an OpenWrt package containing the Pi Zero 2 firmware. I am planning to contact SFC for assistance in this matter, but to be honest this entire mess is very demotivating so I haven't done that yet.
Join the club. It's demotivating to see this level of paranoia about something that clearly has a license file posted, by people who are clearly employees of an entity with redistribution rights, without pointing to a specific license clause you consider to be objectionable, problematic, or concerning.
It's also demotivating to see someone attempt to force their vision of how a repository should be run on others, given that, as I've already stated: Signed-off-by is not a legal requirement, and is something that many projects do not embrace.
I'm not the one who told me not to publish the firmware package. If I'd known in advance I wouldn't have wasted my time...
I'm not trying to force anything, it's just common practice in the Linux kernel and related projects.
I've tried to find the record of that rejection, the closest I can find is http://lists.openwrt.org/pipermail/openwrt-devel/2021-November/037106.html - none of your other commits seem to have any replies?
As I said, I'm willing to pursue stuff with Phil, but I need to know who I'm trying to satisfy. Personally I'd prefer to have whomever is specifically raising the objection communicate directly with Phil to work this out though.
My goals are not specific to the Pi Zero 2, but that repository is highly beneficial for all Pi devices for technical reasons - such as VHT80-capable clm_blobs - that "minimal" 43455 blob isn't useful for my application, but one could easily argue that it would be a sensible default for OpenWRT since a lot of people are probably running in AP mode.
I have a pile of local commits that I'm eventually going to upstream (need to pursue formal authorization with management and legal to submit stuff developed on company time), I really don't want to have the RPi-firmware repo also on the list.