[PATCH 1/1] efi_loader: stop watchdogs in ExitBootServices()

[Heinrich Schuchardt]

On 2/7/23 16:29, Michael Walle wrote:
>>>>>> Honestly, not really? Some good number of SoCs will start the 
>>>>>> watchdog
>>>>>> in ROM and these are also the ones that don't allow you to turn it 
>>>>>> off.
>>>>>
>>>>> I hope not, that sounds really risky. How would you debug such a 
>>>>> platform?
>>>>
>>>> _Every single_ custom piece of industrial (as opposed to 
>>>> consumer-grade)
>>>> hardware I've worked on as a consultant has had an external,
>>>> always-running, gpio-petted watchdog. It's simply just something that
>>>> the hardware designers include, and in some cases that's even due to
>>>> certification requirements. So an always-running, cannot-be-turned-off,
>>>> watchdog is a real thing, in real hardware, and if specs don't account
>>>> for that, well, the spec is just paper, and we can ignore it.
>>>
>>> I agree. But on the other hand, you cannot assume or force the OS to
>>> have a watchdog driver in the general case - which is as I understand
>>> it - one goal of EFI.
>>>
>>> Obviously, there are watchdogs that can be disabled and some which
>>> cannot. I don't want to argue about the advantages and disadvantages.
>>>
>>> For watchdogs which cannot be turned off, we can't really do anything
>>> anyway after the handoff to the OS - except increasing its timeout if
>>> thats possible.
>>>
>>> For watchdogs that can be disabled (and are enabled in u-boot of 
>>> course),
>>> there seems to be two use-cases:
>>>   (1) embedded EFI boot, that is you know exactly what you are 
>>> booting, i.e.
>>>       self compiled kernel with a watchdog driver
>>>   (2) booting a general OS via EFI, think of a debian boot CD for 
>>> example.
>>>
>>> I agree, that for (1) the watchdog shouldn't be disabled. For (2) you
>>> cannot assume the booting OS has a driver for the watchdog, let it be an
>>> older version of a distribution which just haven't the SoC watchdog 
>>> driver
>>> enabled or maybe because there is no driver for it at all (yet).
>>>
>>> Is there a way, to have the watchdog disabled for case (2) while also
>>> having the possibity to use bootm/booti/bootz and keep the watchdog
>>> enabled? Basically I want the following:
>>>
>>> (1) board boots with watchdog enabled
>>> (2) u-boot services watchdog
>>> (3a) booting embedded linux with booti (watchdog enabled) or
>>> (3b) booting generic OS with bootefi (watchdog disabled)
>>>
>>> The missing case is booting an embedded linux with bootefi, which
>>> would be nice to have. But I don't really see it as a use-case for
>>> our board.
>>>
>>> -michael
>>
>> For SUNXI boards disabling CONFIG_WATCHDOG_AUTOSTART solved the
>> problem with the very short maximum expiration time of the watchdog.
> 
> I can't follow you here. What "very short maximum expiration time"?
> With CONFIG_WATCHDOG_AUTOSTART disabled, the watchdog won't be kicked
> by u-boot, right? wdt->running will never be set to true and
> wdt_cyclic() will be a noop.
> 
> -michael
The sunxi boards failed to boot with CONFIG_WATCHDOG_AUTOSTART because 
16s is too short for Linux to install a watchdog driver. With 
CONFIG_WATCHDOG_AUTOSTART=n the watchdog is not running and the boards boot.

Best regards

Heinrich