Did this mean we need poll something when do the external reset? I check the https://dev.openwrt.org/changeset/27083,found it's check the AR933X_BOOTSTRAP_EEPBUSY when do reset,but the latest code have remove it.
2012/8/24 Gabor Juhos <[email protected]> > 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 > _______________________________________________ > openwrt-devel mailing list > [email protected] > https://lists.openwrt.org/mailman/listinfo/openwrt-devel >
_______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
