Hi, I've been looking into why the watchdog on my DG834G(v2) has not been rebooting the unit after a kick timeout and I have a bug open at https://dev.openwrt.org/ticket/2378 . Seeing that this code has now gone into the mainline kernel, I was able to ask around on other channels as to what could be happening. I was told on #linuxmips that *some* AR7 devices have their watchdog disabled in hardware (via a resistor). I was also told that this status could be checked by looking at the BOOTCR register at 0xa8611a00. In the linux kernel, this corresponds to AR7_REGS_DCL and the clocks.c code actually makes use of this.
Ideally, one would want to modify ar7_wdt_init() to check the status of that register and bail out if it's disabled in hardware, but the actually bit encoding of this register is under NDA. One approach to reverse engineering this would be to carry a survey out of this value on openwrt users ar7 devices, and then look for some patterns. I have the following patch that will print this value:
Index: target/linux/ar7/files/arch/mips/ar7/clock.c
===================================================================
--- target/linux/ar7/files/arch/mips/ar7/clock.c (revision 10156)
+++ target/linux/ar7/files/arch/mips/ar7/clock.c (working copy)
@@ -257,6 +257,7 @@
static void __init tnetd7300_init_clocks(void)
{
u32 *bootcr = (u32 *)ioremap_nocache(AR7_REGS_DCL, 4);
+ printk("bootcr is %#x \n", *bootcr);
struct tnetd7300_clocks *clocks =
(struct tnetd7300_clocks *)
ioremap_nocache(AR7_REGS_POWER + 0x20,
You may have to carry out a small modification if you have a 7100/7200. Mine, on a DG834G(v2), is 0x2594281 which is 10010110010100001010000001
It would be really good if some other ar7 peeps could chime in here with their bootcr values.