From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wolfgang Denk Date: Sat, 26 Sep 2020 16:40:56 +0200 Subject: [PATCH 2/2] watchdog: add watchdog behavior configuration In-Reply-To: References: <20200923164527.26894-1-michael@walle.cc> <20200923164527.26894-2-michael@walle.cc> <8ba6107a460b8647@bloch.sibelius.xs4all.nl> <20200923171409.GT14816@bill-the-cat> <8070fb73-d42b-fa66-98a6-a2b9926b2d3f@gmx.de> <20200923173504.GV14816@bill-the-cat> <20200924131931.GF14816@bill-the-cat> <4098208.1601022997@gemini.denx.de> <20200925130039.GI14816@bill-the-cat> <81e467f1-aff3-a54d-5f7e-3b8f5390f410@gmx.de> <4185392.1601109931@gemini.denx.de> <8ba616a732f62f9c@bloch.sibelius.xs4all.nl> Message-ID: <7920.1601131256@gemini.denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Dear Heinrich, In message 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?