[PATCH] efi_loader: stop watchdog devices in ExitBootServices()

[PATCH] efi_loader: stop watchdog devices in ExitBootServices()

[Carlo Caione]

U-Boot can autonomously start a hardware watchdog
(CONFIG_WATCHDOG_AUTOSTART, default y) and service it from its main
loop, but the EFI boot path never stops it: efi_exit_boot_services()
tears the devices down without calling wdt_stop_all(), and a watchdog
driver without a .remove hook leaves the hardware ticking across the
firmware-to-OS handoff.

An EFI-booted OS that does not take over the SoC watchdog within the
remaining timeout is reset mid-boot at a wall-clock-dependent point.

The UEFI specification (v2.11, section 7.5 "Miscellaneous Boot
Services", EFI_BOOT_SERVICES.SetWatchdogTimer()) is explicit about the
one watchdog it allows across the handoff:

  "The watchdog timer is only used during boot services. On
   successful completion of EFI_BOOT_SERVICES.ExitBootServices() the
   watchdog timer is disabled."

U-Boot's UEFI watchdog (an EFI timer event) complies by construction. A
platform watchdog silently surviving the handoff defeats the purpose of
that rule: the OS has no generic way to know it is running, let alone to
service it.

Stop all watchdog devices in efi_exit_boot_services(), before the device
teardown.

Signed-off-by: Carlo Caione <ccaione@baylibre.com>
---
 lib/efi_loader/efi_boottime.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index de57823bd44..9588d9b9739 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -22,6 +22,7 @@
 #include <u-boot/crc.h>
 #include <usb.h>
 #include <watchdog.h>
+#include <wdt.h>
 #include <asm/global_data.h>
 #include <linux/libfdt_env.h>
 
@@ -2245,6 +2246,8 @@ static efi_status_t EFIAPI efi_exit_boot_services(efi_handle_t image_handle,
 		if (IS_ENABLED(CONFIG_DM_ETH))
 			eth_halt();
 		board_quiesce_devices();
+		if (IS_ENABLED(CONFIG_WDT))
+			wdt_stop_all();
 		dm_remove_devices_active();
 	}
 
-- 
2.55.0

Re: [PATCH] efi_loader: stop watchdog devices in ExitBootServices()

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1619 bytes --]

On Sat, Jul 04, 2026 at 03:52:29PM +0200, Carlo Caione wrote:

> U-Boot can autonomously start a hardware watchdog
> (CONFIG_WATCHDOG_AUTOSTART, default y) and service it from its main
> loop, but the EFI boot path never stops it: efi_exit_boot_services()
> tears the devices down without calling wdt_stop_all(), and a watchdog
> driver without a .remove hook leaves the hardware ticking across the
> firmware-to-OS handoff.
> 
> An EFI-booted OS that does not take over the SoC watchdog within the
> remaining timeout is reset mid-boot at a wall-clock-dependent point.
> 
> The UEFI specification (v2.11, section 7.5 "Miscellaneous Boot
> Services", EFI_BOOT_SERVICES.SetWatchdogTimer()) is explicit about the
> one watchdog it allows across the handoff:
> 
>   "The watchdog timer is only used during boot services. On
>    successful completion of EFI_BOOT_SERVICES.ExitBootServices() the
>    watchdog timer is disabled."
> 
> U-Boot's UEFI watchdog (an EFI timer event) complies by construction. A
> platform watchdog silently surviving the handoff defeats the purpose of
> that rule: the OS has no generic way to know it is running, let alone to
> service it.
> 
> Stop all watchdog devices in efi_exit_boot_services(), before the device
> teardown.
> 
> Signed-off-by: Carlo Caione <ccaione@baylibre.com>

NAK. We have had this come up before, and in short, the UEFI
specification needs to be fixed here, as generally speaking a watchdog
should never be stopped, as that leaves a gap where the system can hang
and thus defeat the point of having enabled a watchdog.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH] efi_loader: stop watchdog devices in ExitBootServices()

[Carlo Caione]

> On 4 Jul 2026, at 16:32, Tom Rini <trini@konsulko.com> wrote:
> 
> On Sat, Jul 04, 2026 at 03:52:29PM +0200, Carlo Caione wrote:
> 
>> U-Boot can autonomously start a hardware watchdog
>> (CONFIG_WATCHDOG_AUTOSTART, default y) and service it from its main
>> loop, but the EFI boot path never stops it: efi_exit_boot_services()
>> tears the devices down without calling wdt_stop_all(), and a watchdog
>> driver without a .remove hook leaves the hardware ticking across the
>> firmware-to-OS handoff.
>> 
>> An EFI-booted OS that does not take over the SoC watchdog within the
>> remaining timeout is reset mid-boot at a wall-clock-dependent point.
>> 
>> The UEFI specification (v2.11, section 7.5 "Miscellaneous Boot
>> Services", EFI_BOOT_SERVICES.SetWatchdogTimer()) is explicit about the
>> one watchdog it allows across the handoff:
>> 
>>  "The watchdog timer is only used during boot services. On
>>   successful completion of EFI_BOOT_SERVICES.ExitBootServices() the
>>   watchdog timer is disabled."
>> 
>> U-Boot's UEFI watchdog (an EFI timer event) complies by construction. A
>> platform watchdog silently surviving the handoff defeats the purpose of
>> that rule: the OS has no generic way to know it is running, let alone to
>> service it.
>> 
>> Stop all watchdog devices in efi_exit_boot_services(), before the device
>> teardown.
>> 
>> Signed-off-by: Carlo Caione <ccaione@baylibre.com>
> 
> NAK. We have had this come up before, and in short, the UEFI
> specification needs to be fixed here, as generally speaking a watchdog
> should never be stopped, as that leaves a gap where the system can hang
> and thus defeat the point of having enabled a watchdog.


Fair enough.

For the record, the failure that motivated this: a pristine Ubuntu 26.04 arm64 image on a MediaTek Genio 700 EVK dies silently about 60 seconds after ExitBootServices(), 100% reproducible, at a wall-clock dependent point. The generic kernel ships the watchdog driver as a module, so nothing services the watchdog in time, and nothing tells the OS that it is running. From the user's side this is indistinguishable from broken firmware.

In the meantime, is the accepted pattern hooking up a wdt_stop_all() in the EFI path via board_quiesce_devices()? That keeps the watchdog armed for the whole firmware lifetime and makes the handoff behaviour the board maintainer's call.

Cheers,

—
Carlo Caione

Re: [PATCH] efi_loader: stop watchdog devices in ExitBootServices()

[Mark Kettenis]

> From: Carlo Caione <ccaione@baylibre.com>
> Date: Sat, 4 Jul 2026 17:21:25 +0200
> 
> > On 4 Jul 2026, at 16:32, Tom Rini <trini@konsulko.com> wrote:
> > 
> > On Sat, Jul 04, 2026 at 03:52:29PM +0200, Carlo Caione wrote:
> > 
> >> U-Boot can autonomously start a hardware watchdog
> >> (CONFIG_WATCHDOG_AUTOSTART, default y) and service it from its main
> >> loop, but the EFI boot path never stops it: efi_exit_boot_services()
> >> tears the devices down without calling wdt_stop_all(), and a watchdog
> >> driver without a .remove hook leaves the hardware ticking across the
> >> firmware-to-OS handoff.
> >> 
> >> An EFI-booted OS that does not take over the SoC watchdog within the
> >> remaining timeout is reset mid-boot at a wall-clock-dependent point.
> >> 
> >> The UEFI specification (v2.11, section 7.5 "Miscellaneous Boot
> >> Services", EFI_BOOT_SERVICES.SetWatchdogTimer()) is explicit about the
> >> one watchdog it allows across the handoff:
> >> 
> >>  "The watchdog timer is only used during boot services. On
> >>   successful completion of EFI_BOOT_SERVICES.ExitBootServices() the
> >>   watchdog timer is disabled."
> >> 
> >> U-Boot's UEFI watchdog (an EFI timer event) complies by construction. A
> >> platform watchdog silently surviving the handoff defeats the purpose of
> >> that rule: the OS has no generic way to know it is running, let alone to
> >> service it.
> >> 
> >> Stop all watchdog devices in efi_exit_boot_services(), before the device
> >> teardown.
> >> 
> >> Signed-off-by: Carlo Caione <ccaione@baylibre.com>
> > 
> > NAK. We have had this come up before, and in short, the UEFI
> > specification needs to be fixed here, as generally speaking a watchdog
> > should never be stopped, as that leaves a gap where the system can hang
> > and thus defeat the point of having enabled a watchdog.
> 
> 
> Fair enough.
> 
> For the record, the failure that motivated this: a pristine Ubuntu
> 26.04 arm64 image on a MediaTek Genio 700 EVK dies silently about 60
> seconds after ExitBootServices(), 100% reproducible, at a wall-clock
> dependent point. The generic kernel ships the watchdog driver as a
> module, so nothing services the watchdog in time, and nothing tells
> the OS that it is running.

The OS should probably assume that the watchdog timer is running.  So
the watchdog timer drivers should probably be built in.  Or at least
they should be present on initrd.  If 60 seconds isn't good enough,
you could look into extending the watchdog timeout (but the hardware
might no support that).

> In the meantime, is the accepted pattern hooking up a wdt_stop_all()
> in the EFI path via board_quiesce_devices()? That keeps the watchdog
> armed for the whole firmware lifetime and makes the handoff
> behaviour the board maintainer's call.

But it would make it impossible for users that want the watchdog
enabled across the handover to use the EFI boot path.

If you really can't fix the OS, the more-or-less accepted pattern
would be to disable CONFIG_WATCHDOG_AUTOSTART.  That at least allows
users that want the watchdog to remain active to enable the watchdog
through a u-boot script.

Re: [PATCH] efi_loader: stop watchdog devices in ExitBootServices()

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2883 bytes --]

On Sat, Jul 04, 2026 at 05:21:25PM +0200, Carlo Caione wrote:
> 
> 
> > On 4 Jul 2026, at 16:32, Tom Rini <trini@konsulko.com> wrote:
> > 
> > On Sat, Jul 04, 2026 at 03:52:29PM +0200, Carlo Caione wrote:
> > 
> >> U-Boot can autonomously start a hardware watchdog
> >> (CONFIG_WATCHDOG_AUTOSTART, default y) and service it from its main
> >> loop, but the EFI boot path never stops it: efi_exit_boot_services()
> >> tears the devices down without calling wdt_stop_all(), and a watchdog
> >> driver without a .remove hook leaves the hardware ticking across the
> >> firmware-to-OS handoff.
> >> 
> >> An EFI-booted OS that does not take over the SoC watchdog within the
> >> remaining timeout is reset mid-boot at a wall-clock-dependent point.
> >> 
> >> The UEFI specification (v2.11, section 7.5 "Miscellaneous Boot
> >> Services", EFI_BOOT_SERVICES.SetWatchdogTimer()) is explicit about the
> >> one watchdog it allows across the handoff:
> >> 
> >>  "The watchdog timer is only used during boot services. On
> >>   successful completion of EFI_BOOT_SERVICES.ExitBootServices() the
> >>   watchdog timer is disabled."
> >> 
> >> U-Boot's UEFI watchdog (an EFI timer event) complies by construction. A
> >> platform watchdog silently surviving the handoff defeats the purpose of
> >> that rule: the OS has no generic way to know it is running, let alone to
> >> service it.
> >> 
> >> Stop all watchdog devices in efi_exit_boot_services(), before the device
> >> teardown.
> >> 
> >> Signed-off-by: Carlo Caione <ccaione@baylibre.com>
> > 
> > NAK. We have had this come up before, and in short, the UEFI
> > specification needs to be fixed here, as generally speaking a watchdog
> > should never be stopped, as that leaves a gap where the system can hang
> > and thus defeat the point of having enabled a watchdog.
> 
> 
> Fair enough.
> 
> For the record, the failure that motivated this: a pristine Ubuntu 26.04 arm64 image on a MediaTek Genio 700 EVK dies silently about 60 seconds after ExitBootServices(), 100% reproducible, at a wall-clock dependent point. The generic kernel ships the watchdog driver as a module, so nothing services the watchdog in time, and nothing tells the OS that it is running. From the user's side this is indistinguishable from broken firmware.
> 
> In the meantime, is the accepted pattern hooking up a wdt_stop_all() in the EFI path via board_quiesce_devices()? That keeps the watchdog armed for the whole firmware lifetime and makes the handoff behaviour the board maintainer's call.

No, Ubuntu needs to fix their kernel image to have the watchdog
available early. I hate to be difficult on this, but it's been a known
issue for years at this point that the spec needs to be updated. The
workaround here is for the watchdog to not be started until the OS is
ready to maintain it.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH] efi_loader: stop watchdog devices in ExitBootServices()

[Heinrich Schuchardt]

Am 4. Juli 2026 18:17:07 MESZ schrieb Tom Rini <trini@konsulko.com>:
>On Sat, Jul 04, 2026 at 05:21:25PM +0200, Carlo Caione wrote:
>> 
>> 
>> > On 4 Jul 2026, at 16:32, Tom Rini <trini@konsulko.com> wrote:
>> > 
>> > On Sat, Jul 04, 2026 at 03:52:29PM +0200, Carlo Caione wrote:
>> > 
>> >> U-Boot can autonomously start a hardware watchdog
>> >> (CONFIG_WATCHDOG_AUTOSTART, default y) and service it from its main
>> >> loop, but the EFI boot path never stops it: efi_exit_boot_services()
>> >> tears the devices down without calling wdt_stop_all(), and a watchdog
>> >> driver without a .remove hook leaves the hardware ticking across the
>> >> firmware-to-OS handoff.
>> >> 
>> >> An EFI-booted OS that does not take over the SoC watchdog within the
>> >> remaining timeout is reset mid-boot at a wall-clock-dependent point.
>> >> 
>> >> The UEFI specification (v2.11, section 7.5 "Miscellaneous Boot
>> >> Services", EFI_BOOT_SERVICES.SetWatchdogTimer()) is explicit about the
>> >> one watchdog it allows across the handoff:
>> >> 
>> >>  "The watchdog timer is only used during boot services. On
>> >>   successful completion of EFI_BOOT_SERVICES.ExitBootServices() the
>> >>   watchdog timer is disabled."
>> >> 
>> >> U-Boot's UEFI watchdog (an EFI timer event) complies by construction. A
>> >> platform watchdog silently surviving the handoff defeats the purpose of
>> >> that rule: the OS has no generic way to know it is running, let alone to
>> >> service it.
>> >> 
>> >> Stop all watchdog devices in efi_exit_boot_services(), before the device
>> >> teardown.
>> >> 
>> >> Signed-off-by: Carlo Caione <ccaione@baylibre.com>
>> > 
>> > NAK. We have had this come up before, and in short, the UEFI
>> > specification needs to be fixed here, as generally speaking a watchdog
>> > should never be stopped, as that leaves a gap where the system can hang
>> > and thus defeat the point of having enabled a watchdog.
>> 
>> 
>> Fair enough.
>> 
>> For the record, the failure that motivated this: a pristine Ubuntu 26.04 arm64 image on a MediaTek Genio 700 EVK dies silently about 60 seconds after ExitBootServices(), 100% reproducible, at a wall-clock dependent point. The generic kernel ships the watchdog driver as a module, so nothing services the watchdog in time, and nothing tells the OS that it is running. From the user's side this is indistinguishable from broken firmware.
>> 
>> In the meantime, is the accepted pattern hooking up a wdt_stop_all() in the EFI path via board_quiesce_devices()? That keeps the watchdog armed for the whole firmware lifetime and makes the handoff behaviour the board maintainer's call.
>
>No, Ubuntu needs to fix their kernel image to have the watchdog
>available early. I hate to be difficult on this, but it's been a known
>issue for years at this point that the spec needs to be updated. The
>workaround here is for the watchdog to not be started until the OS is
>ready to maintain it.
>

Nothing wrong with the spec. Some hardware engineers simply don't read it and create watchdog timers that cannot be set to a 5 min timeout.

Best regards

Heinrich

Re: [PATCH] efi_loader: stop watchdog devices in ExitBootServices()

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 3698 bytes --]

On Sat, Jul 04, 2026 at 06:46:50PM +0200, Heinrich Schuchardt wrote:
> Am 4. Juli 2026 18:17:07 MESZ schrieb Tom Rini <trini@konsulko.com>:
> >On Sat, Jul 04, 2026 at 05:21:25PM +0200, Carlo Caione wrote:
> >> 
> >> 
> >> > On 4 Jul 2026, at 16:32, Tom Rini <trini@konsulko.com> wrote:
> >> > 
> >> > On Sat, Jul 04, 2026 at 03:52:29PM +0200, Carlo Caione wrote:
> >> > 
> >> >> U-Boot can autonomously start a hardware watchdog
> >> >> (CONFIG_WATCHDOG_AUTOSTART, default y) and service it from its main
> >> >> loop, but the EFI boot path never stops it: efi_exit_boot_services()
> >> >> tears the devices down without calling wdt_stop_all(), and a watchdog
> >> >> driver without a .remove hook leaves the hardware ticking across the
> >> >> firmware-to-OS handoff.
> >> >> 
> >> >> An EFI-booted OS that does not take over the SoC watchdog within the
> >> >> remaining timeout is reset mid-boot at a wall-clock-dependent point.
> >> >> 
> >> >> The UEFI specification (v2.11, section 7.5 "Miscellaneous Boot
> >> >> Services", EFI_BOOT_SERVICES.SetWatchdogTimer()) is explicit about the
> >> >> one watchdog it allows across the handoff:
> >> >> 
> >> >>  "The watchdog timer is only used during boot services. On
> >> >>   successful completion of EFI_BOOT_SERVICES.ExitBootServices() the
> >> >>   watchdog timer is disabled."
> >> >> 
> >> >> U-Boot's UEFI watchdog (an EFI timer event) complies by construction. A
> >> >> platform watchdog silently surviving the handoff defeats the purpose of
> >> >> that rule: the OS has no generic way to know it is running, let alone to
> >> >> service it.
> >> >> 
> >> >> Stop all watchdog devices in efi_exit_boot_services(), before the device
> >> >> teardown.
> >> >> 
> >> >> Signed-off-by: Carlo Caione <ccaione@baylibre.com>
> >> > 
> >> > NAK. We have had this come up before, and in short, the UEFI
> >> > specification needs to be fixed here, as generally speaking a watchdog
> >> > should never be stopped, as that leaves a gap where the system can hang
> >> > and thus defeat the point of having enabled a watchdog.
> >> 
> >> 
> >> Fair enough.
> >> 
> >> For the record, the failure that motivated this: a pristine Ubuntu 26.04 arm64 image on a MediaTek Genio 700 EVK dies silently about 60 seconds after ExitBootServices(), 100% reproducible, at a wall-clock dependent point. The generic kernel ships the watchdog driver as a module, so nothing services the watchdog in time, and nothing tells the OS that it is running. From the user's side this is indistinguishable from broken firmware.
> >> 
> >> In the meantime, is the accepted pattern hooking up a wdt_stop_all() in the EFI path via board_quiesce_devices()? That keeps the watchdog armed for the whole firmware lifetime and makes the handoff behaviour the board maintainer's call.
> >
> >No, Ubuntu needs to fix their kernel image to have the watchdog
> >available early. I hate to be difficult on this, but it's been a known
> >issue for years at this point that the spec needs to be updated. The
> >workaround here is for the watchdog to not be started until the OS is
> >ready to maintain it.
> >
> 
> Nothing wrong with the spec. Some hardware engineers simply don't read it and create watchdog timers that cannot be set to a 5 min timeout.

Maybe 5 minutes is acceptable in some use cases. It's certainly not in
others. The spec needs to be updated to reflect the reality of
industries that people are pushing to use UEFI in. And then operating
systems need to reflect that a watchdog is not some niche device for
arm64 but something virtually every platform has and that it must be
serviced ASAP.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH] efi_loader: stop watchdog devices in ExitBootServices()

[Heinrich Schuchardt]

Am 4. Juli 2026 18:17:07 MESZ schrieb Tom Rini <trini@konsulko.com>:
>On Sat, Jul 04, 2026 at 05:21:25PM +0200, Carlo Caione wrote:
>> 
>> 
>> > On 4 Jul 2026, at 16:32, Tom Rini <trini@konsulko.com> wrote:
>> > 
>> > On Sat, Jul 04, 2026 at 03:52:29PM +0200, Carlo Caione wrote:
>> > 
>> >> U-Boot can autonomously start a hardware watchdog
>> >> (CONFIG_WATCHDOG_AUTOSTART, default y) and service it from its main
>> >> loop, but the EFI boot path never stops it: efi_exit_boot_services()
>> >> tears the devices down without calling wdt_stop_all(), and a watchdog
>> >> driver without a .remove hook leaves the hardware ticking across the
>> >> firmware-to-OS handoff.
>> >> 
>> >> An EFI-booted OS that does not take over the SoC watchdog within the
>> >> remaining timeout is reset mid-boot at a wall-clock-dependent point.
>> >> 
>> >> The UEFI specification (v2.11, section 7.5 "Miscellaneous Boot
>> >> Services", EFI_BOOT_SERVICES.SetWatchdogTimer()) is explicit about the
>> >> one watchdog it allows across the handoff:
>> >> 
>> >>  "The watchdog timer is only used during boot services. On
>> >>   successful completion of EFI_BOOT_SERVICES.ExitBootServices() the
>> >>   watchdog timer is disabled."
>> >> 
>> >> U-Boot's UEFI watchdog (an EFI timer event) complies by construction. A
>> >> platform watchdog silently surviving the handoff defeats the purpose of
>> >> that rule: the OS has no generic way to know it is running, let alone to
>> >> service it.
>> >> 
>> >> Stop all watchdog devices in efi_exit_boot_services(), before the device
>> >> teardown.
>> >> 
>> >> Signed-off-by: Carlo Caione <ccaione@baylibre.com>
>> > 
>> > NAK. We have had this come up before, and in short, the UEFI
>> > specification needs to be fixed here, as generally speaking a watchdog
>> > should never be stopped, as that leaves a gap where the system can hang
>> > and thus defeat the point of having enabled a watchdog.
>> 
>> 
>> Fair enough.
>> 
>> For the record, the failure that motivated this: a pristine Ubuntu 26.04 arm64 image on a MediaTek Genio 700 EVK dies silently about 60 seconds after ExitBootServices(), 100% reproducible, at a wall-clock dependent point. The generic kernel ships the watchdog driver as a module, so nothing services the watchdog in time, and nothing tells the OS that it is running. From the user's side this is indistinguishable from broken firmware.
>> 
>> In the meantime, is the accepted pattern hooking up a wdt_stop_all() in the EFI path via board_quiesce_devices()? That keeps the watchdog armed for the whole firmware lifetime and makes the handoff behaviour the board maintainer's call.
>
>No, Ubuntu needs to fix their kernel image to have the watchdog
>available early. I hate to be difficult on this, but it's been a known
>issue for years at this point that the spec needs to be updated. The
>workaround here is for the watchdog to not be started until the OS is
>ready to maintain it.
>

Best open a Launchpad bug explaining why this watchdog driver needs to be built in and not a module.

Best regards

Heinrich

Re: [PATCH] efi_loader: stop watchdog devices in ExitBootServices()

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 3628 bytes --]

On Sat, Jul 04, 2026 at 06:59:08PM +0200, Heinrich Schuchardt wrote:
> Am 4. Juli 2026 18:17:07 MESZ schrieb Tom Rini <trini@konsulko.com>:
> >On Sat, Jul 04, 2026 at 05:21:25PM +0200, Carlo Caione wrote:
> >> 
> >> 
> >> > On 4 Jul 2026, at 16:32, Tom Rini <trini@konsulko.com> wrote:
> >> > 
> >> > On Sat, Jul 04, 2026 at 03:52:29PM +0200, Carlo Caione wrote:
> >> > 
> >> >> U-Boot can autonomously start a hardware watchdog
> >> >> (CONFIG_WATCHDOG_AUTOSTART, default y) and service it from its main
> >> >> loop, but the EFI boot path never stops it: efi_exit_boot_services()
> >> >> tears the devices down without calling wdt_stop_all(), and a watchdog
> >> >> driver without a .remove hook leaves the hardware ticking across the
> >> >> firmware-to-OS handoff.
> >> >> 
> >> >> An EFI-booted OS that does not take over the SoC watchdog within the
> >> >> remaining timeout is reset mid-boot at a wall-clock-dependent point.
> >> >> 
> >> >> The UEFI specification (v2.11, section 7.5 "Miscellaneous Boot
> >> >> Services", EFI_BOOT_SERVICES.SetWatchdogTimer()) is explicit about the
> >> >> one watchdog it allows across the handoff:
> >> >> 
> >> >>  "The watchdog timer is only used during boot services. On
> >> >>   successful completion of EFI_BOOT_SERVICES.ExitBootServices() the
> >> >>   watchdog timer is disabled."
> >> >> 
> >> >> U-Boot's UEFI watchdog (an EFI timer event) complies by construction. A
> >> >> platform watchdog silently surviving the handoff defeats the purpose of
> >> >> that rule: the OS has no generic way to know it is running, let alone to
> >> >> service it.
> >> >> 
> >> >> Stop all watchdog devices in efi_exit_boot_services(), before the device
> >> >> teardown.
> >> >> 
> >> >> Signed-off-by: Carlo Caione <ccaione@baylibre.com>
> >> > 
> >> > NAK. We have had this come up before, and in short, the UEFI
> >> > specification needs to be fixed here, as generally speaking a watchdog
> >> > should never be stopped, as that leaves a gap where the system can hang
> >> > and thus defeat the point of having enabled a watchdog.
> >> 
> >> 
> >> Fair enough.
> >> 
> >> For the record, the failure that motivated this: a pristine Ubuntu 26.04 arm64 image on a MediaTek Genio 700 EVK dies silently about 60 seconds after ExitBootServices(), 100% reproducible, at a wall-clock dependent point. The generic kernel ships the watchdog driver as a module, so nothing services the watchdog in time, and nothing tells the OS that it is running. From the user's side this is indistinguishable from broken firmware.
> >> 
> >> In the meantime, is the accepted pattern hooking up a wdt_stop_all() in the EFI path via board_quiesce_devices()? That keeps the watchdog armed for the whole firmware lifetime and makes the handoff behaviour the board maintainer's call.
> >
> >No, Ubuntu needs to fix their kernel image to have the watchdog
> >available early. I hate to be difficult on this, but it's been a known
> >issue for years at this point that the spec needs to be updated. The
> >workaround here is for the watchdog to not be started until the OS is
> >ready to maintain it.
> >
> 
> Best open a Launchpad bug explaining why this watchdog driver needs to be built in and not a module.

I'll leave that to Carlos, and I would suggest digging out the mailing
list threads from a year or two (or three?) ago when this had come up
before, and the problem was explained and it was spelled out that U-Boot
will not be spec compliant here, and I thought someone even volunteered
to take this to the spec to get updated.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH] efi_loader: stop watchdog devices in ExitBootServices()

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 3576 bytes --]

On Sat, Jul 04, 2026 at 11:15:13AM -0600, Tom Rini wrote:
> On Sat, Jul 04, 2026 at 06:59:08PM +0200, Heinrich Schuchardt wrote:
> > Am 4. Juli 2026 18:17:07 MESZ schrieb Tom Rini <trini@konsulko.com>:
> > >On Sat, Jul 04, 2026 at 05:21:25PM +0200, Carlo Caione wrote:
> > >> 
> > >> 
> > >> > On 4 Jul 2026, at 16:32, Tom Rini <trini@konsulko.com> wrote:
> > >> > 
> > >> > On Sat, Jul 04, 2026 at 03:52:29PM +0200, Carlo Caione wrote:
> > >> > 
> > >> >> U-Boot can autonomously start a hardware watchdog
> > >> >> (CONFIG_WATCHDOG_AUTOSTART, default y) and service it from its main
> > >> >> loop, but the EFI boot path never stops it: efi_exit_boot_services()
> > >> >> tears the devices down without calling wdt_stop_all(), and a watchdog
> > >> >> driver without a .remove hook leaves the hardware ticking across the
> > >> >> firmware-to-OS handoff.
> > >> >> 
> > >> >> An EFI-booted OS that does not take over the SoC watchdog within the
> > >> >> remaining timeout is reset mid-boot at a wall-clock-dependent point.
> > >> >> 
> > >> >> The UEFI specification (v2.11, section 7.5 "Miscellaneous Boot
> > >> >> Services", EFI_BOOT_SERVICES.SetWatchdogTimer()) is explicit about the
> > >> >> one watchdog it allows across the handoff:
> > >> >> 
> > >> >>  "The watchdog timer is only used during boot services. On
> > >> >>   successful completion of EFI_BOOT_SERVICES.ExitBootServices() the
> > >> >>   watchdog timer is disabled."
> > >> >> 
> > >> >> U-Boot's UEFI watchdog (an EFI timer event) complies by construction. A
> > >> >> platform watchdog silently surviving the handoff defeats the purpose of
> > >> >> that rule: the OS has no generic way to know it is running, let alone to
> > >> >> service it.
> > >> >> 
> > >> >> Stop all watchdog devices in efi_exit_boot_services(), before the device
> > >> >> teardown.
> > >> >> 
> > >> >> Signed-off-by: Carlo Caione <ccaione@baylibre.com>
> > >> > 
> > >> > NAK. We have had this come up before, and in short, the UEFI
> > >> > specification needs to be fixed here, as generally speaking a watchdog
> > >> > should never be stopped, as that leaves a gap where the system can hang
> > >> > and thus defeat the point of having enabled a watchdog.
> > >> 
> > >> 
> > >> Fair enough.
> > >> 
> > >> For the record, the failure that motivated this: a pristine Ubuntu 26.04 arm64 image on a MediaTek Genio 700 EVK dies silently about 60 seconds after ExitBootServices(), 100% reproducible, at a wall-clock dependent point. The generic kernel ships the watchdog driver as a module, so nothing services the watchdog in time, and nothing tells the OS that it is running. From the user's side this is indistinguishable from broken firmware.
> > >> 
> > >> In the meantime, is the accepted pattern hooking up a wdt_stop_all() in the EFI path via board_quiesce_devices()? That keeps the watchdog armed for the whole firmware lifetime and makes the handoff behaviour the board maintainer's call.
> > >
> > >No, Ubuntu needs to fix their kernel image to have the watchdog
> > >available early. I hate to be difficult on this, but it's been a known
> > >issue for years at this point that the spec needs to be updated. The
> > >workaround here is for the watchdog to not be started until the OS is
> > >ready to maintain it.
> > >
> > 
> > Best open a Launchpad bug explaining why this watchdog driver needs to be built in and not a module.
> 
> I'll leave that to Carlos, and I would suggest digging out the mailing

... to Carlo, my apologies.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]