LDO-Bypass affecting i.MX WDT, enabled in U-Boot

We're using 4.14 GA release for i.MX6Q SabreSD rev 1.2. Our use-case dictates enabling the WDT in U-Boot, and ping it in userspace via systemd. So we do by enabling IMX_WATCHDOG, HW_WATCHDOG and setting WATCHDOG_TIMEOUT_MSECS to, say, 120000 in U-Boot. We also disable CONFIG_WATCHDOG_HANDLE_BOOT_ENABLED in Linux.

In default DTB, imx6q-sabresd.dtb, ldo-bypass mode is configured. We've observed erratic behavior of WDT when it was triggered in U-Boot. Even with systemd servicing the watchdog through WDIOC_KEEPALIVE on /dev/watchdog, POR happens for some reason. It is like as if servicing WDOG_WSR by Linux driver imx2_wdt.c has no effect at all.

We've also verified that this behavior is not seen when using LDO, or WDT was not enabled in U-Boot. The only difference in the value of WCR, when using correctly working internal LDO mode, is debug-enable-bit. It is set by U-Boot (Why does U-Boot driver set that?) and is write-once-per-reset, but is seen cleared when we check it in PMIC mode. Linux driver doesn't touch this as far as I've looked.

Above is our reason to believe that ldo-bypass is doing something funny in U-Boot, thus causing WDT to go haywire.

Thanks igorpadykov for your explanation. I didn't know that imx6q has a second wdog block purposed this way on SabreSD. Just curious, that in ldo-enabled mode, shouldn't a WDT triggered reset read WDT as reset cause in src_regs->srsr?

Having the cause as POR makes sense for wdog1, which feeds PWRON on PMIC via WDOG_B, but I'm getting the same behavior for wdog2.