BOOT_WATCHDOG_TIMEOUT not cancelled after ARM CPU start

[embetrix]

When SIGNED_BOOT=1 is enabled in the EEPROM config alongside BOOT_WATCHDOG_TIMEOUT set, the bootloader watchdog is not automatically cancelled when the ARM CPU starts.
The system reboots after the configured timeout even though Linux is fully booted and running.

Per the documentation:

the bootloader watchdog should be "automatically cancelled as soon as the Arm CPU is started."

EEPROM config:

[all]
SIGNED_BOOT=1
BOOT_UART=1
BOOT_WATCHDOG_TIMEOUT=180
PARTITION_WALK=1

Firmware version:

2026/02/23 10:01:39
version 85353ce41ce7840aa48c5cda1e77c5ad208b1331 (release)
Hardware: Raspberry Pi 5 

Logs:

root@raspberrypi5:~# uptime
16:16:05 up 2 min,  0 user,  load average: 0.23, 0.25, 0.10
 0.89 Boot watchdog init. max duration 180s part 0 started_at 887399 end_at 180887399

 0.89 RPi: BOOTSYS release VERSION:85353ce4 DATE: 2026/02/23 TIME: 10:01:39
 0.90 BOOTMODE: 0x06 partition 0 build-ts BUILD_TIMESTAMP=1771840899 serial d4c37390 boardrev d04171 stc 903919
 0.91 AON_RESET: 00000003 PM_RSTS 00000020
 0.91 POWER_OFF_ON_HALT: 0 WAIT_FOR_POWER_BUTTON 0 power-on-reset 0
 0.92 RP1_BOOT chip ID: 0x20001927
 0.93 PCIEx1: PWR 0 DET_WAKE 0
 0.93 part 00000000 reset_info 00000000
 0.93 PMIC reset-event 00000000 rtc 69e10b47 alarm 00000000 enabled 0
 0.94 uSD voltage 3.3V
 0.94 SDRAM_CONFIG: 14
 0.94 Initialising SDRAM rank 2 total-size: 64Gbit 0 part: 0 (0x14 0x14)
 0.95 memsys_init: 0 64Gbit MCB 0x80015ff0: 5488
 0.95 DDR 4267 Mbps dual-rank:1 byte-mode:0 size-gbit:64
 1.64 RP1 FW: load 0
 1.65 RP1_BOOT chip ID: 0x20001927
 2.81 RP1 FW: load 1
 3.24 OTP boardrev d04171 bootrom a a
 3.24 Customer key hash 0000000000000000000000000000000000000000000000000000000000000000
 3.25 VC-JTAG unlocked
 3.27 RP1_BOOT chip ID: 0x20001927
 3.28 Boot watchdog init. max duration 180s part 0 started_at 887399 end_at 180887399

 3.91 PCI2 init
 3.93 PCI2 reset
 3.98 PCIe scan 00001de4:00000001
 3.98 RP1_CHIP_INFO 20001927

Removing SIGNED_BOOT=1 or commenting out BOOT_WATCHDOG_TIMEOUT resolves the issue
Expected: Bootloader watchdog cancelled at ARM CPU handoff regardless of SIGNED_BOOT state.

[pelwell]

I'm far from an expert when it comes to this stuff, but it appears that (regardless of the value of SIGNED_BOOT) the only thing that should prevent the watchdog being disabled is a non-zero value of kernel_watchdog_timeout from config.txt. Is that possible in your case? Try adding uart_2ndstage=1 in config.txt to get more logging output.

[embetrix]

I don't get it in what is this relaed to a non-zero value of kernel_watchdog_timeout ?

SIGNED_BOOT set or disabled make the difference as explained above

[pelwell]

If you could see the source code of the firmware you would understand. It basically goes:

if (kernel_watchdog_timeout != 0)
    configure_kernel_watchdog();
else
    disable_boot_watchdog();

// a few lines of other stuff

start_arms();

There is no way to get to start_arms() without going through the if, and disable_boot_watchdog() is a very simple function that doesn't know anything about signed boot.

Hence my question.

[embetrix]

Thanks @pelwell for the insight. I checked and kernel_watchdog_timeout is not set in my config.txt, so it should default to 0.

