BCM SoC hardware watchdog and systemd RuntimeWatchdog: arm state across warm reboot vs power cycle
0 reputation · 14 Jan 2022, 18:44 UTC
Goal is to use the Broadcom SoC hardware watchdog exposed by the bcm2835-wdt driver via /dev/watchdog together with systemd RuntimeWatchdogSec for unattended Raspberry Pi operation.
The integration requires the kernel driver to be present, userspace to keep the watchdog alive, and a clear definition of when the watchdog is armed or disarmed across boot transitions. Behavior differs between generations, and the nowayout parameter changes whether a clean close is possible. RuntimeWatchdogSec and ShutdownWatchdogSec are separate settings.
Documentation is inconsistent about whether the watchdog remains armed across a warm reboot versus a full power cycle, and how firmware or bootloader state influences that persistence across Pi generations.
Does the watchdog remain armed after a warm reboot on BCM2711/2712 and Pi 5 RP1 watchdog platforms? Under what conditions does firmware or bootloader clear the SoC counter? How should RuntimeWatchdogSec be chosen to avoid clamping or boot loops given generation-specific hardware limits?