Clarity over the LICENSE for the firmware required for Pi3 BT/WIFI

[clivem]

Can someone from PiF please clarify, the LICENSE that should accompany the files, brcmfmac43430-sdio.bin, brcmfmac43430-sdio.txt, and BCM43430A1.hcd? I need clarification on whether these files can even be re-distributed and under what license?

I have just been warned, by someone who appears to know what they are talking about, having implemented Broadcom chipsets on other SBC designs, (who is aware that I packaged these files in a rpm earlier this week), and whom I would prefer to remain nameless, that these files cannot be re-distributed, (unless the PiF have an alternative LICENSE with Broadcom), without express written permission from Broadcom?

As the included Pi3B wifi/BT isn't even usable without the firmware, can we please get these files being made available from PiF github, accompanied by the actual license, that should accompany them?

Or is it the case, that wifi/BT hardware can only be used with Raspbian/Ubuntu, as these are the only OS distributions that have permission to distribute/re-distribute the proprietary Broadcom binary firmware?

[Noltari]

I completely agree with @clivem.

I see two options:

1. Submit the firmware files to linux-firmware.
2. Provide the firmware files on raspberrypi/firmware repo.
   (Both of them with a proper license)

[clivem]

OK, I was hoping that one of the Pi people would be able to answer this question. Can someone with a pi email address, like @ghollingworth @pelwell or @popcornmix please tell me who I should contact at Pi towers to get clarification over the licensing of these Broadcom binaries, please? Would it be Serge Schneider? (He is mentioned in the RPI-Distro changelog in the same check-in as the wifi/bt firmware. He provided them??????)

[Noltari]

Any news on this matter?

[pelwell]

Disappointingly, I'm still waiting to hear back from Broadcom.

[Noltari]

Thanks for the heads up @pelwell

[pelwell]

Broadcom have said that the firmware files for the BCM43438 are covered under this licence: http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/LICENCE.broadcom_bcm43xx

[clivem]

Well, that's good news!!!!!

In that case, can you please make the binary files available from PiF firmware github accompanied by a copy of that license, and also can someone from Broadcom, (or you????), submit the firmware to linux-firmware git repo. At the point it uses an existing "accepted" license, there shouldn't be an issue with linux-firmware wanting to accept the firmware files, which is good, because it means that pretty much every linux distro will have those files included by default. That's a big WIN-WIN-WIN for trying to get more distros supporting the Pi.

[clivem]

@pelwell Phil, do you think there is any chance, if you ask nicely, that they will release 43438 datasheet to the unwashed masses? (I understand one currently has to sign NDA to get it.)

[pelwell]

No, that's not going to change because I ask for it.

[pelwell]

I think we have the requested clarity now. OK to close?

[Noltari]

@pelwell are there any plans to submit the firmware files to linux/firmware or raspberrypi/firmware?

[pelwell]

I have raised the matter with Broadcom.

[clivem]

@pelwell I think this should remain open, until the firmware is actually distributed with the LICENSE attached, whether that be via PiF firmware github, or linux-firmware. It should remain visible..... This is the only record of anyone saying what license these files should be distributed under. Closing it, removes it from easy view.

[Noltari]

@pelwell any news from Broadcom about submitting both wifi and bluetooth firmwares to linux-firmware?
Thanks in advance.

[pelwell]

Broadcom have been very quiet recently.

[Ruffio]

@clivem has your issue been resolved? If so, please close this issue. Thanks.

[clivem]

@pelwell Do you know if BRCM have any intention of submitting the firmware files to linux-firmware?

[pelwell]

They expressed an intention to look into it, but then Avago and Cypress happened.

[afaerber]

@pelwell Have you considered sending a linux-firmware.git pull request yourself, quoting who at Broadcom said what exactly? We don't have that info, just your comment above, so can't do it for you. If you need technical help, me and others would certainly be willing to assist you. Thanks!

[clivem]

For anyone else interested, Cypress Semiconductor have made the BCM43438 datasheet available online. You can download the pdf datasheet from http://www.cypress.com/file/298076/download

NB. Thanks to Karlheinz, who informed me about this.

[clivem]

Holy flippin moly.... How did I miss this..... About bloody time! It only took 6 months. LOL.
brcm: add firmware for BCM43430 802.11n chipset

[pelwell]

Interesting. Although I requested that the firmware be uploaded , I wasn't told that it was going to happen.

