AR6000 driver failed on probe stage

dongas dongas86 at
Thu Apr 9 04:06:47 CEST 2009

Dear Ivan,

Can you help send me a total log of  ar6000 driver initialization
process such as from you insmod ar6000.ko?
(with ar6000 driver loglevel = 0xFFF7 and openning the mmc core debug info)

The former log you'v sent me seems a little later of ar6000 initialization.
I can not compare with the my log of ar6000 driver initialization.



2009/4/8 dongas <dongas86 at>:
> 2009/4/7 Ivan Petrov <ivan_p at>:
>> I was have similar problem at start of driver port to AT91SAM9260, problem
>> was in SDIO_IRQ suport for my CPU in 4wire mode.
>> First, try turn off MMC_CAP_SDIO_IRQ in you MMC host controller. In this
>> case IRQ state will request every 10ms. Posible it help you.
>>> - mmc->caps = MMC_CAP_SDIO_IRQ;
>>> + mmc->caps = 0; // MMC_CAP_SDIO_IRQ;
> Bit unlucky on me. :-(
> I have tried this method but the same issue still existed.
> I double-checked the ar6000 driver's initialization process, as i
> know, before the driver hanged
> it only had done a few things as following steps:
> 1. enable sdio wifi function with CMD52
> 2. set function block size to 128 with CMD52
> 3. enable sdio irq with CMD52 (if turn it on)
> 4. disable ar6000 interrupts with CMD53
> We have connected a logic analyzer to host to check that all above
> CMD/DATA were sent successful.
> So it seems not cause by some failure during the ar6000 driver initialization.
> 5. try to get BMI command credits by reading COUNTER_DEC register
> AR6000 driver hanged on this step where it was trying to read a BMI
> command credit from CONUTER_DEC register, but it alway got a NULL
> value.
> (The accurate addres the driver read is 0x450 which is calculated by
> the following method defined in bmi.c
> Do you know why the content of CONUTER_DEC register of wifi card is alway 0?
> In other words, why the target hasn't provided this initial command
> credits for host?
> Any one has any idea on this issue?
> Your advice will be highly apprecaited.
> Regards
> Dongas
>> ----- Original Message ----- From: "dongas" <dongas86 at>
>> To: <openmoko-kernel at>
>> Sent: Tuesday, April 07, 2009 4:46 PM
>> Subject: Re: AR6000 driver failed on probe stage
>> 2009/3/28 dongas <dongas86 at>:
>>> After digging into the code, i found that in bmiBufferSend function in
>>> bmi.c,
>>> the driver will try to repeatly read the COUNT_DEC register of the
>>> card  until the register value read back is Non-zero and then the
>>> following
>>> steps can go on.
>>> But the value returned from register was alway zero , so ar6000 driver
>>> hanged there and keeped doing almost the infinit loop
>>> reading&checking.
>>> Why the driver can not read a non-zero value from COUNT_DEC register
>>> as it wanted?
>> After debugging i found that the ar6000 driver failed when it was
>> trying to read target version via BMI request of ar6000 in the routine
>> BMIGetTargetInfo because it was unable to get a BMI command credit(by
>> reading CONUTER_DEC register) for the next BMI request according to
>> the BMI flow control.
>> I think if the target(ar6000) initialized successful before after the
>> host enabled it, the target should have initially provided one command
>> credit to host according to the datasheet, but it hadn’t. (if wrong
>> pls correct me )
>> (The target is enabled by the CMD52 to write to ENABLE BIT of CCCR
>> register of card.
>> Once the target is enabled, it executes firmware that initializes SoC
>> and software states.)
>> So the driver repeatly tried to get this command credit and hanged there.
>> I went through some ar6001 related specs/documents, but still havn't
>> got the key of this issue that why the target failed to provided one
>> command credit to after it was enabled by host?
>> I guess the target failed to initailize itself or worked inproperly
>> but don't know which reason might cause it failed.
>> Now only one thing i can make sure is that wifi card is on I/O Ready
>> state after host enables it by checing CCCR register.
>> Any ideas about this issue?
>> Thanks
>> Regards
>> Dongas

More information about the openmoko-kernel mailing list