watchdog functionality

we want to understand watchdog functionality in L4T 21.4.

if we enabled watchdog in kernel config (via CONFIG_TEGRA_WATCHDOG=y) then we see /dev/watchdog entry and we can reboot terminal by command cat /dev/watchdog.

we have following queries

  1. as per TRM, there are 5 watchdogs( 1 watchdog per 1 CPU core and 1 for AVP), but we don’t see five entry in /dev/. how to get 5 watchdog entries ?
  2. what will happen if only one CPU core hangs ? will core0 be notified ?
  3. watchdog platform device is registered via board file(arch/arm/mach-tegra/devices.c) and NOT via DTS file. why watchdog is not registered via DTS file ?

My understanding of watchdog is that something in user space writes to a single watchdog. It’s up to a user space program to decide when to write to the watchdog…there are default packages available. If you wanted to use criteria different from the existing user space software, you’d have to write your own user space program to provide the write “heartbeat”.

Are you trying to accomplish anything special? Core 0 handles hardware IRQ, and other than core 0, I’m not sure if any individual core could be considered fatally locked up. A description of the situation you are guarding against would help.

We are not trying to do any thing special. User space program will write heartbeat periodically.

Our question is as TRM mentions about 5 watchdog, how to access all 5 watchdog from user space program ?

Right now we can access only one watchdog via /dev/watchdog.0.

I assume you’re referring to TRM section 7.4.

It looks like at the lowest level it’s simply register access via the TMR controller…see TRM page 20. Base physical address is shown as 6000:5000. First explanation starts in section 7.4. Actual controller information starts in section 7.10.1. This would provide full access to all timers.

You’re probably not looking to make it that difficult, so there is a possibility of some access via /sys to make life easier. The default R21.4 kernel config includes:

CONFIG_WATCHDOG=y
CONFIG_WATCHDOG_CORE=y
CONFIG_WATCHDOG_NOWAYOUT=y
CONFIG_TEGRA_WATCHDOG=y
# CONFIG_TEGRA_WATCHDOG_ENABLE_ON_PROBE is not set
CONFIG_MAX77660_SYSTEM_WATCHDOG=y

I don’t know what user space configuration is available for the Tegra watchdog, but there is some exposure in /sys. Observe:

# find /sys -name '*watchdog*'
/sys/devices/platform/tegra_wdt.0/misc/watchdog0
/sys/class/misc/watchdog0
/sys/class/watchdog

(see also “find /sys -name ‘wdt’”)

The entry for /sys/class/misc/watchdog0 is a symbolic link which points to the /sys/devices/platform/tegra_wdt.0/misc/watchdog0 entry. Presumably this means the driver has configured watchdog 0 of core 0 for use. It may be possible to enable more watchdog timers for the other cores and access them via similar /sys entries, but it looks like code has not yet been written for watchdog1 through 3.

In the kernel source look at arch/arm/mach-tegra/board-ardbeg.c, which is of interest:

#if defined(CONFIG_TEGRA_WATCHDOG)
        &tegra_wdt0_device,
#endif

The reason this is “interesting” is because it ties directly to watchdog timer 0 via variable tegra_wdt0_device, and watchdog timer 0 is the one enabled and accessible via /sys in the default configuration. Grep through the rest of the kernel source does not show any occurrence of tegra_wdt#_device other than ‘#’ of ‘0’. You could probably track down the tegra_wdt0_device code and make similar code available as tegra_wdt1_device through tegra_wdt3_device and have full access via simple /sys interface (at least to the extent of the existing watchdog0 code).

thanks linuxdev for information