Merge firmware 20200601 from raspbian

It seems the 5.4 kernel wants another clm_blob on the 3B:

[ 11.240310] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1
[ 11.261578] usbcore: registered new interface driver brcmfmac
[ 11.491296] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1
[ 11.502875] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
[ 11.519522] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43430/1 wl0: Oct 23 2017 03:55:53 version 7.45.98.38 (r674442 CY) FWID 01-e58d219f

Aren't you pulling the firmware blobs from https://github.com/RPi-Distro/bluez-firmware and https://github.com/RPi-Distro/firmware-nonfree?

I think there are things pulled from there, but applied as base64 encoded patches, which might make better sense to be packaged as multi orig tarball.

> It seems the 5.4 kernel wants another clm_blob on the 3B
...

Yup, this is as it is on Raspbian (i.e. on Raspbian you also get that warning on the 3B because it's the only Pi we support that uses the BCM43430).

> Aren't you pulling the firmware blobs from https://github.com/RPi-Distro/bluez-firmware and https://github.com/RPi-Distro/firmware-nonfree?

firmware-nonfree is definitely where we get the wifi firmwares from (Dimitri's just told me about multi-tarball packages which I shall now go read up on and fix the horrid b64 encoded mess we've currently got :), and yes bluez-firmware is indeed the source of the bt firmware (same story there).

Per Phil, the pi-specific bcm43430 firmware contains a built-in clm_blob but the driver doesn't know that and tries to load it. There's no easy way to fix the driver to figure that out so I guess we have to live with that warning.

Sponsored for groovy.