Changes between Version 5 and Version 6 of watchdog
- Timestamp:
- 07/29/2020 04:39:33 PM (4 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
watchdog
v5 v6 3 3 4 4 = Watchdog Timer = 5 Gateworks boards provide a hardware watchdog timer that tickles (resets) the hardware device every x amount of seconds. If the hardware watchdog device is not tickled within Y amount of seconds, then reboot.5 Gateworks boards provide both a hardware boot watchdog timer that power cycles the board if boot firmware failed to run as well as SoC watchdogs. 6 6 7 7 Please see details below on the various differences between hardware watchdogs available and software watchdog daemons. … … 17 17 == Hardware == 18 18 19 === GSC Watchdog ===19 === GSC Boot Watchdog === 20 20 This is the most bulletproof watchdog because it runs on the Gateworks System Controller and results in a power-cycle of the board's primary power supply when tripped. Note that this feature is Gateworks specific. 21 21 … … 24 24 * they issue a chip-level reset. Depending on the CPU and board design they may also assert an output signal from the chip, but often this does not or can not reach every peripheral chip in the system. This can result in hangs following chip-level reset. 25 25 26 In contrast the GSC watchdog benfits are:26 In contrast the GSC boot watchdog benefits are: 27 27 * when expired it momentarily disable the board's primary power supply thus acting as a full board power cycle. 28 * is enabled when the board comes out of reset thus it can protect against any software or hardware issue from power-on until your software starts monitoring itself. The enabling of the watchdog is still configurable via a GSC register but because those registers are battery backed by the GSC coin-cell and non-volatile once enabled it stays enabled 28 * is enabled when the board comes out of reset thus it can protect against any software or hardware issue from power-on until your software starts monitoring itself. 29 * no driver is needed. 29 30 30 31 For more info: 31 32 * [wiki:gsc#HardwareWatchdog GSC Watchdog] 32 * [wiki:gsc#GSCDrivers GSC Drivers]33 33 34 34 35 35 === Newport (ARM SBSA) CPU watchdog 36 The Cavinum CN80XX SoC uses the ARM SBSA watchdog. 36 The Cavinum CN80XX SoC uses the ARM SBSA watchdog. The CN80XX external watchdog reset output is also an input to the GSC so that the GSC can power-cycle the board if the SoC watchdog expires. 37 37 38 38 The linux kernel driver({{{drivers/watchdog/sbsa_gwdt.c}}}) defaults to a 10 second timeout … … 65 65 66 66 Most Linux watchdog drivers have a {{{nowayout}}} kernel parameter which can be defaulted at build time via the kernel config {{{CONFIG_WATCHDOG_NOWAYOUT}}} or passed in via a parameter during module loading or via bootargs. Drivers that support this should display the nowayout setting upon driver init. If {{{nowayout=1}}} the driver does not allow the watchdog to be disabled (no way out of the situation). This is desireable in high reliability cases as the normal API behavior is to start the watchdog when {{{/dev/watchdog}}} is opened by the userspace app, and stop/disable the watchdog when it is closed (which can happen if the userspace watchdog process is killed or even crashes). 67 68 Example:69 * GSC watchdog driver with nowayout disabled70 {{{71 #!bash72 [ 0.000000] Kernel command line: console=ttymxc1,115200 root=ubi0:rootfs ubi.mtd=2 rootfstype=ubifs73 [ 3.949752] gsc_wdt watchdog.39: registered watchdog (nowayout=0)74 }}}75 * enabling nowayout at runtime for GSC watchdog driver:76 {{{77 #!bash78 Ventana> setenv extra 'gsc_wdt.nowayout=1'79 Ventana> boot80 ...81 [ 0.000000] Kernel command line: console=ttymxc1,115200 root=ubi0:rootfs ubi.mtd=2 rootfstype=ubifs gsc_wdt.nowayout=182 [ 3.949752] gsc_wdt watchdog.39: registered watchdog (nowayout=1)83 }}}84 67 85 68 Example trying to kill the watchdog: … … 149 132 150 133 151 === OpenWrt procd Watchdog (Modern OpenWrt used in 14-08 BSP and forward)===134 === OpenWrt procd Watchdog === 152 135 While older versions of OpenWrt used the watchdog daemon from busybox, newer versions (including the Gateworks BSP's from 13-06 and forward) implement the watchdog daemon via procd, which is the init process (PID1). Therefore on modern OpenWrt, you will never see the watchdog process when doing a ps. 153 136 … … 181 164 182 165 183 === OpenWrt busybox watchdog (Older OpenWrt used in 13-06 BSP and older) ===184 Older OpenWrt versions such as the one used in the Gateworks 13-06 BSP use the busybox watchdog daemon. This daemon is similar to the procd based watchdog daemon in modern OpenWrt as it does not do any specific system checks - if the service is running it will tickle/reset the watchdog based on its configured period.185 186 There is no uci configuration for the period or frequency, they are hard-coded in the {{{/etc/init.d/watchdog}}} init script for a default timeout of 60 seconds and a tickle frequency of 5 seconds.187 188 usage:189 {{{190 #!bash191 Usage: watchdog [-t N[ms]] [-T N[ms]] [-F] DEV192 193 Periodically write to watchdog device DEV194 195 Options:196 -T N Reboot after N seconds if not reset (default 60)197 -t N Reset every N seconds (default 30)198 -F Run in foreground199 200 Use 500ms to specify period in milliseconds201 }}}202 203 204 Example:205 {{{206 #!bash207 watchdog -t 30 -T 60 /dev/watchdog # reset the watchdog every 30 seconds with 60 second timeout208 }}}209 210 211 166 === Android watchdog daemon === 212 167 The Android OS watchdog daemon is {{{/sbin/watchdog}}} and is implemented in {{{/system/core/init/watchdogd.c}}}. It is kicked off by init and does not perform any specific checks. 213 214 The Ventana Android BSP configures the watchdog for a 30 second timer and resets it every 10 seconds. If the GSC watchdog is enabled it will be used, otherwise the IMX6 SoC watchdog will be used.
