From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Walle Date: Sun, 04 Oct 2020 16:55:32 +0200 Subject: [PATCH 2/2] watchdog: add watchdog behavior configuration In-Reply-To: <4118667.1601039047@gemini.denx.de> 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> <4118667.1601039047@gemini.denx.de> Message-ID: <5cde7abe86717966c89211d921177505@walle.cc> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi all, Am 2020-09-25 15:04, schrieb Wolfgang Denk: > Dear Heinrich Schuchardt, > > In message you wrote: >> >> > Any so-called "watchdog" that can be disabled / switched off by >> > software is not really woth this name. As such, the concept of >> > disabling a watchdog in software, is misleading at best and should >> > never ibe implemented. >> >> If we want to boot UEFI payloads, we will have to follow the UEFI >> specification even if we think it is not perfect. > > That's perfectly OK. But if the OS expects that the watchdog is > disabled, then we should not enable it in U-Boot in the first place. > > Keep in ind that any real watchdog (which is worth the money and the > name) _cannot_ be disabled by software once it was started. How do we proceed here? There seems to be no final conclusion what to do. I guess one thing we agree on is that after a system is booted with bootefi the watchdog should be disabled. So Wolfgang argues, that the watchdog shouldn't be enabled in the first place then. With this patch this would actually be possible, the user could just choose to not enable it at all; if he has a watchdog which can be disabled again, he can choose that behavior too. OTOH Mark argues, that in the bootefi case, the watchdog should be disabled in _any_ case. But that would mean to change the behavior of current boards. So the question is: is this acceptable? So if this is not acceptable, I don't think there will be any changes to this patch (otherwise than having some additional help text). If it is acceptable, I'd stop the watchdog before bootefi unconditionally (and printing a message if SUPERVISE_OS is set), but keep the current logic for bootm. Personally I'd also prefer this, because in the end you'll have a bootloader which can boot an OS via EFI in any case. Tom, you've mentioned the IMX_WATCHDOG with !CONFIG_WDT. One key difference is that without CONFIG_WDT the watchdog is only started if CONFIG_WATCHDOG is enabled (or I missed something here). And I don't think this patch will apply for that case, right? I think in that case the watchdog can't even be stopped; there seems to be only functions to initialize and kick it. Therefore, it also won't be compatible the EFI spec. There might be warning during the build if HW_WATCHDOG && EFI_LOADER is set. With a note which suggest the move to CONFIG_WDT. -michael