Ath79-wdt: how to disable watchdog within <1s into kernel execution?

Hi everyone,

I'm trying to add support for the D-Link DAP series business APs made by Edimax (e.g. DAP-2662 here).
They are QCA9563 + Wave2, using the elx-header image type wrapped into wrgg03 image.

When booting initramfs, the device will perform a factory reset roughly 1 second after uboot hands over execution to the kernel, and in the stock firmware, a few messages related to ath79-wdt are output around that time of boot:

m25p80 spi0.0: w25q128 (16384 Kbytes)
Creating 9 MTD partitions on "spi0.0":
0x000000000000-0x000001000000 : "ALL"
0x000000000000-0x000000040000 : "Bootloader"
0x000000040000-0x000000050000 : "Config"
0x000000050000-0x000000d70000 : "Kernel"
0x000000250000-0x000000d70000 : "user"
0x000000d70000-0x000000e70000 : "userdata"
0x000000e70000-0x000000f70000 : "manufacture"
0x000000f70000-0x000000ff0000 : "storage"
0x000000ff0000-0x000001000000 : "ART"
libphy: ag71xx_mdio: probed
eth0: Atheros AG71xx at 0xb9000000, irq 4
Disable 803x az function.
ag71xx 19000000.ethernet: connected to PHY at 19000000.mdio:03 [uid=004dd074, driver=Atheros 8031/8033 ethernet]
Registered button device:reset, gpio:2,code:408,index:10
ath79_wdt: WDOG_REG_CTRL: 0x0

Error: Driver 'ath79-wdt' is already registered, aborting...
u32 classifier
    Actions configured

Looking at the datasheets, there is a hardware watchdog in ath79 at 0x18060008, and even a dt binding which I tried to use:

&wdt {
	status = "okay";

	timeout-sec = <1>;

Even with status = 'disabled' there is no difference, the boot will interrupt after about 1 second:

[    0.620020] 1 squashfs-split partitions found on MTD device rootfs
[    0.626446] 0x000000b50000-0x000000e20000 : "rootfs_data"
[    0.633585] 0x000000e70000-0x000000f70000 : "manufacture"
[    0.640065] 0x000000f70000-0x000000ff0000 : "storage"
[    0.647628] 0x000000ff0000-0x000001000000 : "art"
[    0.658567] libphy: Fixed MDIO Bus: probed
[    0.666312] ag71xx 19000000.eth: invalid MAC address, using random address

U-Boot 1.1.4-g1466e5c4 (Mar 13 2018 - 13:39:31)
ELX version: 1.0.3

ap152_ar8033 - Dragonfly 1.0DRAM:
ath_ddr_initial_config(278): (ddr2 init)
ath_sys_frequency: cpu 775 ddr 650 ahb 258
Tap values = (0xf, 0xf, 0xf, 0xf)
128 MB

I also disabled any GPIOs, disabled JTAG pins etc. to make sure there is no hardware short-circuit etc. causing a reset.
So it seems, maybe the watchdog configuration just happens too late in the boot process?
I also tried to fiddle with the pinctrl-single driver to overwrite the watchdog enable bit via gpio-keys, and delete the &wdt node declared in the dtsi altogether:

/delete-node/ &wdt;
	wdtpinmux: pinmux@18060008 {
		compatible = "pinctrl-single";

		reg = <0x18060008 0x8>;

		#size-cells = <0>;

		pinctrl-single,register-width = <32>;
		pinctrl-single,function-mask = <0x1>;
		#pinctrl-cells = <2>;

		wdt_disable: pinmux_wdt_disable {
			pinctrl-single,bits = <0x0 0x0 0x3>;

	keys {
		compatible = "gpio-keys";

		pinctrl-names = "default", "nowdt";
		pinctrl-0 = <&jtag_disable_pins>;
		pinctrl-1 = <&wdt_disable>;

		reset {
			label = "reset";
			linux,code = <KEY_RESTART>;
			gpios = <&gpio 2 GPIO_ACTIVE_HIGH>;

But this does not work either, it still reboots, from both initramfs, or when writing the image to flash.

I also verified with OKLI loader, which usually says SYSTEM HALTED when it could not find a partition, and it reboots as well, so I'm quite certain this is the ath79 wathchog. Although in the uboot shell, the registers (including reason for last reboot) will be set to 0 already (wdt is probably just enabled right before handing over control to the extracted kernel image, since uboot could not periodically reset it without heavy modifications).

Any suggestions on how to make sure the wdt reset happens even earlier in the boot process?

Any further input on this is highly appreciated :slight_smile:

This looks more like an external, hardware watchdog which requires GPIO based toggling.
Are there any GPL tarballs available for this model, with U-Boot sources?

The GPL tarball [1] does not seem to contain uboot sources, and I also thought about a hardware watchdog from the beginning. However I could not spot anything suspicious on the PCB, but will have another look.

I also doubt there might be any issues related to ethernet configuration, but usually the GPIO config seems to happen around that time of boot. Maybe switching from bootloader settings to high-impedance could be a trigger here.

It's curious that the oem bootlog says 'ath79-wdt' is already registered, maybe they patched the kernel to write these registers earlier, and when it executes normally it is already there? When would ath79-wdt typically be loaded (assuming it should just disable watchdog altogether) in the boot process?


Okay, as it turns out there is indeed another tiny SOT23-5 package near the SoC that I previously overlooked, and it seems to serve as an external HW watchdog.
So I'll go along with the gpio-watchdog package, hoping this can output slightly faster than 1 Hz square wave? The frequencies are indeed different for uboot vs. OEM Linux, I had not believed they would indeed patch uboot to periodically toggle some pin, but indeed they did:


OEM Linux:

seems to be 700ms per cycle.

Thanks for your input, and sorry for the noise :slightly_smiling_face:

1 Like

Board pictures from FCC database aren't great quality [1], so it's hard to tell but that kind of h/w watchdog could be inside a very small package, like SOT-23. If I'm correct, there is something near the main SOC and the RESET_L (pin A67) is connected "somewhere" (I might be totally wrong here but I always prefer to exclude hardware related things first):




Perfect, you got it :slight_smile:

Just a side note here, there might be a way to disable this watchdog. If there are two GPIOs connected to the package, then I bet one is for enable/disable. I just re-checked the datasheet of that reset chip, it uses single input for toggling and can be disabled with high impedance which is not available on the QCA95xx I/O. Usually this is achieved by additional buffer.

Thanks :+1:
Now I need to just figure out the GPIO pin, usually my approach would be uboot console connnection and just md loop to dump the GPIO_IN register and see what changes when messing with the pins, but ins this case messing with that line unfortunately results in a reset... :innocent:

But I hope this GPIO will be same for all devices.... e.g. DAP-2620, DAP-2622, DAP-2662, DAP-3666, DIS-2650AP (my favourite), DIS-3650AP etc... :slightly_smiling_face:

// edit: GPIO8 it is :slightly_smiling_face:

QCA9563 datasheet is easily available, so I would just try the hardware approach and use meter to find the I/O.

Popular reset circuit chip in hardware manufactured in Taiwan:

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.