Hi,
I have a problem with Linux not rebooting when the RTC watchdog is enabled in U-Boot. The stmp3xxx_rtc watchdog driver is enabled in Linux and there's a watchdog daemon that triggers the /dev/watchdog device. Everything was working so far and the watchdog rebooted the device after a while if the watchdog daemon was killed. Then I modified U-Boot to enable the watchdog before loading Linux. I had to modify U-Boot to add a driver with the hw_watchdog_init() and hw_watchdog_reset() functions and call the hw_watchdog_init in the board_init() function. The watchdog works fine in U-Boot, but now, Linux doesn't reboot on a reboot command, it gets stuck on : reboot: Restarting system. On a watchdog timeout it just freezes. When I disable the watchdog in U-Boot, everything still works fine.
I tried rewriting the Linux mxs_restart() function in arch/arm/mach-mxs.c to reset the device using the watchdog instead of using the reset chip function and made sure to enable the AUTO_RESTART bit in the RTC_PERSISTENT0 register. It still doesn't reboot..
The board is using a TQMa28 module. Linux kernel is 5.10.19 with some patches applied for the board.
Any help would be appreciated. Thanks!
Solved! Go to Solution.
Hi @Yuri,
The problem was caused by a wrong RTC clock setup in the rtc-stmp3xxx Linux driver. If WATCHDOGEN is active, the RTC initialization is skipped and the wrong clock is set. It seems the RTC_XTAL_32768_PRESENT fuse bit was not blown. I added a stmp,crystal-freq = <32768>; entry in the device-tree and that fixed the problem. It reboots fine now.
Regards,
Jocelyn
Hi Yuri,
I'm not sure I understand how this is related to the watchdog activation. It reboots fine when the rtc watchdog is not activated in U-Boot which is done by setting WATCHDOGEN bit in the HW_RTC_CTRL register and AUTO_RESTART bit in the HW_RTC_PERSISTENT0.
Thanks,
Jocelyn
@harj1607
Hello,
when (software) processor reset is issued, system tries to boot again;
but if external boot device is in unpredictable state (is not reset) - system
may hang.
Regards,
Yuri.
Hi @Yuri,
The problem was caused by a wrong RTC clock setup in the rtc-stmp3xxx Linux driver. If WATCHDOGEN is active, the RTC initialization is skipped and the wrong clock is set. It seems the RTC_XTAL_32768_PRESENT fuse bit was not blown. I added a stmp,crystal-freq = <32768>; entry in the device-tree and that fixed the problem. It reboots fine now.
Regards,
Jocelyn
@harj1607
Hello,
It is recommended to remove power (voltages) from all board
components if a processor reset occurs - in order to avoid
situations, when components, critical for system rebooting,
are not in the necessary (reset) state to support the reboot.
Voltage rising for VDDD, VDDA and (especially) VDDIO should start
up from 0V. VDDIO should be discharged to 0V.
Also iMX28 GPIOs should not be powered before VDDIO is ready,
otherwise, it would cause iMX28 boot failure.
Regards,
Yuri.