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/ -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
