[PATCH 2/2] watchdog: add watchdog behavior configuration

[Wolfgang Denk]

Dear Mark,

In message <8ba616a732f62f9c at bloch.sibelius.xs4all.nl> you wrote:
> > > p. 40
> > > "The causes of reset could be power-on reset, external hard reset,
> > > brownout detected, watchdog timer elapse, sleep-mode wakeup, etc., which
> > > machine-mode UEFI system firmware has to distinguish."
> > 
> > This is possible only if the hardware actually supports such
> > distinction.  In many cases of actual hardware I've seen a watchdog
> > reset is just the same as an external hard reset, and brownout
> > detection does not exist.
>
> This is RISC-V specific, and RISC-V apparently has an architected
> register that communicates the reset cause.  Even then the text
> immediately before the text quoted by Heinrich allows for hardware
> that can't distinguish to simply report 0 in that register implying
> "the most complete reset (e.g., hard reset)".

Sorry, I disagree here.  This is in no way RISC-V specific, it is a
generic hardware thing.  If your board design has an external
watchdog chip which simply pulls the main reset line, you CANNOT
distinguish between the watchdog triggering or the user pressing the
reset button.

The reset reason register can only show information it has access
to, i. e. when a SoC-internal WD triggers.

> That doesn't change the fact that enabling a hardware watchdog timer
> that resets the system is problematic for the EFI boot path in U-Boot.
> The typical EFI boot path is:
>
>   UEFI Firmware ->       EFI OS loader       ->    OS kernel
>     (U-Boot)       (GRUB, OpenBSD's EFIBOOT)    (Linux, OpenBSD)
>
> Here the EFI OS loader is hardware agnostic and only supposed to use
> EFI interfaces to do its job.  As such it cannot reset or disable the
> watchdog hardware.  Maybe it can do its job of loading and starting
> the OS kernel before a hardware watchdog timer expires.  But if there
> is any user interaction required the timer will at some point expire
> and reset the system in the middle of the user interaction.
>
> Even if the EFI OS loader does its job before the hardware watchdog
> timer expires, there is no guarantee that the OS kernel has the driver
> necesary to reset/disable the hardware watchdog.  Or even if it does
> have such a driver, loading/attaching it may take too much time.

I guess this is just another deficiency in the (U)EFI design...

> In my opinion enabling a hardware watchdo timer only makes sense if
> U-Boot and the loaded OS kernel are tightly coupled.  Which is a use
> case where one would probably not use the EFI boot path in the first
> place and use a more traditional U-Boot bootpath such as "bootm"
> instead.

Agreed.  I would never run these software layers on a system that
requires to be secure/reliable/robust/reliable/robust.

> At this point UEFI isn't really targeted at "deeply embedded" systems
> that require a hardware watchdog to implement guaranteed recovery from
> software failures.  If there is a desire to use the EFI boot path in
> this scenario someone should probably lobby the UEFI folks to add a
> EFI runtime service to reset the hardware watchdog that can be called
> by the EFI OS Loader and the OS to prevent the timer from expiring.

Or, as I mentioned before: if you cannot make sure to trigger the
watchdog in a sensible way, leave it off until you have reached a
software state where this can be done. Only then enable it (keeping
in mind that this may be a write-once register somehwere, so you
cannot assume to disable in other ways than a hardware reset).

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Being schizophrenic is better than living alone.