From: Peter Seiderer <ps.report@gmx.net>
To: buildroot@busybox.net
Subject: [Buildroot] Buildroot: enable lib/firmware/brcm for rpi0w
Date: Mon, 29 Mar 2021 20:49:37 +0200 [thread overview]
Message-ID: <20210329204937.01bb10a6@gmx.net> (raw)
In-Reply-To: <0d1e250a62069d63923fccf305f9766d@umbiko.net>
Hello Andreas,
On Fri, 26 Mar 2021 12:47:21 +0000, Andreas Ziegler <br015@umbiko.net> wrote:
> Hello Peter,
>
> On 2021-03-25 21:20, Peter Seiderer wrote:
> >
> > Many thanks for doing the tests!
> >
>
> Not at all; after getting confused with different versions and
> repositories, I wanted to understand the reason behind this.
>
> Short summary of my findings; I may state the obvious here, but it was
> new for me and maybe it helps someone with the same hazy knowledge about
> hardware engineering as myself:
>
> Broadcom sold its RF division to Cypress in 2016. Cypress now supports
> the legacy wireless /bluetooth /radio hardware from Broadcom; that is
> the reason why BCM* and CYW* versions of firmware exist, and
> linux-firmware removed the original Broadcom supplied binaries.
>
> Cypress does not directly sell to end customers, but provides silicon to
> hardware partners (AzureWave, Murata, ...), which in turn sell RF
> solutions. Cypress distributes firmware for their silicon chips
> (probably to same hardware partners).
>
> End product is some type of SOC (subsystem on chip); the benefit is that
> tuning and regulatory issues have been taken care of. The SOC
> manufacturer is responsible for supplying bluetooth patch (HCD),
> regulatory data (CLM) and firmware configuration (TXT).
>
> That means the firmware binary (BIN) can be obtained from any source,
> the other items (HCD, CLM, TXT) need to be sourced from the implementer.
>
> >> The LibreELEC repository (rpi-wifi-firmware) seems to have adopted
> >> this
> >> version in commit 7dbd877545ae15069f2bd0e73893af942500e23d on Jan. 25.
> >
> > So a good reason to stay with LibreELEC (and fix the firmware package
> > to
> > provide raspberrypi,4-model-b.txt as a link or copy, do you know if
> > missing
> > it has some disadvantages or produces only the firmware load warning or
> > is
> > there a fallback to plain brcmfmac43455-sdio.txt?), keeping up with
> > RPi-Distro...
>
> Yes, also my opinion to stay with LibreELEC. The repository is small, is
> updated in a timely manner, and is (slightly) better documented than
> RPi-Distro.
>
> There is one thing (apart from providing the missing link) I would
> propose: merge rpi-bt-firmware and rpi-wifi-firmware into
> rpi-rf-firmware, combining the code from both .mk and Config.in files.
> Functionality would be identical, but one less firmware package. If
> anyone is interested, I could provide a patch.
+1 from my side...
>
> In recent kernels, firmware load tries board-specific path first, then
> falls back to firmware derived path [1]. If I remember correctly, in
> kernels < 5.0 the firmware load failed.
>
> >> There seem to be some bigger changes in the pipeline: linux-firmware
> >> removed the Broadcom redistributed binaries in January [4] for the
> >> 20210208 release; instead Cypress firmware should be used. The
> >> upstream
> >> repository for this firmware seems to be murata-wireless /
> >> cyw-fmac-fw [5]
> >>
> >> I need to look into this in detail at some other time ...
> >
> > Seems kind of (another) firmware mess...., different versions at
> > different
> > repositories...., all with the same name (instead of clear version
> > string)...
>
> There are at least three different versions available in Buildroot:
>
> (available in Buildroot, repo 'master' version listed respectively)
> libreELEC build 2021-01-04 version 7.45.229
> linux-firmware build 2020-09-18 version 7.45.221
> murata-wireless build 2020-09-18 version 7.45.221
> (not in buildroot)
> rpi-distro build 2021-01-04 version 7.45.229
>
> > Regards,
> > Peter
>
> Kind regards,
> Andreas
Thanks again for the detailed information (and testing)!
Did just sent out an patch adding the convenience firmware configuration
links for RPi3A+, RPi3B+ and RPi4B (see [2])...
Regards,
Peter
[2] https://patchwork.ozlabs.org/project/buildroot/patch/20210329184503.10514-1-ps.report at gmx.net/
>
> [1]
> https://elixir.bootlin.com/linux/v5.10.21/source/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c#L616
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
next prev parent reply other threads:[~2021-03-29 18:49 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.13.1616500803.19462.buildroot@busybox.net>
2021-03-24 6:37 ` [Buildroot] Buildroot: enable lib/firmware/brcm for rpi0w Andreas Ziegler
2021-03-24 22:27 ` Peter Seiderer
2021-03-25 9:45 ` Andreas Ziegler
2021-03-25 21:20 ` Peter Seiderer
2021-03-26 12:47 ` Andreas Ziegler
2021-03-29 18:49 ` Peter Seiderer [this message]
2021-03-30 8:20 ` Andreas Ziegler
2021-03-30 18:32 ` Peter Seiderer
2021-03-23 10:26 Laurentiu-Cristian Duca
2021-03-23 19:46 ` Peter Seiderer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210329204937.01bb10a6@gmx.net \
--to=ps.report@gmx.net \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox