I'm trying to get the watchdog timer on my BeagleBoard XM Rev. C to
work correctly. Right now I am using the code exactly as found on the
following site to test out the watchdog: http://embeddedfreak.wordpress.com/2010/08/23/howto-use-linux-watchdog/
. Kicking the watchdog works as it should. The problem is that upon
timeout, the watchdog doesn't reboot the computer. The computer
becomes non-responsive and requires that I manually power cycle it.
Nothing suspicious shows up in the logs. Also, upon timeout, nothing
gets output to an external monitor or via the serial port. The board
simply hangs. One interesting note is that when running the watchdog
program again after cycling the board, the program detects that "Last
boot is caused by : Watchdog". I think that's a pretty strong
indication that the board is being kicked into a weird, intermediate
state.
I found a couple of threads on here dated last year in which the same
problem was described. No resolution was posted on those threads, so
I decided to start this one in the hopes that someone has an idea of
what might be going on.
I just wanted to relay the results of a little more tinkering:
1. I disabled the OMAP watchdog, enabled the software watchdog,
recompiled the kernel, and booted it on the board. The exact same
behavior was observed; the BeagleBoard XM Rev C. just hangs.
2. I ran the same watchdog program on the Beagle Bone. It works as
intended; the Beagle Bone reboots on a timeout.
I found a solution at this site: http://gumstix.8.n6.nabble.com/Watchdog-timer-not-working-in-gumstix-overo-td812498.html
; look for the post near the bottom by a user named Steve Sakoman. In
summary, he recommends enabling the TWL4030 watchdog driver. Having
enabled that driver and disabled all other in my kernel config and
re-compiled the kernel, I can confirm that his suggestion works on my
BeagleBoard xm Rev. C.
Quick postscript/caveats about using the TWL4030 driver on the XM:
1. You can't get detect the correct status of the powercycle using
WDIOC_GETBOOTSTATUS. It will always return that the system was power
cycled normally. I traced down the difference in the omap and twl4030
drivers in the kernel source. There's a special function for
omap16xx,24xx,etc. that's used to get the boot status. I've pinged
the linux-omap about this issue on the Texas Instrument's Omap
Processor's Linux development mailing list. I will post anything that
comes of that on here.
2. When running the demo code in my original post, naming the
executable using the term "watchdog" results in some very strange
behavior. The system will reboot, but the executable is a 0 bytes
size file upon reboot. No joke. The problem doesn't happen if I
rename the executable to, say, "demo." Very, very spooky.