fix(watchdog): service hardware watchdog during initramfs crypt setup

[colpane]

WDOG_TIMEOUT only configures EFI Boot Guard's own watchdog handling and does not stop U-Boot from independently arming the hardware watchdog. INITRAMFS_WATCHDOG_DEVICE was left unset, so the initramfs crypt-hook never serviced it during the lengthy TPM2/LUKS partition setup on first boot, causing the device to hard-reset mid-encryption if setup exceeded the bootloader-armed timeout.

Move WDOG_TIMEOUT from iot2050-image-base.bb to iot2050.conf so it applies regardless of which image recipe is used, and add INITRAMFS_WATCHDOG_DEVICE=/dev/watchdog so the crypt-hook keeps the hardware watchdog alive during setup.

[colpane]

@huaqianli could you check please :)

[jan-kiszka]

I suspect you are using a larger encrypted disk setup than the example image, because the missing watchdog petting during encryption should have otherwise already been noticed.

I would split setting INITRAMFS_WATCHDOG_DEVICE from moving WDOG_TIMEOUT because those are different topics.

[colpane]

I suspect you are using a larger encrypted disk setup than the example image, because the missing watchdog petting during encryption should have otherwise already been noticed.

I would split setting INITRAMFS_WATCHDOG_DEVICE from moving WDOG_TIMEOUT because those are different topics.

Actually, I'm using eMMC @jan-kiszka. Sure, I'm splitting into two different commits.

[jan-kiszka]

Actually, I'm using eMMC @jan-kiszka. Sure, I'm splitting into two different commits.

But the question is how large your encrypted partition is on that setup. By default, it should only be an empty /var, not the read-only rootfs or some prefilled data partitions.

[colpane]

Actually, I'm using eMMC @jan-kiszka. Sure, I'm splitting into two different commits.

But the question is how large your encrypted partition is on that setup. By default, it should only be an empty /var, not the read-only rootfs or some prefilled data partitions.

got it now, then, yes, it is larger on my side :)

[colpane]

Actually, I'm using eMMC @jan-kiszka. Sure, I'm splitting into two different commits.

But the question is how large your encrypted partition is on that setup. By default, it should only be an empty /var, not the read-only rootfs or some prefilled data partitions.

You're right, and I checked the logs to confirm.

CRYPT_PARTITIONS on our setup is overridden to "persistent:/persistent:format-if-empty" — so it's not the read-only rootfs (that's on separate dm-verity protected A/B partitions, never encrypted) and not prefilled data (format-if-empty creates an empty LUKS volume + fresh filesystem).

However, the size is not the small nominal partition from the .wks.in (2G). We have a separate initramfs-expand-disk-hook that runs before the crypt-hook in local-top and grows the persistent partition (as the last partition on disk) to consume the rest of the eMMC via sfdisk --force, independent of the crypt-hook's own :expand flag. The log confirms this:

mke2fs 1.47.2 (1-Jan-2025)
Creating filesystem with 2795008 4k blocks and 699008 inodes

2795008 × 4k ≈ 10.66 GiB, vs. the 2G nominal size in the wks file — so on first boot we're doing LUKS format + TPM2 enrollment + mke2fs on a ~10.66 GiB partition instead of a small empty one. That's almost certainly why the missing watchdog petting became visible for us and possibly wasn't for the reference setup.

One more thing worth noting: our timeout is 60s because U-Boot arms the hardware watchdog with that value before handing off to Linux (WDT: Started watchdog@40610000 without servicing (60s timeout)). I'm not sure upstream's own test setup actually arms a U-Boot watchdog at all when testing the crypt-hook — if it doesn't, the missing petting simply wouldn't manifest as a hard reset for them regardless of partition size, which would also explain why this wasn't caught upstream.

[jan-kiszka]

Adding INITRAMFS_WATCHDOG_DEVICE is absolutely right - was forgotten or, more likely, didn't even exist by the time the integration was done.

One more thing worth noting: our timeout is 60s because U-Boot arms the hardware watchdog with that value before handing off to Linux (WDT: Started watchdog@40610000 without servicing (60s timeout)). I'm not sure upstream's own test setup actually arms a U-Boot watchdog at all when testing the crypt-hook — if it doesn't, the missing petting simply wouldn't manifest as a hard reset for them regardless of partition size, which would also explain why this wasn't caught upstream.

If you are referring to isar-cip-core: No, we do not test this because there is still no watchdog that qemu-system-aarch64 can emulate via its virt machine and U-Boot understands out of the box. Maybe worth looking into that again, though. An alternative would be enabling the real AM62x platform for CI image testing.

[huaqianli]

Signed-off-by is missing.

[jan-kiszka]

FWIW: https://lore.kernel.org/u-boot/cbed1b19-f171-4388-9614-13f89a9820dd@siemens.com