From: Samuel Ortiz <sameo@linux.intel.com>
To: Arend van Spriel <arend@broadcom.com>
Cc: Bernd Wagener <Bernd.Wagener@Uni-Oldenburg.DE>,
Linux Wireless <linux-wireless@vger.kernel.org>,
frankyl@broadcom.com
Subject: Re: brcmfmac NVRAM files
Date: Wed, 5 Mar 2014 03:31:51 +0100 [thread overview]
Message-ID: <20140305023151.GG17664@zurbaran> (raw)
In-Reply-To: <53032EAB.5070905@broadcom.com>
Hi Arend,
On Tue, Feb 18, 2014 at 10:58:03AM +0100, Arend van Spriel wrote:
> I certainly hope you misread that. Before 3.13 the driver always look
> for brcmfmac-sdio.bin and brcmfmac-sdio.txt regardless the device being
> used. That has changed so the firmware file now includes the chip id and
> for some even the revision, eg. brcmfmac43241b4-sdio.bin and
> brcmfmac43241b4-sdio.txt. The nvram file has a totally different format
> as the bin file so copying will fail for sure.
So I finally found this NVRAM file, hidden somewhere in an EFI variable
(Thanks for the hint).
I have 2 questions for you:
- How can I tell if the target properly loaded this NVRAM file ? Is
checking for wlan0's MAC to match the NVRAM MAC a good way to verify
that ?
- I'm running this on an Asus T100 (x86 tablet). This is a BCM94324A1
over SDIO and I run wireless-next there (With your very latest
brcmfmac changes). I see the driver is quite unreliable, for example
scan times out most of the time as the driver puts the target to sleep
while it's in the middle of receiving partial scan results. I had to
increase BRCMF_WD_POLL_MS to 100ms to actually get scan results. Then
the driver seems to be having a hard time joining the couple of WPA
APs that I tested it against.
Am I missing something or are those instabilities to be expected with
the latest brcmfmac code ? Please let me know if you need debug logs,
I'll happily provide them.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
next prev parent reply other threads:[~2014-03-05 2:31 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-17 15:06 brcmfmac NVRAM files Samuel Ortiz
2014-02-17 16:33 ` Samuel Ortiz
2014-02-17 16:52 ` Bernd Wagener
2014-02-17 17:37 ` Arend van Spriel
2014-02-17 17:38 ` Arend van Spriel
2014-02-17 18:00 ` Samuel Ortiz
2014-02-17 18:27 ` Bernd Wagener
2014-02-18 9:58 ` Arend van Spriel
2014-03-05 2:31 ` Samuel Ortiz [this message]
2014-03-05 9:04 ` Arend van Spriel
2014-03-05 10:24 ` Samuel Ortiz
2014-03-05 16:15 ` Arend van Spriel
2014-03-05 16:50 ` Samuel Ortiz
2014-03-07 8:26 ` Arend van Spriel
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=20140305023151.GG17664@zurbaran \
--to=sameo@linux.intel.com \
--cc=Bernd.Wagener@Uni-Oldenburg.DE \
--cc=arend@broadcom.com \
--cc=frankyl@broadcom.com \
--cc=linux-wireless@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).