Hi Arend,
I'm trying to use a 43241 SDIO chip here, and it fails asking for the
.txt file (brcmfmac43241b4-sdio.txt). This seems to be an NVRAM map
file, but I could not find either a template on linux-firmware or any
kind of documentation about it.
How do distro handle that ? Are they expected to build their own, or is
it completely OEM pecific ?
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
On Mon, Feb 17, 2014 at 04:06:40PM +0100, Samuel Ortiz wrote:
> Hi Arend,
>
> I'm trying to use a 43241 SDIO chip here, and it fails asking for the
> .txt file (brcmfmac43241b4-sdio.txt). This seems to be an NVRAM map
> file, but I could not find either a template on linux-firmware or any
> kind of documentation about it.
>
> How do distro handle that ? Are they expected to build their own, or is
> it completely OEM pecific ?
Adding Franky to the Cc list.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
Am 17.02.2014 17:33, schrieb Samuel Ortiz:
> On Mon, Feb 17, 2014 at 04:06:40PM +0100, Samuel Ortiz wrote:
>> Hi Arend,
>>
>> I'm trying to use a 43241 SDIO chip here, and it fails asking for the
>> .txt file (brcmfmac43241b4-sdio.txt). This seems to be an NVRAM map
>> file, but I could not find either a template on linux-firmware or any
>> kind of documentation about it.
>>
>> How do distro handle that ? Are they expected to build their own, or is
>> it completely OEM pecific ?
> Adding Franky to the Cc list.
>
> Cheers,
> Samuel.
>
Hi Samuel,
I had the same proble with a wandboard here and I guess it's a bug. In
/lib/firmware/brcm are all reqired *.bin files, but no *.txt file. On
http://www.wandboard.or I found a SDK-Kit with brcmfmac4329-sdio.txt, copied
the file and then the wlan was running.
The *.txt are simply forgotten to copy to the firmware directory.
No idea how to fix this.
Bernd
Hi Arend,
On Mon, Feb 17, 2014 at 06:37:33PM +0100, Arend van Spriel wrote:
> Hi Bernd,
>
> The hint to solve this is found on wireless.kernel.org [1] and the
> answer is as Samuel suspects. This file is very board specific so
> OEMs manufacturing/selling the board should provide it either upon
> request or through some distribution like a SDK.
There are several Win8 2-in-1 devices that do run the SDIO Full MAC
chipsets and obviously there is no SDK for those. Which means no distro
will ever be able to run out of the box on those.
I may be completely off the mark here, but isn't there a sensible
template for those guys ? Nothing optimised, but just something that
would at least make things work...
Also, the hint for pre 3.13 kernel is to copy the .bin into a .txt. Is
that still the case for post 3.13 ?
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
On 02/17/14 17:52, Bernd Wagener wrote:
> Am 17.02.2014 17:33, schrieb Samuel Ortiz:
>> On Mon, Feb 17, 2014 at 04:06:40PM +0100, Samuel Ortiz wrote:
>>> Hi Arend,
>>>
>>> I'm trying to use a 43241 SDIO chip here, and it fails asking for the
>>> .txt file (brcmfmac43241b4-sdio.txt). This seems to be an NVRAM map
>>> file, but I could not find either a template on linux-firmware or any
>>> kind of documentation about it.
>>>
>>> How do distro handle that ? Are they expected to build their own, or is
>>> it completely OEM pecific ?
>> Adding Franky to the Cc list.
>>
>> Cheers,
>> Samuel.
>>
> Hi Samuel,
> I had the same proble with a wandboard here and I guess it's a bug. In
> /lib/firmware/brcm are all reqired *.bin files, but no *.txt file. On
> http://www.wandboard.or I found a SDK-Kit with brcmfmac4329-sdio.txt, copied
> the file and then the wlan was running.
> The *.txt are simply forgotten to copy to the firmware directory.
> No idea how to fix this.
Hi Bernd,
The hint to solve this is found on wireless.kernel.org [1] and the
answer is as Samuel suspects. This file is very board specific so OEMs
manufacturing/selling the board should provide it either upon request or
through some distribution like a SDK. Because of the nature of the file
we do not put it on linux-firmware although people like yourself can get
lucky trying ;-)
Regards,
Arend
Am 17.02.2014 19:00, schrieb Samuel Ortiz:
> Hi Arend,
>
> On Mon, Feb 17, 2014 at 06:37:33PM +0100, Arend van Spriel wrote:
>> Hi Bernd,
>>
>> The hint to solve this is found on wireless.kernel.org [1] and the
>> answer is as Samuel suspects. This file is very board specific so
>> OEMs manufacturing/selling the board should provide it either upon
>> request or through some distribution like a SDK.
> There are several Win8 2-in-1 devices that do run the SDIO Full MAC
> chipsets and obviously there is no SDK for those. Which means no distro
> will ever be able to run out of the box on those.
> I may be completely off the mark here, but isn't there a sensible
> template for those guys ? Nothing optimised, but just something that
> would at least make things work...
>
> Also, the hint for pre 3.13 kernel is to copy the .bin into a .txt. Is
> that still the case for post 3.13 ?
>
> Cheers,
> Samuel.
>
No, thats wrong. You need a special board-specific *.txt file and rename
it for kernels > 3.12 to brcmfmacxxxx-sdio.txt.
Bernd
On 02/17/2014 07:00 PM, Samuel Ortiz wrote:
> Hi Arend,
>
> On Mon, Feb 17, 2014 at 06:37:33PM +0100, Arend van Spriel wrote:
>> Hi Bernd,
>>
>> The hint to solve this is found on wireless.kernel.org [1] and the
>> answer is as Samuel suspects. This file is very board specific so
>> OEMs manufacturing/selling the board should provide it either upon
>> request or through some distribution like a SDK.
> There are several Win8 2-in-1 devices that do run the SDIO Full MAC
> chipsets and obviously there is no SDK for those. Which means no distro
> will ever be able to run out of the box on those.
> I may be completely off the mark here, but isn't there a sensible
> template for those guys ? Nothing optimised, but just something that
> would at least make things work...
Last time I got the question I extracted the nvram from the windows
driver installer archive. However, it may end up in (U)EFI variable
space. Guess that could be accessed from Linux as well. Anyway, it may
be an area where we can and maybe should improve. I will discuss this
with Franky and the rest of the team over here.
> Also, the hint for pre 3.13 kernel is to copy the .bin into a .txt. Is
> that still the case for post 3.13 ?
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.
Regards,
Arend
On 02/17/14 18:37, Arend van Spriel wrote:
> On 02/17/14 17:52, Bernd Wagener wrote:
>> Am 17.02.2014 17:33, schrieb Samuel Ortiz:
>>> On Mon, Feb 17, 2014 at 04:06:40PM +0100, Samuel Ortiz wrote:
>>>> Hi Arend,
>>>>
>>>> I'm trying to use a 43241 SDIO chip here, and it fails asking for the
>>>> .txt file (brcmfmac43241b4-sdio.txt). This seems to be an NVRAM map
>>>> file, but I could not find either a template on linux-firmware or any
>>>> kind of documentation about it.
>>>>
>>>> How do distro handle that ? Are they expected to build their own, or is
>>>> it completely OEM pecific ?
>>> Adding Franky to the Cc list.
>>>
>>> Cheers,
>>> Samuel.
>>>
>> Hi Samuel,
>> I had the same proble with a wandboard here and I guess it's a bug. In
>> /lib/firmware/brcm are all reqired *.bin files, but no *.txt file. On
>> http://www.wandboard.or I found a SDK-Kit with brcmfmac4329-sdio.txt, copied
>> the file and then the wlan was running.
>> The *.txt are simply forgotten to copy to the firmware directory.
>> No idea how to fix this.
>
> Hi Bernd,
>
> The hint to solve this is found on wireless.kernel.org [1] and the
> answer is as Samuel suspects. This file is very board specific so OEMs
> manufacturing/selling the board should provide it either upon request or
> through some distribution like a SDK. Because of the nature of the file
> we do not put it on linux-firmware although people like yourself can get
> lucky trying ;-)
forgot:
[1] http://wireless.kernel.org/en/users/Drivers/brcm80211
> Regards,
> Arend
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On 03/05/14 11:24, Samuel Ortiz wrote:
> I'm attaching the log corresponding to a modprobe brcmfmac debug=0x31416
> && ifconfig wlan0 up sequence.
> I have modified this in the driver, to make it less aggressive about
> SDIO sleeps:
>
> sdio_host.h:
> #define BRCMF_WD_POLL_MS 200
>
> dhd_sdio.c:
> #define BRCMF_IDLE_INTERVAL 20
So this log looks fine, because due to the changes above it never goes
to sleep. The log actually show it is a backport, right?
>> > I also have 2 question for you;-)
> Sorry if I sounded a bit rude, I didn't mean it :-/
I did not take it as rude so no worries.
>> > - what mmc host controller is used?
> So this is sdhci-acpi.
>
>> > - do you have CONFIG_RUNTIME_PM enabled?
> CONFIG_PM_RUNTIME is enabled, yes. Do you want me to test with it
> disabled ?
>
I am asking because Russell King recently discovered that SDHCI based
host controller drivers disable the SDIO interrupt. This would explain
the timeout on the scan as the scan results are events from the device
that require this interrupt. Even with your patches this may still
happen. You can probably disable it for the host controller through sysfs.
Regards,
Arend
On 03/05/2014 05:50 PM, Samuel Ortiz wrote:
> On Wed, Mar 05, 2014 at 05:15:27PM +0100, Arend van Spriel wrote:
>> On 03/05/14 11:24, Samuel Ortiz wrote:
>>> I'm attaching the log corresponding to a modprobe brcmfmac debug=0x31416
>>> && ifconfig wlan0 up sequence.
>>> I have modified this in the driver, to make it less aggressive about
>>> SDIO sleeps:
>>>
>>> sdio_host.h:
>>> #define BRCMF_WD_POLL_MS 200
>>>
>>> dhd_sdio.c:
>>> #define BRCMF_IDLE_INTERVAL 20
>>
>> So this log looks fine, because due to the changes above it never
>> goes to sleep. The log actually show it is a backport, right?
> That's correct, yes.
>
>
>>>>> I also have 2 question for you;-)
>>> Sorry if I sounded a bit rude, I didn't mean it :-/
>>
>> I did not take it as rude so no worries.
>>
>>>>> - what mmc host controller is used?
>>> So this is sdhci-acpi.
>>>
>>>>> - do you have CONFIG_RUNTIME_PM enabled?
>>> CONFIG_PM_RUNTIME is enabled, yes. Do you want me to test with it
>>> disabled ?
>>>
>>
>> I am asking because Russell King recently discovered that SDHCI
>> based host controller drivers disable the SDIO interrupt.
> You mean they do so from their runtime_suspend hook ?
> I see the thread now:
>
> http://www.spinics.net/lists/arm-kernel/msg308757.html
>
> It seems those patches have not been reviewed nor merged...
> I'll watch that thread closely ;)
>
>> This would
>> explain the timeout on the scan as the scan results are events from
>> the device that require this interrupt. Even with your patches this
>> may still happen. You can probably disable it for the host
>> controller through sysfs.
> I did so, and things seem to be more stable. The throughput is a lot
> better. Better is expected but 20x better is something else.
> I still get fairly weak signal, typically -75 dBm for APs that are a few
> meters away. Does that sound like reasonable values to you ?
Depending on the definition of a few meters and whether there is a
concrete wall in between, I tend to say -75 dBm is crap. Up to 10 meters
(without aforementioned wall) I would expect something around -40 dBm.
Regards,
Arend
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/
On 03/05/2014 03:31 AM, Samuel Ortiz wrote:
> 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).
That is actually the first occurrence of EFI I have come across in the
wild, but I mentioned it as I caught up that this was considered for
Win8(.1).
> 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 ?
Actually, the MAC address in NVRAM should be a backup value. The device
should have a MAC address programmed in OTP on the device itself. The
driver itself reads back the NVRAM to assure it is properly loaded.
> - 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.
Great. Please send me a log with module parameter 'debug=0x31416' of the
driver probe sequence.
I also have 2 question for you ;-)
- what mmc host controller is used?
- do you have CONFIG_RUNTIME_PM enabled?
Gr. AvS
On Wed, Mar 05, 2014 at 05:15:27PM +0100, Arend van Spriel wrote:
> On 03/05/14 11:24, Samuel Ortiz wrote:
> >I'm attaching the log corresponding to a modprobe brcmfmac debug=0x31416
> >&& ifconfig wlan0 up sequence.
> >I have modified this in the driver, to make it less aggressive about
> >SDIO sleeps:
> >
> >sdio_host.h:
> >#define BRCMF_WD_POLL_MS 200
> >
> >dhd_sdio.c:
> >#define BRCMF_IDLE_INTERVAL 20
>
> So this log looks fine, because due to the changes above it never
> goes to sleep. The log actually show it is a backport, right?
That's correct, yes.
> >>> I also have 2 question for you;-)
> >Sorry if I sounded a bit rude, I didn't mean it :-/
>
> I did not take it as rude so no worries.
>
> >>> - what mmc host controller is used?
> >So this is sdhci-acpi.
> >
> >>> - do you have CONFIG_RUNTIME_PM enabled?
> >CONFIG_PM_RUNTIME is enabled, yes. Do you want me to test with it
> >disabled ?
> >
>
> I am asking because Russell King recently discovered that SDHCI
> based host controller drivers disable the SDIO interrupt.
You mean they do so from their runtime_suspend hook ?
I see the thread now:
http://www.spinics.net/lists/arm-kernel/msg308757.html
It seems those patches have not been reviewed nor merged...
I'll watch that thread closely ;)
> This would
> explain the timeout on the scan as the scan results are events from
> the device that require this interrupt. Even with your patches this
> may still happen. You can probably disable it for the host
> controller through sysfs.
I did so, and things seem to be more stable. The throughput is a lot
better. Better is expected but 20x better is something else.
I still get fairly weak signal, typically -75 dBm for APs that are a few
meters away. Does that sound like reasonable values to you ?
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
Hi Arend,
Thanks for your answers.
On Wed, Mar 05, 2014 at 10:04:13AM +0100, Arend van Spriel wrote:
> > So I finally found this NVRAM file, hidden somewhere in an EFI variable
> > (Thanks for the hint).
>
> That is actually the first occurrence of EFI I have come across in the
> wild, but I mentioned it as I caught up that this was considered for
> Win8(.1).
Yes, this device came with Win8 installed.
> > 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 ?
>
> Actually, the MAC address in NVRAM should be a backup value. The device
> should have a MAC address programmed in OTP on the device itself. The
> driver itself reads back the NVRAM to assure it is properly loaded.
I'm asking this because when fetching the NVRAM file from UEFI, I
eventually noticed the 4 first bytes were garbage. I'm not sure how the
target will react to that, so I was looking for a way to verify that the
NVRAM was parsed and processed properly on the target side.
> > - 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.
>
> Great. Please send me a log with module parameter 'debug=0x31416' of the
> driver probe sequence.
I'm attaching the log corresponding to a modprobe brcmfmac debug=0x31416
&& ifconfig wlan0 up sequence.
I have modified this in the driver, to make it less aggressive about
SDIO sleeps:
sdio_host.h:
#define BRCMF_WD_POLL_MS 200
dhd_sdio.c:
#define BRCMF_IDLE_INTERVAL 20
> I also have 2 question for you ;-)
Sorry if I sounded a bit rude, I didn't mean it :-/
> - what mmc host controller is used?
So this is sdhci-acpi.
> - do you have CONFIG_RUNTIME_PM enabled?
CONFIG_PM_RUNTIME is enabled, yes. Do you want me to test with it
disabled ?
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/