based on your pseudocode, disable_boot_watchdog() should be called. However the system still reboots at exactly 180s (PM_RSTS 00000020 confirms watchdog reset).

This behaviour is only observed when SIGNED_BOOT=1 is enabled. With SIGNED_BOOT disabled, the boot watchdog is cancelled correctly at ARM CPU start.

[pelwell]

Hopefully someone with a bit more knowledge of the field will be able to chip in at some point.

[cfernand2222]

It's my understanding that something in the OS has to kick the dog (not just the arm cores starting up).

Check that RuntimeWatchdogSec is configured in /etc/systemd/system.conf

Have a look in the note section here

[embetrix]

@cfernand2222 please Read again the issue and discussion fully before suggest something off topic

[timg236]

The description of how watchdog cancellation works is correct.

N.B. SIGNED_BOOT=1 is redundant for secure-boot these days so you can safely delete that.

[embetrix]

SIGNED_BOOT=1 is not redundant in case I didn't burn OTPs yet ? that's my case

[timg236]

It's being removed because it's inconsistent with secure-boot behaviour on Pi5 and confuses people who might think that they have enabled secure-boot when in reality they've just set a config flag.

[embetrix]

now I'm getting confused, how to then boot using boot.img/boot.sig ?

[timg236]

If secure-boot is enabled (via OTP) then the bootloader will only ever load boot.img + boot.sig and always verifies the signature.

SIGNED_BOOT=1 is almost the same as setting boot_ramdisk=1 but it just does the RSA verification of boot.sig

It looks like your boot log stops before starting the kernel. The kernel WDT driver would actually cancel the boot_watchdog even if it is still running so I suspect there is something strange going on with cmdline.txt.
uart_2ndstage=1 and kernel kernel UART traces (remove quiet in cmdline.txt) will reveal

[embetrix]

No it's not in the logs I'm already in rootfs and have also systemd configured with hw watchdog

root@raspberrypi5:~# uptime
16:16:05 up 2 min,  0 user,  load average: 0.23, 0.25, 0.10
 0.89 Boot watchdog init. max duration 180s part 0 started_at 887399 end_at 180887399

 0.89 RPi: BOOTSYS release VERSION:85353ce4 DATE: 2026/02/23 TIME: 10:01:39
 0.90 BOOTMODE: 0x06 partition 0 build-ts BUILD_TIMESTAMP=1771840899 serial d4c37390 boardrev d04171 stc 903919
 0.91 AON_RESET: 00000003 PM_RSTS 00000020
 0.91 POWER_OFF_ON_HALT: 0 WAIT_FOR_POWER_BUTTON 0 power-on-reset 0
 0.92 RP1_BOOT chip ID: 0x20001927
 0.93 PCIEx1: PWR 0 DET_WAKE 0
 0.93 part 00000000 reset_info 00000000
 0.93 PMIC reset-event 00000000 rtc 69e10b47 alarm 00000000 enabled 0
 0.94 uSD voltage 3.3V
 0.94 SDRAM_CONFIG: 14
 0.94 Initialising SDRAM rank 2 total-size: 64Gbit 0 part: 0 (0x14 0x14)
 0.95 memsys_init: 0 64Gbit MCB 0x80015ff0: 5488
 0.95 DDR 4267 Mbps dual-rank:1 byte-mode:0 size-gbit:64
 1.64 RP1 FW: load 0
 1.65 RP1_BOOT chip ID: 0x20001927
 2.81 RP1 FW: load 1
 3.24 OTP boardrev d04171 bootrom a a
 3.24 Customer key hash 0000000000000000000000000000000000000000000000000000000000000000
 3.25 VC-JTAG unlocked
 3.27 RP1_BOOT chip ID: 0x20001927
 3.28 Boot watchdog init. max duration 180s part 0 started_at 887399 end_at 180887399

 3.91 PCI2 init
 3.93 PCI2 reset
 3.98 PCIe scan 00001de4:00000001
 3.98 RP1_CHIP_INFO 20001927

[pelwell]

Ahem:

Try adding uart_2ndstage=1 in config.txt to get more logging output.

uart_2ndstage=1 and kernel kernel UART traces (remove quiet in cmdline.txt) will reveal