sdio 8686 firmware load problem.

[Dan Williams]

On Wed, 2009-08-12 at 06:16 +0000, Jonathan Cameron wrote:
> 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?

So you already figured it out, but just for the record, in assoc.c:

		/* v9+ returns the AP's association response */
		lbs_deb_assoc("ASSOC_RESP: failure reason 0x%02x\n", status_code);

so it's going to be the actual status code from the AP, which for 0x12
is:

"Association denied; the mobile station does not support all of the data
rates required by the BSS"

So it's Roel's rate patch that's causing your association problems.

Dan