Hi
On 2015-09-02, Rainer Dorsch wrote:
> Hi Stefan,
>
> I copied the debian-arm list, because this should be an issue which is present
> on almost any ARM based SoC and there might exist solutions for other SoCs
> already.
It's not really arm specific, as this particular SDIO based wlan chipset
is used on multiple architectures (including many windows 8.x based Intel
Atom tablets).
> On Wednesday 02 September 2015 19:37:13 Stefan Lippers-Hollmann wrote:
> > On 2015-09-02, Rainer Dorsch wrote:
[...]
> Are you saying that I opened the bugreport against the wrong package or that
> this is not a bug at all?
As far as I see it, this is not a /software/ bug and not actionable
from within Debian, the data blob in question can only be provided
by the OEM/ systems integrator manufacturing the devboard or the
vendor producing the wlan card in question (e.g. AMPAK for the AP6120
wlan/ BT daughterboard using the Broadcom BCM4329 SDIO chipset found
on many armhf devboards). It is calibration data for your particular
wlan card and not a generic firmware image.
At best (and this is pretty questionable as well) you could create a
dedicated firmware image providing brcmfmac4329-sdio.txt for each
particular devboard, conflicting with all other providers of this
file.
If I were the Debian maintainer for firmware-brcm80211, I'd see no
other option than to close this bug - likewise I don't think that it
can be re-assigned to any other package in Debian.
On more traditional PCI/ PCIe or USB wlan cards, this type of
calibration data is typically stored in a small EEPROM chip, together
with the device's MAC address, but in the embedded space, vendors try
to save the last cent and reuse other kinds of (independent) storage.
- on x86 Atom Baytrail-T tablets (many of which use this exact,
bcm4329, wlan chipset), this calibration data is usually stored in
the mainboard firmware (vulgo BIOS) and exposed to the Windows driver
as UEFI (nvram-) variable; brcmfmac does not look there on its own.
- on Atheros based (mips) routers, the calibration data usually goes
into a dedicated mtd partition of the main flash ("ART", aka Atheros
Radio Test), here it is unique (based on the OEM calibration) to each
specific router (or at least small batches of the production).
- on most armhf devices originally shipping with Android, it is usually
presented as firmware file shipped in the original Android system
partition (e.g. /system/etc/wifi/nvram_net.txt) and then used by the
bcmhd driver on Android, respectively its mainline counterpart and
successor brcmfmac via /lib/firmware/brcm/brcmfmac4329-sdio.txt.
you need to extract /system/etc/wifi/nvram_net.txt from your original
Android image and copy it to /lib/firmware/brcm/brcmfmac4329-sdio.txt
or ask the manufacturer of your board for it.
> Doesn't on an ARM system the device tree file contain embedded device specific
> information, which is shipped with the kernel itself? And would this txt file
> not fit perfectly in this category of information?
I'm not a specialist on device tree syntax, but I'd guess that it's a
bit too much information to be injected via DT.
> How is this issue addressed for other ARM SoCs?
Many ARM devboards go a simpler route, by simply using a USB based
daughterboard (which includes all these implementation details in an
EEPROM of the USB daughterboard itself). Android smartphones, which
are more likely to use SDIO based wlan cards (and bcmhd as its driver),
store it as /system/etc/wifi/nvram_net.txt and alternative firmwares
either need to take care of not overwriting it, or to ship it
themselves.
The few devboards using SDIO based BCM4329 wlan cards either provide
nvram_net.txt/ brcmfmac4329-sdio.txt somewhere (which is specific to
their particular device, respectively production batch) or punt the
task of extracting it from the original Android based firmware to the
user.
See the situation for x86 tablets and mips routers above.
Regards
Stefan Lippers-Hollmann
Attachment:
pgphqM74vDeTj.pgp
Description: Digitale Signatur von OpenPGP