Hi,
we're trying to get a SD8787 to play which is connected via SDIO to an
OMAP hsmmc (AM33xx hardware). This fails with the following message:
# modprobe mwifiex_sdio
[ 13.984779] [sched_delayed] sched: RT throttling activated
[ 22.401700] mwifiex_sdio mmc0:0001:1: FW failed to be active in time
The firmware sd8787_uapsta.bin was taken from the linux-firmware.git and
apparently is transferred successfully, but then consequently fails to
do start up. When compiled with CONFIG_MMC_CONFIG=y, tons of successful
messages are logged like this:
[ 2607.867660] mmc0: starting CMD52 arg 00000a00 flags 00000195
[ 2607.867713] mmc0: req done (CMD52): 0: 00001000 00000000 00000000
00000000
[ 2607.883273] mmc0: starting CMD52 arg 00000a00 flags 00000195
[ 2607.883327] mmc0: req done (CMD52): 0: 00001000 00000000 00000000
00000000
[ 2607.898905] mmc0: starting CMD52 arg 00000a00 flags 00000195
The kernel we're based on is Linus' current merge tree (3.7-rc1), but
earlier version (3.6) have shown the same issue.
Before we start digging into this, I want to ask whether there are any
common pitfalls we should be aware of and that could cause this?
Please let me know whether you need any further information.
Many thanks,
Daniel
Hi Bing,
thanks for your time.
On 18.10.2012 02:20, Bing Zhao wrote:
>> we're trying to get a SD8787 to play which is connected via SDIO to an
>> OMAP hsmmc (AM33xx hardware). This fails with the following message:
>>
>> # modprobe mwifiex_sdio
>> [ 13.984779] [sched_delayed] sched: RT throttling activated
>> [ 22.401700] mwifiex_sdio mmc0:0001:1: FW failed to be active in time
>>
>> The firmware sd8787_uapsta.bin was taken from the linux-firmware.git and
>> apparently is transferred successfully, but then consequently fails to
>> do start up. When compiled with CONFIG_MMC_CONFIG=y, tons of successful
>> messages are logged like this:
>>
>> [ 2607.867660] mmc0: starting CMD52 arg 00000a00 flags 00000195
>> [ 2607.867713] mmc0: req done (CMD52): 0: 00001000 00000000 00000000
>> 00000000
>> [ 2607.883273] mmc0: starting CMD52 arg 00000a00 flags 00000195
>> [ 2607.883327] mmc0: req done (CMD52): 0: 00001000 00000000 00000000
>> 00000000
>> [ 2607.898905] mmc0: starting CMD52 arg 00000a00 flags 00000195
>
> It keeps reading Int_Pending (CCCR register 0x05). Perhaps you have interrupt storm here?
> Could you please check if your controller clears interrupt properly?
The reason for this issue was a different one: the 32KHz clock was not
running. I just learned that the firmware download will succeed
nevertheless, but the firmware won't start. Note to myself: make sure to
rule out any hardware issue before bordering developers :-/ But that
posting may be a help to someone with similar issues one day ...
>> The kernel we're based on is Linus' current merge tree (3.7-rc1), but
>> earlier version (3.6) have shown the same issue.
>>
>> Before we start digging into this, I want to ask whether there are any
>> common pitfalls we should be aware of and that could cause this?
>
> You may want to get a newer firmware release from here:
>
> http://git.marvell.com/?p=mwifiex-firmware.git;a=summary
> git://git.marvell.com/mwifiex-firmware.git
Note that contains the same firmware binary than the linux-firmware
repository.
>> Please let me know whether you need any further information.
>
> It might be helpful if you post messages before this line:
>
> [ 2607.867660] mmc0: starting CMD52 arg 00000a00 flags 00000195
Thanks again!
Daniel
[have to re-open this issue again]
On 21.10.2012 16:16, Andrei Emeltchenko wrote:
> I have the same board and see this problem sometimes. Reloading modules
> might help, if not reboot always works :).
I thought I solved this issue, but I can't reproduce the running version
anymore unfortunately. It constantly fails with the error I described,
even though the clock and all voltages etc are definitely stable. I can
also rule out hardware issues as the BSP kernel (3.2.18) works just fine
with the same setup including the firmware image.
Andrei, may I ask which board you have exactly? What kernel version are
you based on? I wonder if the firmware is actually transferred
correctly, or which reason there could be for it not to start up. Could
that be related to the recent AM33xx/omap_hsmmc DMA reworks? [copied Matt]
Bing, FWIW here are some more complete logs with CONFIG_MMC_DEBUG=y.
This is the detection of the SDIO card:
http://pastebin.com/h9VDaExh
And this is what happens after "modprobe mwifiex_sdio":
http://pastebin.com/w5bcz6Aa (part 1/2)
http://pastebin.com/G5wfnPrg (part 2/2)
Can anyone see what's wrong here?
Thanks again,
Daniel
> 18.10.2012 18:09 пользователь "Daniel Mack" <[email protected]
> <mailto:[email protected]>> написал:
>>
>> Hi Bing,
>>
>> thanks for your time.
>>
>> On 18.10.2012 02:20, Bing Zhao wrote:
>> >> we're trying to get a SD8787 to play which is connected via SDIO to an
>> >> OMAP hsmmc (AM33xx hardware). This fails with the following message:
>> >>
>> >> # modprobe mwifiex_sdio
>> >> [ 13.984779] [sched_delayed] sched: RT throttling activated
>> >> [ 22.401700] mwifiex_sdio mmc0:0001:1: FW failed to be active in time
>> >>
>> >> The firmware sd8787_uapsta.bin was taken from the
> linux-firmware.git and
>> >> apparently is transferred successfully, but then consequently fails to
>> >> do start up. When compiled with CONFIG_MMC_CONFIG=y, tons of successful
>> >> messages are logged like this:
>> >>
>> >> [ 2607.867660] mmc0: starting CMD52 arg 00000a00 flags 00000195
>> >> [ 2607.867713] mmc0: req done (CMD52): 0: 00001000 00000000 00000000
>> >> 00000000
>> >> [ 2607.883273] mmc0: starting CMD52 arg 00000a00 flags 00000195
>> >> [ 2607.883327] mmc0: req done (CMD52): 0: 00001000 00000000 00000000
>> >> 00000000
>> >> [ 2607.898905] mmc0: starting CMD52 arg 00000a00 flags 00000195
>> >
>> > It keeps reading Int_Pending (CCCR register 0x05). Perhaps you have
> interrupt storm here?
>> > Could you please check if your controller clears interrupt properly?
>>
>> The reason for this issue was a different one: the 32KHz clock was not
>> running. I just learned that the firmware download will succeed
>> nevertheless, but the firmware won't start. Note to myself: make sure to
>> rule out any hardware issue before bordering developers :-/ But that
>> posting may be a help to someone with similar issues one day ...
>>
>> >> The kernel we're based on is Linus' current merge tree (3.7-rc1), but
>> >> earlier version (3.6) have shown the same issue.
>> >>
>> >> Before we start digging into this, I want to ask whether there are any
>> >> common pitfalls we should be aware of and that could cause this?
>> >
>> > You may want to get a newer firmware release from here:
>> >
>> > http://git.marvell.com/?p=mwifiex-firmware.git;a=summary
>> > git://git.marvell.com/mwifiex-firmware.git
> <http://git.marvell.com/mwifiex-firmware.git>
>>
>> Note that contains the same firmware binary than the linux-firmware
>> repository.
>>
>> >> Please let me know whether you need any further information.
>> >
>> > It might be helpful if you post messages before this line:
>> >
>> > [ 2607.867660] mmc0: starting CMD52 arg 00000a00 flags 00000195
>>
>>
>> Thanks again!
>>
>> Daniel
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe
> linux-wireless" in
>> the body of a message to [email protected]
> <mailto:[email protected]>
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
On 26.10.2012 22:58, Daniel Mack wrote:
> [have to re-open this issue again]
>
> On 21.10.2012 16:16, Andrei Emeltchenko wrote:
>> I have the same board and see this problem sometimes. Reloading modules
>> might help, if not reboot always works :).
>
> I thought I solved this issue, but I can't reproduce the running version
> anymore unfortunately. It constantly fails with the error I described,
> even though the clock and all voltages etc are definitely stable.
Ok, following up on my own writings: I solved this issue. It took me
awhile to figure out that the 88WSD8787 is really picky about the
clock/power sequencing. It really needs >= 1ms delay in the startup
phase, otherwise the firmware won't start up.
So if anyone has this problem, make sure to care for that very detail.
Daniel
SGkgRGFuaWVsLA0KDQo+IEhpLA0KPiANCj4gd2UncmUgdHJ5aW5nIHRvIGdldCBhIFNEODc4NyB0
byBwbGF5IHdoaWNoIGlzIGNvbm5lY3RlZCB2aWEgU0RJTyB0byBhbg0KPiBPTUFQIGhzbW1jIChB
TTMzeHggaGFyZHdhcmUpLiBUaGlzIGZhaWxzIHdpdGggdGhlIGZvbGxvd2luZyBtZXNzYWdlOg0K
PiANCj4gIyBtb2Rwcm9iZSBtd2lmaWV4X3NkaW8NCj4gWyAgIDEzLjk4NDc3OV0gW3NjaGVkX2Rl
bGF5ZWRdIHNjaGVkOiBSVCB0aHJvdHRsaW5nIGFjdGl2YXRlZA0KPiBbICAgMjIuNDAxNzAwXSBt
d2lmaWV4X3NkaW8gbW1jMDowMDAxOjE6IEZXIGZhaWxlZCB0byBiZSBhY3RpdmUgaW4gdGltZQ0K
PiANCj4gVGhlIGZpcm13YXJlIHNkODc4N191YXBzdGEuYmluIHdhcyB0YWtlbiBmcm9tIHRoZSBs
aW51eC1maXJtd2FyZS5naXQgYW5kDQo+IGFwcGFyZW50bHkgaXMgdHJhbnNmZXJyZWQgc3VjY2Vz
c2Z1bGx5LCBidXQgdGhlbiBjb25zZXF1ZW50bHkgZmFpbHMgdG8NCj4gZG8gc3RhcnQgdXAuIFdo
ZW4gY29tcGlsZWQgd2l0aCBDT05GSUdfTU1DX0NPTkZJRz15LCB0b25zIG9mIHN1Y2Nlc3NmdWwN
Cj4gbWVzc2FnZXMgYXJlIGxvZ2dlZCBsaWtlIHRoaXM6DQo+IA0KPiBbIDI2MDcuODY3NjYwXSBt
bWMwOiBzdGFydGluZyBDTUQ1MiBhcmcgMDAwMDBhMDAgZmxhZ3MgMDAwMDAxOTUNCj4gWyAyNjA3
Ljg2NzcxM10gbW1jMDogcmVxIGRvbmUgKENNRDUyKTogMDogMDAwMDEwMDAgMDAwMDAwMDAgMDAw
MDAwMDANCj4gMDAwMDAwMDANCj4gWyAyNjA3Ljg4MzI3M10gbW1jMDogc3RhcnRpbmcgQ01ENTIg
YXJnIDAwMDAwYTAwIGZsYWdzIDAwMDAwMTk1DQo+IFsgMjYwNy44ODMzMjddIG1tYzA6IHJlcSBk
b25lIChDTUQ1Mik6IDA6IDAwMDAxMDAwIDAwMDAwMDAwIDAwMDAwMDAwDQo+IDAwMDAwMDAwDQo+
IFsgMjYwNy44OTg5MDVdIG1tYzA6IHN0YXJ0aW5nIENNRDUyIGFyZyAwMDAwMGEwMCBmbGFncyAw
MDAwMDE5NQ0KDQpJdCBrZWVwcyByZWFkaW5nIEludF9QZW5kaW5nIChDQ0NSIHJlZ2lzdGVyIDB4
MDUpLiBQZXJoYXBzIHlvdSBoYXZlIGludGVycnVwdCBzdG9ybSBoZXJlPw0KQ291bGQgeW91IHBs
ZWFzZSBjaGVjayBpZiB5b3VyIGNvbnRyb2xsZXIgY2xlYXJzIGludGVycnVwdCBwcm9wZXJseT8N
Cg0KPiANCj4gDQo+IFRoZSBrZXJuZWwgd2UncmUgYmFzZWQgb24gaXMgTGludXMnIGN1cnJlbnQg
bWVyZ2UgdHJlZSAoMy43LXJjMSksIGJ1dA0KPiBlYXJsaWVyIHZlcnNpb24gKDMuNikgaGF2ZSBz
aG93biB0aGUgc2FtZSBpc3N1ZS4NCj4gDQo+IEJlZm9yZSB3ZSBzdGFydCBkaWdnaW5nIGludG8g
dGhpcywgSSB3YW50IHRvIGFzayB3aGV0aGVyIHRoZXJlIGFyZSBhbnkNCj4gY29tbW9uIHBpdGZh
bGxzIHdlIHNob3VsZCBiZSBhd2FyZSBvZiBhbmQgdGhhdCBjb3VsZCBjYXVzZSB0aGlzPw0KDQpZ
b3UgbWF5IHdhbnQgdG8gZ2V0IGEgbmV3ZXIgZmlybXdhcmUgcmVsZWFzZSBmcm9tIGhlcmU6DQoN
Cmh0dHA6Ly9naXQubWFydmVsbC5jb20vP3A9bXdpZmlleC1maXJtd2FyZS5naXQ7YT1zdW1tYXJ5
DQpnaXQ6Ly9naXQubWFydmVsbC5jb20vbXdpZmlleC1maXJtd2FyZS5naXQNCg0KPiANCj4gUGxl
YXNlIGxldCBtZSBrbm93IHdoZXRoZXIgeW91IG5lZWQgYW55IGZ1cnRoZXIgaW5mb3JtYXRpb24u
DQoNCkl0IG1pZ2h0IGJlIGhlbHBmdWwgaWYgeW91IHBvc3QgbWVzc2FnZXMgYmVmb3JlIHRoaXMg
bGluZToNCg0KWyAyNjA3Ljg2NzY2MF0gbW1jMDogc3RhcnRpbmcgQ01ENTIgYXJnIDAwMDAwYTAw
IGZsYWdzIDAwMDAwMTk1DQoNClRoYW5rcywNCkJpbmcNCg0KPiANCj4gDQo+IE1hbnkgdGhhbmtz
LA0KPiBEYW5pZWwNCg==
On 01.11.2012 10:48, Andrei Emeltchenko wrote:
> Hi Daniel,
>
> On Sun, Oct 28, 2012 at 04:49:02PM +0100, Daniel Mack wrote:
>> On 26.10.2012 22:58, Daniel Mack wrote:
>>> [have to re-open this issue again]
>>>
>>> On 21.10.2012 16:16, Andrei Emeltchenko wrote:
>>>> I have the same board and see this problem sometimes. Reloading modules
>>>> might help, if not reboot always works :).
>>>
>>> I thought I solved this issue, but I can't reproduce the running version
>>> anymore unfortunately. It constantly fails with the error I described,
>>> even though the clock and all voltages etc are definitely stable.
>>
>> Ok, following up on my own writings: I solved this issue. It took me
>> awhile to figure out that the 88WSD8787 is really picky about the
>> clock/power sequencing. It really needs >= 1ms delay in the startup
>> phase, otherwise the firmware won't start up.
>
> So did you put delay in a marvell sdio driver?
No, that has to be done by some code that first enables the clock and
then asserts the PDN line (assuming that clock is generated by some sort
of PLL or CPU).
Daniel
Hi Daniel,
On Sun, Oct 28, 2012 at 04:49:02PM +0100, Daniel Mack wrote:
> On 26.10.2012 22:58, Daniel Mack wrote:
> > [have to re-open this issue again]
> >
> > On 21.10.2012 16:16, Andrei Emeltchenko wrote:
> >> I have the same board and see this problem sometimes. Reloading modules
> >> might help, if not reboot always works :).
> >
> > I thought I solved this issue, but I can't reproduce the running version
> > anymore unfortunately. It constantly fails with the error I described,
> > even though the clock and all voltages etc are definitely stable.
>
> Ok, following up on my own writings: I solved this issue. It took me
> awhile to figure out that the 88WSD8787 is really picky about the
> clock/power sequencing. It really needs >= 1ms delay in the startup
> phase, otherwise the firmware won't start up.
So did you put delay in a marvell sdio driver?
Best regards
Andrei Emeltchenko
>
> So if anyone has this problem, make sure to care for that very detail.
>
>
>
> Daniel
Hi Mack,
On Fri, Oct 26, 2012 at 10:58:58PM +0200, Daniel Mack wrote:
> [have to re-open this issue again]
>
> On 21.10.2012 16:16, Andrei Emeltchenko wrote:
> > I have the same board and see this problem sometimes. Reloading modules
> > might help, if not reboot always works :).
>
> I thought I solved this issue, but I can't reproduce the running version
> anymore unfortunately. It constantly fails with the error I described,
> even though the clock and all voltages etc are definitely stable. I can
> also rule out hardware issues as the BSP kernel (3.2.18) works just fine
> with the same setup including the firmware image.
>
> Andrei, may I ask which board you have exactly?
I do not know exactly, it is MARVELL RD8787 AG1_V3 with WIB Adapter v3.
> What kernel version are
> you based on?
I use latest bluetooth-next which is 3.7-rc1 + some bluetooth & wireless patches
Best regards
Andrei Emeltchenko