Bug#797779: brcmfmac4330-sdio.txt from OpenElec fixes the issue
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
pgpPI4PWVduKq.pgp
Description: Digitale Signatur von OpenPGP
Bug#797779: brcmfmac4330-sdio.txt from OpenElec fixes the issue
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. On Wednesday 02 September 2015 19:37:13 Stefan Lippers-Hollmann wrote: > Hi > > On 2015-09-02, Rainer Dorsch wrote: > > Hi, > > > > I copied brcmfmac4330-sdio.txt from OpenElec > > > > https://github.com/OpenELEC/wlan-firmware/blob/master/firmware/brcm/brcmfm > > ac4330-sdio.txt > > > > to /lib/firmware/brcm > > > > which fixes the issue > > [...] > > brcmfmac4330-sdio.txt is OEM, respectively even device specific[1], > nothing that would be generic enough (for all bcm4330 devices) to be > shipped by Debian's firmware packages. > > On x86 systems this blob is typically provided in a UEFI variable (but not > found automatically by the kernel, so you need to copy it from the UEFI > variable to /lib/firmware). On embedded devices it needs to be provided by > the manufacturer (not Broadcom, but the OEM vendor) of your wlan card > (respectively the devboard). > > Regards > Stefan Lippers-Hollmann > > [1] These blobs contain calibration data, regulatory domain settings > and similar information, which is highly specific to your exact > device. Using data from a different device would make it run out > of its specifications (getting you in trouble with FCC, ETSI, > etc.) and could even physically damage your device. Are you saying that I opened the bugreport against the wrong package or that this is not a bug at all? 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? How is this issue addressed for other ARM SoCs? Thanks Rainer -- Rainer Dorsch http://bokomoko.de/
Bug#797779: brcmfmac4330-sdio.txt from OpenElec fixes the issue
Hi On 2015-09-02, Rainer Dorsch wrote: > Hi, > > I copied brcmfmac4330-sdio.txt from OpenElec > > https://github.com/OpenELEC/wlan-firmware/blob/master/firmware/brcm/brcmfmac4330-sdio.txt > > to /lib/firmware/brcm > > which fixes the issue [...] brcmfmac4330-sdio.txt is OEM, respectively even device specific[1], nothing that would be generic enough (for all bcm4330 devices) to be shipped by Debian's firmware packages. On x86 systems this blob is typically provided in a UEFI variable (but not found automatically by the kernel, so you need to copy it from the UEFI variable to /lib/firmware). On embedded devices it needs to be provided by the manufacturer (not Broadcom, but the OEM vendor) of your wlan card (respectively the devboard). Regards Stefan Lippers-Hollmann [1] These blobs contain calibration data, regulatory domain settings and similar information, which is highly specific to your exact device. Using data from a different device would make it run out of its specifications (getting you in trouble with FCC, ETSI, etc.) and could even physically damage your device. pgpB3yQFdQkGm.pgp Description: Digitale Signatur von OpenPGP
Bug#797779: brcmfmac4330-sdio.txt from OpenElec fixes the issue
Hi, I copied brcmfmac4330-sdio.txt from OpenElec https://github.com/OpenELEC/wlan-firmware/blob/master/firmware/brcm/brcmfmac4330-sdio.txt to /lib/firmware/brcm which fixes the issue rd@home:~$ dmesg |grep brcm [2.092917] brcm_reg: disabling [6.786725] usbcore: registered new interface driver brcmfmac [6.846286] brcmfmac_sdio mmc0:0001:1: firmware: direct-loading firmware brcm/brcmfmac4330-sdio.bin [6.879810] brcmfmac_sdio mmc0:0001:1: firmware: direct-loading firmware brcm/brcmfmac4330-sdio.txt [7.225901] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Oct 25 2011 19:34:12 version 5.90.125.104 [7.258702] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code [ 11.484505] brcmfmac: brcmf_add_if: ERROR: netdev:wlan0 already exists [ 11.491109] brcmfmac: brcmf_add_if: ignore IF event rd@home:~$ /sbin/ifconfig -a eth1 Link encap:Ethernet Hardware Adresse d0:63:b4:00:2b:ac inet Adresse:192.168.178.29 Bcast:192.168.178.255 Maske:255.255.255.0 inet6-Adresse: fd00::d263:b4ff:fe00:2bac/64 Gültigkeitsbereich:Global inet6-Adresse: fe80::d263:b4ff:fe00:2bac/64 Gültigkeitsbereich:Verbindung UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1 RX packets:6800 errors:0 dropped:0 overruns:0 frame:0 TX packets:5344 errors:0 dropped:0 overruns:0 carrier:0 Kollisionen:0 Sendewarteschlangenlänge:1000 RX bytes:1065692 (1.0 MiB) TX bytes:5224223 (4.9 MiB) loLink encap:Lokale Schleife inet Adresse:127.0.0.1 Maske:255.0.0.0 inet6-Adresse: ::1/128 Gültigkeitsbereich:Maschine UP LOOPBACK RUNNING MTU:65536 Metrik:1 RX packets:56 errors:0 dropped:0 overruns:0 frame:0 TX packets:56 errors:0 dropped:0 overruns:0 carrier:0 Kollisionen:0 Sendewarteschlangenlänge:0 RX bytes:5946 (5.8 KiB) TX bytes:5946 (5.8 KiB) wlan0 Link encap:Ethernet Hardware Adresse b8:5a:f7:82:aa:c2 UP BROADCAST MULTICAST MTU:1500 Metrik:1 RX packets:490 errors:0 dropped:490 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 Kollisionen:0 Sendewarteschlangenlänge:1000 RX bytes:233292 (227.8 KiB) TX bytes:0 (0.0 B) rd@home:~$ Thanks, Rainer -- Rainer Dorsch http://bokomoko.de/
