Hello,
How can I enable the watchdog automatically at kernel boot for a vf61 module. I’ve added status=“okay” instead of “disabled” in the device-tree. But it does not seem to work like this.
Second if I would like to enable the watchdog from u-boot using something like mw.w address value. 0x4003e000 seems to be the watchdog address but I’m not sure what I should write to this address.
Regards,
I’ve already found out I can start the watchdog with:
mw.w 0x4003e000 xx34 1 (xx time)
So the module will reset after xx timeout. I will boot the module after I’ve started the watchdog. It looks like the kernel stops the watchdog during boot. Any idea how to prevent this?
Regards,
Watchdog is enabled by default, look at this. One can pass the timeout to the watchdog driver via kernel argument. Have a look at this article ?
Hello,
Thanks for your reply. I would expect once I’ve triggered the watchdog in u-boot it would reset the board if I don’t retrigger it again once the kernel has started. But it seems the watchdog is “turned off” . If I don’t boot the kernel and wait in u-boot there will be a watchdog reset after it has timed out. So question is what do I need to do to keep it running during kernel boot. Once the system has fully booted ofcourse I need to retrigger it to make sure there won’t be a watchdog reset.
Regards, Chris
As @bhuvan.tx stated, the watchdog driver for the A5 watchdog instance of the Vybrid SoC is enabled by default. However, on startup, the Linux driver will reset the watchdog settings (disable it) and only enable it if a client requests it…
In the end the question is what you want to watch… The kernel does not use watchdog to monitor itself, but it just allows access to the watchdog via /dev/watchdog. You need to have a user space application which requests the watchdog. This is typically your mission critical process… As soon as the user space application does not respond anymore (either because the kernel crashed or just the application), the watchdog won’t get serviced anymore and a reboot will be triggered.
You can also use Watchdog support built-in to the service manager systemd.
Refer to our Watchdog (Linux) article.
Hi Stefan,
That’s totally clear. But asume the kernel crashed even before the user application was able to start. As you said the kernel disabled the watchdog on boot. The userspace application was unable to start, so the watchdog will never be enabled again. So in this situation I would like to have the watchdog started as early as possible in the boot process. I will choose a timeout long enough for the kernel and userspace application to get up and running. The userspace application will retrigger the watchdog before it times out. So I have to find out how to prevent the kernel from disabling the already enabled watchdog during the boot process so it will keep counting.
Regards,
Hm, I guess it’s this line in probe:
Ok, I see your point, I guess that makes sense.
There is also the nmi_watchdog, see Documentation/lockup-watchdogs.txt. The kernel also has also some software mechanism to reboot in case of crashes, you might want to look at the panic and oops kernel parameters.
That’s the power down enable bit. This bit is already reset in u-boot. Otherwise u-boot would also reset after 16 seconds. According to the datasheet:
Power Down Enable bit. Reset value of this bit is 1, which means the power down counter inside the WDOG is enabled after reset. The software must write 0 to this bit to disable the counter within 16 seconds of reset de-assertion. Once disabled this counter cannot be enabled again. See Power-down counter event for operation of this counter.
Hm, I see what you are saying.
It seems that Linux is not actually disabling the Watchdog (since that is not possible) but just service it using a kernel level timer:
The timer calls imx2_wdt_timer_ping every 30 seconds or so.
I also found the answer this afternoon. Didn’t have time to post until now. As long as the watchdog device is closed the timer takes care of the pinging of the watchdog every 30seconds. Thanks for your support!
Anybody any idea which part stops the watchdog during boot? I’ve been looking to the imx2-wdt driver but I don’t see a obvious “stop” being callled. If I remove the driver from the device-tree the watchdog keeps counting and in the end resets the module.
Thanks for this answer, @stefan.tx
What else did you discovered, @sirhc?
Nice to see that the Watchdog is enabled by default in the vf500.dtsi file.
But like @stefan.tx said, it is no enabled by default at the boot process.
Some application need to start feeding the /dev/watchdog to make it start “really” working.
I have a situation here quite similar to @sirhc: I need the watchdog to “really” start at the boot.
If my application (which feeds the watchdog) does not start properly, the equipment should be reinitialized by the watchdog.
And if the boot process got stuck by something, the watchdog should do its work, don’t you agree?
(Like what I’m facing in using the PREEMPT_RT patch…)
After all, how could I effectively activate the watchdog at boot?
I’ve just put mw.w 0x4003e000 xx34 (xx timeout time) in my bootcmd at the first position. This will start the watchdog before the kernel boots. Some background process based on a timer will retrigger the watchdog periodically as described above.
I have a situation here quite similar to @sirhc: I need the watchdog to “really” start at the boot.
You can start the Watchdog in U-Boot with the method mentioned by @sirhc (using mw.w 0x4003e000 xx34 1).
To avoid any possible issues on the user space side, you need to make sure that already the first process uses the watchdog. This can be by either using a Watchdog aware init system (e.g. systemd) or start your application directly as a only/“init process”…
The kernel being stuck is always somewhat unfortunate, it can happen that the kernel is in a deadlock situation (e.g. between two processes) and that interrupts/timers are still running… The kernel has lots of software mechanism to automatically reboot on lockups and kernel oops (see panic_timeout described here).
However, with such issues in mind, it seems to me that the i.MX wdt2 drivers standard behavior is not ideal. I guess this has been introduced with the idea that the kernel is “sound”, and only user space needs to be watched… However, removing that behavior from drivers/watchdog/imx2_wdt.c should be rather trivial: Remove the timer or simple don’t do anything in the timer callback.
Thanks for the question. Has this methodology to be considered for the TK1 as well?
Watchdogs are rather SoC specific. This thread is rather long, not sure what you exactly mean by “this methodology”. Can you post a new question so it can be properly tagged for the TK1?
That worked for me. Thanks you all!
@stefan.tx I created a new question for the TK1 here Enable HW Watchdog for Apalis TK1 at Boot - Technical Support - Toradex Community