Although it seems to work, the upstreamed firmware is not identical to our shipping firmware - the version number is the same (7.45.41.26), but the upstreamed firmware is one byte longer (apparently because it was compiled in the CEST timezone), However, since that string is at the end of the firmware the majority of the bytes are identical - I can see two embedded timestamp strings that are different, and about 40 other bytes of unknown function, but I'd be surprised if there are any real code changes.

[clivem]

Although I requested that the firmware be uploaded , I wasn't told that it was going to happen.

Well, the sale of the division to Cypress seems to have resulted in positive things.... The release of a datasheet without NDA and the submission of the firmware to the linux-firmware repo....

and about 40 other bytes of unknown function, but I'd be surprised if there are any real code changes.

Regardless of whether you'd be surprised if there are any real code changes, we now have two firmware files, embedded with the same version number, but there are differences in those files. Really not helpful, IMHO! So now we cannot rely on someone telling us from dmesg that firmware version blah, blah, blah was loaded by the driver. We now need to ask them for the exact byte size of the file on the filesystem to determine which version of the same version firmware they are actually using, the upstream firmware or the downstream firmware, because although they are both the same version, there are differences. ;)

[clivem]

OK, we can identify which is which via FWID.

Downstream...
brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: May 27 2016 00:13:38 version 7.45.41.26 (r640327) FWID 01-df77e4a7
Upstream...
brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Aug 29 2016 20:48:16 version 7.45.41.26 (r640327) FWID 01-4527cfab

[pelwell]

Even starting from the same commit, with the same configuration, my kernel build will be different from yours - do you think we should start asking that issues are only reported against kernels built by us because, you know, they're different?

Until suspected otherwise I'm going to treat builds with the same version - "7.45.41.26 (r640327)" - as equivalent.

[clivem]

Even starting from the same commit, with the same configuration, my kernel build will be different from yours - do you think we should start asking that issues are only reported against kernels built by us because, you know, they're different?

The beauty of open source, is that I can see what those differences are, by looking at the source you built your kernel from and comparing to mine. This closed source binary firmware, I don't get to look at the source to figure out what the differences might be, between two files that imply to be equivalent with the same version number. ;)

[clivem]

I say it means what Phil or Dom think is going to cause them more grief
than they really want!

@JamesH65 I'm not sure what that actually means, in real world terms, that can be communicated to other people with the expectation that they might understand something more than they did before, from hearing it. (And no, I'm not taking the piss. What 'Dom and Phil think is going to cause them more grief' seems even more arbitrary than Phil talking about modifying the config in a way we consider "significant", without having defined what he considers to be significant.)

[P33M]

This discussion is becoming tedious.

There's a nominal level of support and, consequently, engineering time available for any particular issue. With a small set of people that can both evaluate kernel issues and propose fixes, this time is valuable.

We are at liberty to restrict our attention to issues related only to pre-packaged builds of this repository. This is an unnecessarily tight constraint, as there are significant numbers of Pi users out there that do not run our particular scripts with our particular compilers to produce binaries (LibreELEC users being one of those significant numbers). Thus it's self-defeating to refuse support for all binaries that are not direct products of this repository; as such we will attempt best-effort diagnosis of issues experienced with binaries produced by others. The ultimate decision on what constitutes "too much grief" is ours alone.

[JamesH65]

Sorry, it was an attempt to be humorous, with overtones of what P33M says!

On 29 September 2016 at 22:36, P33M notifications@github.com wrote:

This discussion is becoming tedious.

There's a nominal level of support and, consequently, engineering time
available for any particular issue. With a small set of people that can
both evaluate kernel issues and propose fixes, this time is valuable.

We are at liberty to restrict our attention to issues related only to
pre-packaged builds of this repository. This is an unnecessarily tight
constraint, as there are significant numbers of Pi users out there that do
not run our particular scripts with our particular compilers to produce
binaries (LibreELEC users being one of those significant numbers). Thus
it's self-defeating to refuse support for all binaries that are not direct
products of this repository; as such we will attempt best-effort diagnosis
of issues experienced with binaries produced by others. The ultimate
decision on what constitutes "too much grief" is ours alone.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#1325 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADqrHc-fit1A8Su5pJ2OYTPkEDEmb91_ks5qvC9CgaJpZM4HqJ8L
.

[JamesH65]

Closing this issue as questions answered/resolved.

[xulinsun]

I did find the binary file " brcmfmac43430-sdio.bin" in the upstream, but no "BCM43430A1.hcd" for BT of RPI 3. Per my understanding for BT feature the file "BCM43430A1.hcd" must be needed. So how about this BT file license? @clivem @pelwell
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=c4c07a8d1128d50a5c2885ceea1abbebaa82f820