The fix and explanation is in the first patch, which I hope can make it into v2022.10, it should be rather uncontroversial.
The second patch may make sense on its own, but is not at all urgent and can be considered a mere suggestion, but it was convenient for making the following two patches less intrusive.
While I noticed this on my actual hardware, it's not too hard to verify the problem in sandbox, which is what patches 2-4 are for.
More precisely, I've tested that with this series (and the stuff added by the first patch temporarily commented out), building sandbox64_defconfig modified by setting CONFIG_BOOTDELAY=15 and CONFIG_AUTOBOOT_KEYED=y, doing
./u-boot -D
works as always (ordinary simple autoboot, getting a prompt after 15 seconds), while with
./u-boot -D --autoboot_keyed
the sandbox gets killed as expected five seconds into the 15 second countdown. And with the first patch properly applied, this is fixed.
I don't know if this is a good way to test this, or if having that SIGALRM based watchdog device running always in sandbox can cause problems for other uses of sandbox. I also won't have time in the near future for polishing or reworking the test, so consider it mostly POC.
Regardless, as I wrote above, I do hope the fix itself (1/4) can be applied soonish.
Rasmus Villemoes (4): autoboot: make sure watchdog device(s) are handled with keyed autoboot watchdog: introduce a u-boot,autostart property sandbox: add SIGALRM-based watchdog device sandbox.dtsi: add a sandbox,alarm-wdt instance
arch/sandbox/cpu/os.c | 17 +++++ arch/sandbox/dts/sandbox.dtsi | 6 ++ common/autoboot.c | 3 + configs/sandbox64_defconfig | 2 + configs/sandbox_defconfig | 2 + doc/device-tree-bindings/watchdog/common.txt | 9 ++- drivers/watchdog/Kconfig | 8 ++ drivers/watchdog/Makefile | 1 + drivers/watchdog/sandbox_alarm-wdt.c | 79 ++++++++++++++++++++ drivers/watchdog/wdt-uclass.c | 15 ++-- include/os.h | 17 +++++ 11 files changed, 149 insertions(+), 10 deletions(-) create mode 100644 drivers/watchdog/sandbox_alarm-wdt.c