AM3351: watchdog clarifications

Hello Michael,

It will take me a couple of days to circle back to your thread. Please ping the thread if I do not have a response for you by midweek.

Regards,

Nick

Hello Michael,

Apologies for the delayed response - I ran out of time before I'm on vacation for the rest of March. I am reassigning your thread to our uboot owner to comment from that side.

Regards,

Nick

team,

customer ran some more experiments and I copy the reports along with request for clarifications below

1. I think we were mistaken that u-boot wasn’t working.  Using the wdt expire command it didn’t fire (perhaps not supported by the omap3 driver here).  Instead, I put some while(1); loops in various places and it reboots. (good)
   1. Even though we are passing 60 seconds into the WDT setup functions, in u-boot the timeout seems to consistently occur after only 50s.   I wonder why the discrepancy?

1. It looks like during Linux boot (around the 0.75s mark), we load the wdt module.  This seems to disable the watchdog until we later turn it back on from userspace.  I see now there is a watchdog module parameter enable_early.  Turning this on, it seems to help protect more of the kernel boot
   1. Invoking a kernel panic with this during boot, the system restarts as we expect (good)
   2. I purposely made a driver hang (by adding a while(1); loop to the GPIO driver probe)

1. The system however still seems to pet the watchdog even though this driver has “hung” and the system is not booting further.  This seems to sort of defeat part of the purpose of the watchdog.  I’m wondering if this is a side effect of how the Kernel itself is implemented, or something else and how this behavior can be fixed.  (bad)

e.g.:

[    0.755948] wdt ping

[    0.756133] omap_wdt: OMAP Watchdog Timer Rev 0x01: initial timeout 60 sec

[    0.756156] starting wdt

[    0.778742] 48022000.serial: ttyS1 at MMIO 0x48022000 (irq = 19, base_baud = 3000000) is a 8250

[    2.795339] printk: console [ttyS1] enabled

[    2.840709] ti-sysc: probe of 48040000.target-module failed with error -16

[    2.904373] gpio gpiochip0: (gpio-0-31): not an immutable chip, please consider fixing it!

[    2.935976] WHILE(1) LOOP IN OMAP GPIO DRIVER

[   30.756195] wdt ping

[   60.758656] wdt ping

[   90.761071] wdt ping

Hi Nick,

How are we doing on Michael's follow up? Any updates? Thank you!

The WDT time-out is configured in u-boot
git.ti.com/.../omap_wdt.c
/* Hardware timeout in seconds */
#define WDT_HW_TIMEOUT 60

For example, if JTAG is used to "halt" SPL/u-boot running, WARM RESET would be trigged after WDT time-out.

I'm passing it back to my colleague on WDT configuration in kernel.

Best,
-Hong

Hello,

Watchdog timing out after 50 seconds, even though it is set to 60 seconds

Is this an EVM board, or a custom board? What clock source are you using for the RTC? What are your clock source settings?

e.g., if you are providing a 32.768kHz reference oscillator into OSC1 that is getting routed to the RTC, I would expect you to see a timeout at almost exactly 60 seconds. If you were using the higher frequency peripheral PLL oscillator as your clock source, it would depend on your frequency divider settings.

If you are using the internal 32k RC oscillator, our hardware folks have told me that RC oscillators are NOT designed to be used for runtime usecases where you actually need precise timing. They were described to me as "there to make sure that SOME kind of clock signal is coming into the peripheral so that it can keep running", and often only used during bootup or until the more precise clock sources can get set up.

What is the purpose of a watchdog timer? 

From a hardware perspective, it is very simple: The timer counts down, and if the hardware timer is ever allowed to reach 0, it resets the system.

From a software perspective, my (limited) understanding is that it is more complex. If the entire processor locks up, then the watchdog will no longer be serviced - that is easy. But what about the usecase where only a particular software thread has hung, while the rest of the system continues running?

As far as I can tell, it comes down to how you choose to program your code. E.g., if you set up your code so that a userspace Daemon pets the watchdog, then the watchdog will trigger if userspace locks up. If you set your code so that your specific userspace application pets the watchdog, then the watchdog will trigger if your specific application is unable to run.

At this point in time, I have not looked into enabling watchdog after uboot, but before Linux finishes booting, so I'm not totally sure how the "petting" code interacts with the rest of Linux boot.

I hope this helps,

Nick