Hi Michael, Hi Chris,
On 15.09.20 12:44, Chris Packham wrote:
On Tue, 15 Sep 2020, 7:54 PM Michael Walle, michael@walle.cc wrote:
Am 2020-09-15 09:44, schrieb Rayagonda Kokatanur: > On Tue, Sep 15, 2020 at 12:56 PM Michael Walle <michael@walle.cc> > wrote: >> >> Hi Stefan, >> >> it appears that since commit 06985289d45 ("watchdog: Implement generic >> watchdog_reset() version") - by default - the first watchdog is >> started >> unconditionally if CONFIG_WDT is set but never stopped before booting >> the operating system. >> >> Shouldn't it also be stopped uncondionally? What's worse is that on >> one >> board/arch the watchdog is stopped in arch_preboot_os() which is never >> called in the bootefi case. So even if I'd do a workaround and stop it >> manually in my board code, I couldn't do that consistently for >> bootm/bootefi. >> >> Or am I missing something here? > > Define CONFIG_WATCHDOG. > This takes care of resetting wdt. Yes as along as you're inside the bootloader, but when u-boot hands control over the OS the watchdog is not serviced anymore; which wouldn't be a problem per se, but it is enabled unconditionally by u-boot.Just to add some data. At $dayjob we use this behaviour as a failsafe to make sure our userspace gets to a point where it is servicing the watchdog.
Yes, this is exactly how this is supposed to work AFAIK.
Michael, are you sure that the watchdog was disabled in U-Boot when booting into the OS before this patch?
That said having a leave-wdt-running environment variable would work for our use case.
I would rather use it the other way around. Something like "wdt-stop- pre-os" to optionally stop the WDT before booting into the OS.
Remark: IMHO, if you don't use the WDT in the OS, it does not make much sense to enable the WDT in U-Boot.
Thanks, Stefan