Why does the watchdog for i.MX6ULL happen too soon in Linux?

JohnKlug · ‎03-18-2024

In the file drivers/watchdog/imx2_wdt.c There is a parameter IMX2_WDT_DEFAULT_TIME.

This is set to 60 seconds.

When set to 60 seconds the following code sees approximately 50 seconds before the system resets:

echo >/dev/watchdog0;while : ; do date ;sleep 1;done

If I set the value of IMX2_WDT_DEFAULT_TIME to 128, then I see a time out of 110 seconds.

Why does it not wait the full timeout period before stopping?

We are using an i.MX6ULL with a 528MHz clock speed.

JohnKlug

That is true, we only have 24MHz, but the clock time in Linux is not fast by 15% like the watchdog.

liangtao

It is known from the manual that Watchdog uses a Low Frequency Reference Clock.
Internal 32k RC oscillator can be used instead if a high accuracy RTC is not required, in this case RTC-XTALI should be tied to GND and left RTC-XTALO floating.
If your design already does that, then I don't have any good ideas.

weidong_sun · ‎03-18-2024

Dear @JohnKlug ,

Could you tell me the BSP version you are using?

My colleague tested it on i.mx6ull + L6.1.55_2.1.0 and kept if for a period of time.

The issue can't be reproduced.

Would you please share your method to trigger watchdog?

Thanks!

Regards,

weidong

JohnKlug · ‎03-19-2024

BSP is from Yocto:

linux-fslc-imx

This is Yocto Kirkstone.

weidong_sun · ‎03-19-2024

Dear @JohnKlug ,

I tested it again on L6.1.55 BSP using your command. It seems that the time for watchdog reset is no problem, see screenshot, please!

If you think it is ok, would you please use the version of bsp for your product?

Thanks!

Regards,

weidong

JohnKlug · ‎03-20-2024

I checked the kernel you are using, and the only watchdog related change I am missing is this one:
https://github.com/nxp-imx/linux-imx/commit/cf6e4bc16dba2068fa4a115300185a8c56edc93f

I then looked at our evaluation board for the i.MX6ULL. It is also running the 5.15 Kirkstone kernel that we use on our board. It resets in 60 seconds, as does yours.

So this makes me think this is a hardware/clocking issue.

Our CPU is:
MCIMX6Y2CVM05AB

As I said, this is a 528MHz part, and the evaluation board is using a 900MHz part.

Did you use the MCIMX6Y2CVM05AB CPU to run your test?

weidong_sun · ‎03-21-2024

Dear @JohnKlug ,

The iMX6ULL part number on my board is MCIMX6Y2DVM09AB, which is 900MHz.

I checked imx6ull.dtsi, Could you tune it like below? Then try it, please!

==================================

Thanks!

Regards,

weidong

JohnKlug · ‎03-22-2024

I see this during boot:

[    3.149617] cpu cpu0: failed to disable 792MHz OPP
[    3.154464] cpu cpu0: failed to disable 900MHz OPP

I don't know if this helps:

bash# cat /proc/cpuinfo
processor       : 0
model name      : ARMv7 Processor rev 5 (v7l)
BogoMIPS        : 48.00
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xc07
CPU revision    : 5

Hardware        : Freescale i.MX6 Ultralite (Device Tree)
Revision        : 0000
Serial          : 111279d7614ecc8e

It is interesting that the BogoMIPS value is the same as the 900MHz part, and the only difference is the serial number.

JohnKlug · ‎03-22-2024

Unfortunately that did not fix the issue.

I include the imx6ull.dtsi in my device tree, and I added the following stanza:

&cpu0 {
        clock-frequency = <528000000>;
        operating-points = <
                /* kHz  uV */
                528000  1175000
                396000  1025000
                198000  950000
        >;
        fsl,soc-operating-points = <
                /* KHz  uV */
                528000  1175000
                396000  1175000
                198000  1175000
        >;
};

I verified that clock-frequency is no longer 900MHz

bash# pwd
/proc/device-tree/cpus/cpu@0
bash# xxd -g4 clock-frequency
00000000: 1f78a400 .x..

However the watchdog is still about 15% fast.

weidong_sun · ‎03-24-2024

Dear @JohnKlug ,

I checked cpufreq driver: drivers/cpufreq/imx6q-cpufreq.c

It means 900M & 792M settings in dts will be disabled if cpu frequency in fuse map doesn't support one of them. So original dts is no problem for i.MX6ULL 528M version, from our previous discussions, no need to change it. At the same time, according to code in imx6q-cpufreq.c, our change in dts(remove 900M & 792M) will not affect normal operations of system, too.

The i.mx6ll-evk I have on hand, the CPU is the 900M version.

Could you test L6.1.55_2.1.0 BSP on you board? Let us check if watchdog time out is correct.

Thanks!

Regards,

weidong

JohnKlug · ‎03-25-2024

This would not be a small effort for me to try 6.1 on our board. I don't know when I will have time to try that.

It would be better if you could point out which patches would fix the problem and I could then apply the patches to 5.15.

I have already show that 5.15 works correctly on a 900MHz processor.

JohnKlug · ‎03-25-2024

Ideally we would like the watchdog timeout to be about 5 minutes. Do you know any register changes that might run the watchdog timeout to a longer value? For instance TI processors that we use have much longer hardware watchdog timeout values possible.

weidong_sun · ‎03-25-2024

Dear @JohnKlug ,

On page 4093 of reference manual, we can find register.

But max value is 128s, so 300s can not be supported.

I will test it again on 5.15 bsp.

wait for my test result, please!

Thanks!

Regards,

weidong

