I have an issue where I can only suspend the iMX8MP up to 128 seconds before it reboots due to the watchdog timer.
Using the mem sleep state.
I see in the watchdog control register, bit 0 is for suspending dog on STOP/DOZE and bit 8 is for suspending on WAIT.
Looking at the NXP iMX Linux Reference manual, it seems that the IMX8M family doesn’t support STOP or WAIT, only a software based power domain suspend.
The imx2_wdt.c driver when suspending attempts to turn the clock off, but this doesn’t seem to have any effect - WDT still resets the device after 128 seconds.
We are using upstream NXP Linux 6.6 + Toradex patches and mainline u-boot + Toradex patches.
Is this supposed to work, or is it not possible to use suspend and wdt at the same time?
I’m wondering if it is a result of using mainline u-boot an nxp linux together, is that a stupid thing to do?
I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.
Did you like my answer?
Hello! Thank you for your detailed description of the issue.
You are correct that on the i.MX 8M Plus, the Linux kernel uses the WDOG1 watchdog by default, and the watchdog timer continues running during suspend-to-RAM (deep sleep) unless special handling is implemented. This behavior can indeed result in the system being reset by the watchdog if the device remains in suspend for longer than the watchdog timeout (which is often 128 seconds, as you observed)(1).
Suspend and Watchdog Behavior
The i.MX 8M Plus does not support traditional STOP or WAIT CPU power states. Instead, suspend-to-RAM is handled via a software-managed power domain(3).
The imx2_wdt driver attempts to disable the watchdog during suspend by gating its clock, but the actual hardware does not always support this as intended—meaning the watchdog can continue counting down during suspend and will eventually reset the board.
Thus, unless the watchdog is explicitly managed in a board- or driver-specific way, you will encounter resets after the timeout during suspend-to-RAM.
Using Mainline U-Boot with NXP Linux
Using mainline U-Boot with an NXP-provided (or Toradex-patched) Linux kernel is possible and often works, but it is generally recommended to use the combinations validated by Toradex BSP releases for best stability and compatibility(4).
In this case, though, the suspend/watchdog interaction is not likely a direct result of using mainline U-Boot, but rather is due to the way the SoC handles suspend and the watchdog in hardware. The reset you are seeing is expected with the standard upstream software stack.
Possible Solutions
Increase Watchdog Timeout: If you control your own system, you can increase the watchdog timeout before suspend so that typical suspend durations do not trigger a reset.
Disable Watchdog Prior to Suspend: Some implementations explicitly stop the watchdog prior to entering suspend (for example, via a systemd or custom suspend script) and re-enable it on resume, but this introduces a short window where no watchdog protection is present.
Custom Kernel Patches: In theory, the imx2_wdt driver could be modified to better support suspend on this hardware, but support is limited by hardware capabilities. As such, there is usually not a way to have the watchdog safely stopped during suspend-to-RAM on this SoC.
Use Suspend-to-Idle (s2idle): If deep power savings are less critical, you can use the lighter s2idle suspend mode, where the watchdog should continue to be properly serviced.
Summary
To directly answer your question: This behavior is expected on the i.MX 8M Plus with standard Linux implementations, and it is not the result of mixing mainline U-Boot and NXP Linux per se. The hardware design does not stop the watchdog during suspend-to-RAM, and it is not currently possible to keep the watchdog running without risking resets after the timeout. Most systems either increase the watchdog timeout or disable the watchdog during suspend.
Hi @phil , the suspend feature of Verdin iMX8MP is not fully supported on mainline kernel yet. If this is essential to your application, we suggest downstream image. And it is never a stupid thing to choose mainline release. Our R&D team at Toradex is working actively on mainline, and it is also important to our products.
Sorry, there was a typo. It is downstream Linux reference multimedia image v7.3.0 where suspend and wake-up works.
This image includes upstream U-Boot v2024.07 and the NXP downstream kernel v6.6. The system wakes up from suspend-to-RAM state after 150 seconds via the RTC.
I also grabbed your kernel config from the BSP 7.1.0 release shown in the release matrix. I think (hope) our kernel versions are similar enough both being based off the NXP 6.6 release.
Still not working.
I don’t have rtcwake available so I can’t do the exact same test, however I just checked the source for it and it is very simply, sets an alarm then writes to the same file I am.
One key difference between your example images and the one I have, is I am putting my image together with buildroot.
Right now the u-boots match. The kernel is very similar.
I’m running out of ideas of what to try. Have you got any suggestions?
I don’t have rtcwake available so I can’t do the exact same test, however I just checked the source for it and it is very simply, sets an alarm then writes to the same file I am.
Yes, they are basically the same.
Our latest downstream kernel for Verdin iMX8MP is based on lf-6.6.52-2.2.0 and R&D team customs the kernel to make it work on the module. There could be lots of changes against NXP Linux lf-6.6.y. But we don’t have patch set for NXP Linux lf-6.6.y that works with buildroot. It may be the reason suspend doesn’t work.
