Re: AR9330 hornet board stops beaconing after a few days (0xdeadbeef)

[Gabor Juhos <juhosg@xxxxxxxxxxx>]

2012.08.23. 11:28 keltezéssel, Simon Wunderlich írta:
> Hello Adrian,
> 
> thanks for your comments!
> 
> On Wed, Aug 22, 2012 at 11:57:04AM -0700, Adrian Chadd wrote:
>> Yeah. The deadbeef means "something's turned off."
>>
>> I'd start with the SoC reset register and see if the MAC/WMAC bits are
>> correctly set. Ie, that something hasn't gone and reset the wireless
>> bits behind your back.
> 
> Sure, but which register would that be? How can I find out? Is it included
> in regdump of ath9k debugfs?

It is the AR933X_RESET_REG_RESET_MODULE register (0x1806001c), and the reset of
the WMAC chip is controlled by the AR933X_RESET_WMAC bit. You can find the
definitions in arch/mips/include/asm/mach-ath79/ar71xx_regs.h.

The platform device registration code pulls the WMAC chip out of reset before
registering the device. See the 'ar933x_wmac_setup' function in
'arch/mips/ath79/dev-wmac.c'. Then only the ath9k driver controls the hardware
reset line indirectly via ah->external_reset.

However, I doubt that the 0xdeadbeef values are caused by this. If the
AR933X_RESET_WMAC bit is set in the reset register, the WMAC chip is not
accessible at all. If the AR933X_RESET_WMAC bit is set and the driver tries to
access the WMAC registers, the board locks up completely, or reboots itself. At
least I have experienced this earlier.

-Gabor
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html