I’m a developer working with the Atheros AR6003 Wireless LAN chip. I recently
updated the Linux kernel on my custom board to 3.0.0 and pulled the latest
snapshot of the ath6kl driver from
http://git.kernel.org/?p=linux/kernel/git/kvalo/ath6kl-cleanup.git;a=summary (as
of 2011-07-25). I’m also using the latest firmware images from
http://www.kernel.org/pub/linux/kernel/people/mcgrof/firmware/ath6k.tar.gz as
recommended by
http://wireless.kernel.org/en/users/Drivers/ath6kl?highlight=%28ar6003%29.
After running 'insmod ath6kl.ko', the command line hangs. I’ve narrowed down
the execution path to the function ath6kl_bmi_get_rx_lkahd (called from
ath6kl_bmi_exeute after loading the OPT firmware). The parameter value of
"need_timeout" is set to false. Without this timeout the function never
returns. The call to ath6kl_hif_read_write_sync always returns 0, and the value
of rx_word is always 0.
My question is: What would cause the read from address
RX_LOOKAHEAD_VALID_ADDRESS to always return a value of 0?
My custom board is using an atmel at91sam9g45 microprocessor using the SDIO bus
on mci1. Any information would be greatly appreciated.
Thanks,
Brent Taylor
Senior Software Developer
Applied Technology Department of Motorola Solutions
[email protected]
On Tue, Jul 26, 2011 at 03:43:02PM +0000, Brent Taylor wrote:
> I’m a developer working with the Atheros AR6003 Wireless LAN chip. I recently
> updated the Linux kernel on my custom board to 3.0.0 and pulled the latest
> snapshot of the ath6kl driver from
> http://git.kernel.org/?p=linux/kernel/git/kvalo/ath6kl-cleanup.git;a=summary (as
> of 2011-07-25). I’m also using the latest firmware images from
> http://www.kernel.org/pub/linux/kernel/people/mcgrof/firmware/ath6k.tar.gz as
> recommended by
> http://wireless.kernel.org/en/users/Drivers/ath6kl?highlight=%28ar6003%29.
>
These are fine.
> After running 'insmod ath6kl.ko', the command line hangs. I’ve narrowed down
> the execution path to the function ath6kl_bmi_get_rx_lkahd (called from
> ath6kl_bmi_exeute after loading the OPT firmware). The parameter value of
> "need_timeout" is set to false. Without this timeout the function never
> returns. The call to ath6kl_hif_read_write_sync always returns 0, and the value
> of rx_word is always 0.
>
> My question is: What would cause the read from address
> RX_LOOKAHEAD_VALID_ADDRESS to always return a value of 0?
Odd, we have never seen this sort of issues. Can you please give
the kernel debug output with BMI debug enabled (debug_mask=0x10).
Vasanth
Kalle Valo <kvalo@...> writes:
>
> Brent Taylor <btaylor1@...> writes:
>
> > Fixed ... realized that I was using the wrong firmware images. I was
> > using an older image from AR6K_FW.3.0_RC.233.
>
> Good that your issue was solved and thanks for letting us now. But
> nevertheless the driver should not lockup in there's a problem with
> firmware, ath6kl is definitely buggy here.
>
My lockup (due to wrong firmware) was caused by the function
ath6kl_bmi_get_lkahd in bmi.c. The function was called with the parameter
"need_timeout = false". This causes the while loop to wait for a response from
the chip. Since the wrong firmware image was used, the chip will never respond.
Is it possible for the ath6kl driver to somehow read the firmware version from
the firmware file before sending it to the chip?
-- Brent
Hi Brent,
On 08/04/2011 03:55 PM, Brent Taylor wrote:
> Kalle Valo <kvalo@...> writes:
>
>>
>> Brent Taylor <btaylor1@...> writes:
>>
>>> Fixed ... realized that I was using the wrong firmware images. I was
>>> using an older image from AR6K_FW.3.0_RC.233.
>>
>> Good that your issue was solved and thanks for letting us now. But
>> nevertheless the driver should not lockup in there's a problem with
>> firmware, ath6kl is definitely buggy here.
>
> My lockup (due to wrong firmware) was caused by the function
> ath6kl_bmi_get_lkahd in bmi.c. The function was called with the parameter
> "need_timeout = false". This causes the while loop to wait for a response from
> the chip. Since the wrong firmware image was used, the chip will never respond.
Thanks for the analysis. Yesterday I submitted a patch for review which
will fix this.
> Is it possible for the ath6kl driver to somehow read the firmware version from
> the firmware file before sending it to the chip?
Not right now. But in the new firmware image format (for which I also
sent patches yesterday) we can do that. You can even check the firmware
just with the strings command.
Thank you for the feedback, I appreciate it.
Kalle