sdio 8686 firmware load problem.

[Jonathan Cameron]

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.

Jonathan