sdio 8686 firmware load problem.

[Jonathan Cameron]

Jonathan Cameron wrote:
> Mark Litwack wrote:
>> On Tue, 11 Aug 2009 13:20:45 +0000
>> Jonathan Cameron <jic23 at cam.ac.uk> wrote:
>>> Jonathan Cameron wrote:
>>>>> Jonathan Cameron wrote:
>>>>>> V8 and V9 firmware's from git repository are both
>>>>>> giving the following debug.
>>>>>>
>>>>>> libertas enter: lbs_init_module()
>>>>>> libertas leave: lbs_init_module()
>>>>>> libertas enter: if_sdio_init_module()
>>>>>> libertas_sdio: Libertas SDIO driver
>>>>>> libertas_sdio: Copyright Pierre Ossman
>>>>>> libertas enter: if_sdio_probe()
>>>>>> libertas sdio: class = 0x7, vendor = 0x2DF, device =
>>>>>> 0x9103, model = 0xB, ioport = 0x10000 libertas enter:
>>>>>> if_sdio_prog_firmware() libertas sdio: firmware
>>>>>> status = 0x0 into sdio firmware load
>>>>>> libertas enter: if_sdio_prog_helper()
>>>>>> libertas_sdio mmc0:0001:1: firmware: requesting
>>>>>> sd8686_helper.bin libertas sdio: waiting for helper
>>>>>> to boot... libertas leave: if_sdio_prog_helper(), ret
>>>>>> 0 libertas enter: if_sdio_prog_real()
>>>>>> libertas_sdio mmc0:0001:1: firmware: requesting
>>>>>> sd8686.bin libertas sdio: firmware wants 16 bytes
>>>>>> libertas sdio: firmware wants 17 bytes
>>>>>> libertas sdio: firmware helper signalled error
>>>>>> libertas: failed to load firmware
>>>>>> libertas leave: if_sdio_prog_real(), ret -5
>>>>>> libertas leave: if_sdio_prog_firmware(), ret -5
>>>>>> libertas leave: if_sdio_probe(), ret -5
>>>>>> libertas_sdio: probe of mmc0:0001:1 failed with error
>>>>>> -5 libertas leave: if_sdio_init_module(), ret 0
>>>>>>
>>>>>> This was previously working with this board and the
>>>>>> same kernel setup prior to switching from a scratch
>>>>>> built filesystem etc to using openembedded.
>>>>>>
>>>>>> Anyone have any suggestions on what might be
>>>>>> happening?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Jonathan
>>>>> Forgot to mention this is with 2.6.31-rc5
>>>> Ok, bit more info.
>>>>
>>>> Uncommenting out the line in the helper firmware load
>>>> that makes it log how much data is being sent makes
>>>> everything work.
>>>>
>>>> Looks like something racy is going on. Will poke
>>>> further.
>>>>
>>>> For more info, this on a pxa271 board. The only non
>>>> libertas change recently that might effect it was a fix
>>>> to the pxamci dma code, will try reverting that.
>>> Revert the pxamci fix doesn't help.
>>>
>>> Have reduced things to a single msleep(1) before
>>>
>>> 		ret = sdio_writesb(card->func,
>>> card->ioport, chunk_buffer, 64);
>>>
>>> in: static int if_sdio_prog_helper(struct if_sdio_card
>>> *card)
>>>
>>> + sticking a large sleep at the end of the firmware load
>>> doesn't seem to help.
>>>
>>> Has anyone seen anything similar?
>>
>> Hi Jonathan,
>>
>> I saw the same behavior when I was trying to get the
>> libertas driver working with the SDIO driver running in SPI
>> mode (as per SDIO Simplified Spec 2.00, section 2.2.1).
>>
>> The libertas driver would load the firmware helper, or at
>> least think it did, and then would proceed to get requests
>> for 16 or 17 bytes at a time.  Eventually it would time out,
>> exactly as your example.
>>
>> I was never able to resolve it.  My only guess was that I
>> needed a helper and/or firmware specifically for SDIO/SPI
>> mode.
>>
>> Perhaps your problem is that your new kernel is configuring
>> the pxamci for SDIO/SPI mode instead of normal SDIO.  Just a
>> guess -- the symptoms are the same.
> Probably a coincidence. The pxamci driver doesn't seem to even
> support the spi modes.
> 
> This definitely looks like a startup race condition.  If you
> load the libertas drivers prior to pxamci it fails even with
> the above delay.
> 
> Right now, even with the nasty delay hack, I can't seem to associate
> with any networks. Just trying to track down why.
On that note, does anyone happen to know what a v9 firmware
association response of 0x12 is indicating?

Cheers,

Jonathan