weidong_sun · ‎03-27-2024

Dear @JohnKlug ,

I tested L5.15.71_2.2.2 DEMO image on iMX6ULL-EVK (14X14), it is no problem.

===========================================================================

root@imx6ul7d:~# echo >/dev/watchdog0;while : ; do date ;sleep 1;done
[ 64.619726] watchdog: watchdog0: watchdog did not stop!
Thu Apr 28 17:43:26 UTC 2022
Thu Apr 28 17:43:27 UTC 2022
Thu Apr 28 17:43:28 UTC 2022
Thu Apr 28 17:43:29 UTC 2022
Thu Apr 28 17:43:30 UTC 2022
Thu Apr 28 17:43:31 UTC 2022
Thu Apr 28 17:43:32 UTC 2022
Thu Apr 28 17:43:33 UTC 2022
Thu Apr 28 17:43:34 UTC 2022
Thu Apr 28 17:43:35 UTC 2022
Thu Apr 28 17:43:36 UTC 2022
Thu Apr 28 17:43:37 UTC 2022
Thu Apr 28 17:43:38 UTC 2022
Thu Apr 28 17:43:39 UTC 2022
Thu Apr 28 17:43:40 UTC 2022
Thu Apr 28 17:43:41 UTC 2022
Thu Apr 28 17:43:42 UTC 2022
Thu Apr 28 17:43:43 UTC 2022
Thu Apr 28 17:43:44 UTC 2022
Thu Apr 28 17:43:45 UTC 2022
Thu Apr 28 17:43:46 UTC 2022
Thu Apr 28 17:43:47 UTC 2022
Thu Apr 28 17:43:48 UTC 2022
Thu Apr 28 17:43:49 UTC 2022
Thu Apr 28 17:43:50 UTC 2022
Thu Apr 28 17:43:51 UTC 2022
Thu Apr 28 17:43:52 UTC 2022
Thu Apr 28 17:43:53 UTC 2022
Thu Apr 28 17:43:54 UTC 2022
Thu Apr 28 17:43:56 UTC 2022
Thu Apr 28 17:43:57 UTC 2022
Thu Apr 28 17:43:58 UTC 2022
Thu Apr 28 17:43:59 UTC 2022
Thu Apr 28 17:44:00 UTC 2022
Thu Apr 28 17:44:01 UTC 2022
Thu Apr 28 17:44:02 UTC 2022
Thu Apr 28 17:44:03 UTC 2022
Thu Apr 28 17:44:04 UTC 2022
Thu Apr 28 17:44:05 UTC 2022
Thu Apr 28 17:44:06 UTC 2022
Thu Apr 28 17:44:07 UTC 2022
Thu Apr 28 17:44:08 UTC 2022
Thu Apr 28 17:44:09 UTC 2022
Thu Apr 28 17:44:10 UTC 2022
Thu Apr 28 17:44:11 UTC 2022
Thu Apr 28 17:44:12 UTC 2022
Thu Apr 28 17:44:13 UTC 2022
Thu Apr 28 17:44:14 UTC 2022
Thu Apr 28 17:44:15 UTC 2022
Thu Apr 28 17:44:16 UTC 2022
Thu Apr 28 17:44:17 UTC 2022
Thu Apr 28 17:44:18 UTC 2022
Thu Apr 28 17:44:19 UTC 2022
Thu Apr 28 17:44:20 UTC 2022
Thu Apr 28 17:44:21 UTC 2022
Thu Apr 28 17:44:22 UTC 2022
Thu Apr 28 17:44:23 UTC 2022
Thu Apr 28 17:44:24 UTC 2022
Thu Apr 28 17:44:25 UTC 2022

U-Boot 2022.04-lf_v2022.04+g181859317b (Nov 15 2022 - 06:28:05 +0000)

CPU: i.MX6ULL rev1.1 900 MHz (running at 396 MHz)
CPU: Commercial temperature grade (0C to 95C) at 40C
Reset cause: POR
Model: i.MX6 ULL 14x14 EVK Board
Board: MX6ULL 14x14 EVK
DRAM: 512 MiB
Core: 65 devices, 18 uclasses, devicetree: separate
MMC: FSL_SDHC: 0, FSL_SDHC: 1
Loading Environment from MMC... *** Warning - bad CRC, using default environment

===========================================================================

So the issue is not cause by Linux BSP.

Thanks!

Regards,

weidong

weidong_sun · ‎03-18-2024

Dear @JohnKlug ,

LCD_RESET is multiplexed as nWDOG signal, which is used to reset system.

See schematic & device tree, please!

pinctrl_wdog: wdoggrp {
fsl,pins = <
MX6UL_PAD_LCD_RESET__WDOG1_WDOG_ANY 0x30b0
>;

WDOG_ANY is a global signal, which will send reset signal about 10s in advance. A customer has ever mentioned the similar question.
If you want to use WDOG, a better option is to increase the increment by about 10 seconds.

Thanks!

Regards,

weidong

JohnKlug · ‎03-19-2024

Is there a way to extend the watchdog CPU reset beyond 110 seconds? We would like to set the watchdog to expire at the start of our reboot procedure in case it should hang.

nWDOG is connected to LCD_RESET pad on the i.MX6ULL EVK.

On our board we do not use the watchdog externally from the CPU, and LCD_RESET is not connected.

In my case the watchdog timeout reset is purely internal to the i.MX6ULL, doing a reset after the timer expires.

As to how I set the watchdog to expire, it is in my original posting:

echo >/dev/watchdog0

Do you have an errata that explains why it is short?

liangtao

Could it be that the board you designed does not have 32.768 crystal vibration?