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.
That is true, we only have 24MHz, but the clock time in Linux is not fast by 15% like the watchdog.
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.
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
BSP is from Yocto:
linux-fslc-imx
This is Yocto Kirkstone.
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
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?
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!
==================================
==================================
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.
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.
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
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.
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
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
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
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?