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

[Wolfgang Denk <wd@denx.de>]

Dear Heinrich,

In message <ef24629c-2c57-c681-eae5-2d034abfbd9b@gmx.de> you wrote:
>
> This is why UEFI API has the EFI_BOOT_SERVICES.SetWatchdogTimer()
> service which allows to set the timeout or disable the watchdog completely. 

UEFI may have any APIs it wants, this will not change the underlying
hardware in any way.  A proper watchdog implementation has
write-once register to prime the watchdog.  Once it is armed, there
will be no other way to disarm it except for a hardware reset.

> The Linux EFI stub calls EFI_BOOT_SERVICES.ExitBootServices. According
> to the UEFI spec this is the moment when the watchdog must be disabled.
>
> So in a UEFI environment you can only monitor the time in U-Boot, in
> GRUB and part of the Linux EFI stub. You cannot monitor if Linux reaches
> the command prompt using the watchdog provided by the UEFI firmware.
> Linux could set up its own watchdog that takes over.

The logical approach is to leave the watchdog uninitialized in
U-Boot, and activate it in Linux only.

Or, if you need to be able to detect and reset a system hanging in
the boot process, then simply do not use UEFI at all.  Apparently it
is unsuitable for any reliable systems.

I mean - when there are mandatory phases in EFI boot where the WD
_must_ be disabled, then what happens when booting hangs exactly
then?  then you are exactly in the same position as if not enabling
the WD at all in U-Boot.


> If we want to have a hardware based watchdog in the UEFI context, we
> need a U-Boot internal API by which we can enable and disable a hardware
> watchdog with an arbitrary duration (>> 5 min) with 1 second resolution.
> Then our implementation of SetWatchdogTimer() could call into this API.

Sorry, but please stop ignoring hardware properties!

Yes, eventually we could implement a software layer that triggers
the watchdog _while_U-Boot_is_running.  But as soon as U-Boot loats
and starts the next payload, this code is gone.

For example, assume a hardware watchdog with a fixed time-out
interval of 1.6 seconds that cannot be disabled at all in software -
it starts running with power on. [Note that this is not a theoretical
example, but real life.]

We can deal with this in U-Boot just fine.  We can also deal with
this booting Linux - 1.6 seconds is usually enough to get the needed
driver initialized in Linux, too.  But as soon as U-Boot starts the
first payload, you have only those 1.6 seconds - so if your payload
does not trigger the WD, you lose.

You can implement software services only within the capabilities of
the given hardware.

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
If a packet hits a pocket on a socket on a port,
And the bus is interrupted as a very last resort,
And the address of the memory makes your floppy disk abort,
Then the socket packet pocket has an error to report! - Ken Burchill?