U-Boot: arm the watchdog (CONFIG_WATCHDOG_AUTOSTART) #34

New issue

Closed

opened 2026-08-28 05:59:29 +00:00 by tiagoagueda · 1 comment

tiagoagueda commented

2026-08-28 05:59:29 +00:00

Owner

The sunxi watchdog is compiled into U-Boot and never started, so a hang in U-Boot
proper is terminal on a board with no remote power control.

Measured

From ~/a80/u-boot/.config on ouranos (HEAD 6a561883):

CONFIG_WATCHDOG=y
CONFIG_WDT=y
CONFIG_WDT_SUNXI=y
CONFIG_WATCHDOG_TIMEOUT_MSECS=16000
# CONFIG_WATCHDOG_AUTOSTART is not set     <- nothing ever starts it
# CONFIG_CMD_WDT is not set

Everything needed is already there. drivers/watchdog/Kconfig:14 carries
default n if ARCH_SUNXI, so the symbol is off by platform default rather than by
any decision made here.

Why it is safe

Checked before proposing, because an armed watchdog crossing into the kernel could
otherwise cause a reset loop:

wdt_stop_all() has exactly one caller in the tree (board/alliedtelesis/x530/x530.c:126),
so U-Boot does not disarm the watchdog at bootm. It stays armed into the kernel.
sunxi_wdt_probe() calls sunxi_wdt_stop() before registering the device
(drivers/watchdog/sunxi_wdt.c), so the kernel disarms it at probe.
systemd then re-arms it at 15 s per 38-userspace-hardening.md.

Net effect: protection covers U-Boot, is handed off cleanly, and no reset loop is
possible. The kernel also has CONFIG_WATCHDOG_HANDLE_BOOT_ENABLED=y as a second net.

Change

CONFIG_WATCHDOG_AUTOSTART=y
CONFIG_CMD_WDT=y

CMD_WDT is worth having so the watchdog can be exercised from the U-Boot prompt
rather than only by inducing a hang.

Does not cover

SPL (see the SPL watchdog issue) — which is where the one real outage happened.
A board parked at an interactive prompt: U-Boot services the watchdog from its own
idle loop, so a prompt looks healthy to it. That is the BOOT_RETRY issue.

Acceptance

wdt list at the U-Boot prompt shows the device armed.
A deliberate hang in U-Boot proper resets the board within ~16 s.
Normal boot to Linux is unaffected; dmesg still shows sunxi-wdt probing and
systemd re-arming watchdog0.

Addresses gaps 2 and 3 of 41-production-plan.md.

The sunxi watchdog is compiled into U-Boot and never started, so a hang in U-Boot proper is terminal on a board with no remote power control. ## Measured From `~/a80/u-boot/.config` on ouranos (HEAD `6a561883`): ``` CONFIG_WATCHDOG=y CONFIG_WDT=y CONFIG_WDT_SUNXI=y CONFIG_WATCHDOG_TIMEOUT_MSECS=16000 # CONFIG_WATCHDOG_AUTOSTART is not set <- nothing ever starts it # CONFIG_CMD_WDT is not set ``` Everything needed is already there. `drivers/watchdog/Kconfig:14` carries `default n if ARCH_SUNXI`, so the symbol is off by platform default rather than by any decision made here. ## Why it is safe Checked before proposing, because an armed watchdog crossing into the kernel could otherwise cause a reset loop: - `wdt_stop_all()` has exactly one caller in the tree (`board/alliedtelesis/x530/x530.c:126`), so U-Boot does **not** disarm the watchdog at `bootm`. It stays armed into the kernel. - `sunxi_wdt_probe()` calls `sunxi_wdt_stop()` before registering the device (`drivers/watchdog/sunxi_wdt.c`), so the kernel disarms it at probe. - systemd then re-arms it at 15 s per [38-userspace-hardening.md](38-userspace-hardening.md). Net effect: protection covers U-Boot, is handed off cleanly, and no reset loop is possible. The kernel also has `CONFIG_WATCHDOG_HANDLE_BOOT_ENABLED=y` as a second net. ## Change ``` CONFIG_WATCHDOG_AUTOSTART=y CONFIG_CMD_WDT=y ``` `CMD_WDT` is worth having so the watchdog can be exercised from the U-Boot prompt rather than only by inducing a hang. ## Does not cover - SPL (see the SPL watchdog issue) — which is where the one real outage happened. - A board parked at an interactive prompt: U-Boot services the watchdog from its own idle loop, so a prompt looks healthy to it. That is the `BOOT_RETRY` issue. ## Acceptance - `wdt list` at the U-Boot prompt shows the device armed. - A deliberate hang in U-Boot proper resets the board within ~16 s. - Normal boot to Linux is unaffected; `dmesg` still shows `sunxi-wdt` probing and systemd re-arming `watchdog0`. Addresses gaps 2 and 3 of [41-production-plan.md](41-production-plan.md).

tiagoagueda commented

2026-08-28 17:15:29 +00:00

Author

Owner

Done 2026-08-28. Exactly the two symbols this issue specified.

WDT:   Started watchdog@6000ca0 with servicing every 1000ms (16s timeout)
WDT:   Started watchdog@8001000 with servicing every 1000ms (16s timeout)

Two things the analysis here did not predict, both good:

It arms both instances, including R_WDT in the always-on domain. That turned out to
matter for #37, which arms the same R_WDT in SPL and hands it to this.
U-Boot services the watchdog while sitting at its own prompt. That was worth confirming
rather than assuming - an armed 16 s watchdog could have made interactive serial recovery
impossible. Proven incidentally while testing #35, where the board sat at => for a full
60 s without resetting.

The handoff is as this issue described: Linux disarms in sunxi_wdt_probe() and systemd
re-arms at 15 s. See 50-uboot-resilience.md.

**Done 2026-08-28.** Exactly the two symbols this issue specified. ``` WDT: Started watchdog@6000ca0 with servicing every 1000ms (16s timeout) WDT: Started watchdog@8001000 with servicing every 1000ms (16s timeout) ``` Two things the analysis here did not predict, both good: - **It arms both instances**, including R_WDT in the always-on domain. That turned out to matter for #37, which arms the same R_WDT in SPL and hands it to this. - **U-Boot services the watchdog while sitting at its own prompt.** That was worth confirming rather than assuming - an armed 16 s watchdog could have made interactive serial recovery impossible. Proven incidentally while testing #35, where the board sat at `=>` for a full 60 s without resetting. The handoff is as this issue described: Linux disarms in `sunxi_wdt_probe()` and systemd re-arms at 15 s. See `50-uboot-resilience.md`.

tiagoagueda closed this issue

2026-08-28 17:15:29 +00:00

tiagoagueda referenced this issue

2026-08-28 17:15:30 +00:00

U-Boot: arm a watchdog in SPL — the stage that actually hung #37

tiagoagueda referenced this issue

2026-08-29 07:41:10 +00:00

U-Boot: enable CMD_MEMTEST and validate the 3.5 GiB DRAM geometry before upstreaming #38

tiagoagueda referenced this issue from a commit

2026-08-29 11:58:10 +00:00

U-Boot recovers from four things that used to need a physical visit

tiagoagueda referenced this issue from a commit