Linux: 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]

do you think we should start asking that issues are only reported against kernels built by us because

LOL. You mean you don't already? LOL.

[pelwell]

"LOL." Put up or shut up. "LOL."

[clivem]

Put up or shut up.

Not sure I understand, you want me to go searching for issues where you or @popcornmix have pointed out that it isn't an issue with a kernel built/supplied by you and they need to take it up with the people that did build/supply that kernel, whether that be Arch or another distro?

[pelwell]

That's right - one built from the same commit and with the same config options. Off you go.

[clivem]

That's right - one built from the same commit and with the same config options.

Oh, I see. Well, I suspect all the 3rd party builders are not using your config totally unaltered.

[pelwell]

And if they modify the config in a way we consider significant then we reserve the right to not put effort into fixing a problem that doesn't exist with the standard configuration.

[clivem]

And if they modify the config in a way we consider significant then we reserve the right to not put effort into fixing a problem that doesn't exist with the standard configuration.

Phil, if I were you, I'd be reserving the right not to put any effort into investigating anything, that wasn't actually built by you! FULL STOP!!! I've had my fair share of running around in ever decreasing circles trying to understand issues, even when the config and commit was the same, but the tool-chain used to build it differed. Or in once case, an idiot with an insanely overclocked machine, (to "speed up the build"), where everything else was the same, commit, config, tool chain..... and what otherwise appeared to be a successful build, resulting in corrupted binaries that were built on that overclocked machine, seg-faulting at runtime.

[pelwell]

But that's not how we roll...

[clivem]

Doesn't matter to me, one way or the other. I will communicate what you have said in these last few comments to the distros I "associate with"/help, about how their users can expect more support from you as an upstream, if they stick as close as possible to your default config and avoid changing it in ways you might consider "significant". (Although I'm not sure what that actually means in real terms.)

[JamesH65]

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

On 29 September 2016 at 15:32, Clive Messer [email protected]
wrote:

Doesn't matter to me, one way or the other. I will communicate what you
have said in these last few comments to the distros I "associate
with"/help, about how there users can expect more support from you as an
upstream, if they stick as close as possible to your default config and
avoid changing it in ways you might consider "significant". (Although I'm
not sure what that actually means in real terms.)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/raspberrypi/linux/issues/1325#issuecomment-250483687,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADqrHQ3sg7SoGyRAwFYgx3AgNqbYiCQXks5qu8wGgaJpZM4HqJ8L
.

[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 [email protected] 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
https://github.com/raspberrypi/linux/issues/1325#issuecomment-250598313,
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