Re: Questions about Watch Dog Timer under Linux.

[Cypher Wu]

I'm not sure if there is already a framework to cope with this
situation, or I've design it myself to use kernel thread to work with
the real WDT and interface to the user space application? And since
the WDT start to work just a very short interval after the system
power on, do I have to modify mboot  and Linux kernel to support dog
clearing from the very beginning?


On Thu, Dec 10, 2009 at 12:29 AM, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> wrote:
>> products is usually a seperate chip on the board wich will start to
>> work after power reset and will time out in 2 seconds. The system has
>> to start dog clearing from the very beginning and there have no way to
>> disable WDT.
>
> That will be fun as you will probably need to start some kind of kernel
> task refereshing it early in boot unless your boot is very quick.
>
> If it cannot be disabled then you don't need to support the disable
> option. The watchdog API is a range of features designed to cover all
> watchdogs. Many only have a few of the features. A large number of the
> supported watchdogs only support a single timeout rate.
>
>> Is this the pattern we have to follow to use WDT under Linux? We have
>> to choose a chip as WDT, and it seems the chip we've familiar under
>> embedded systems can't be used under Linux?
>
> There are two ways to handle this depending on your needs and what the
> applications require. The first is to provide the real hardware interface
> - 2 second fixed timeout, no disable. That's perfectly sufficient.
>
> The other (which some devices do) is to create a kernel thread that
> refreshes the watchdog each second but *only* if a user application has
> made a watchdog call within the last [whatever] seconds. That also allows
> you to provide a disableable watchdog. More flexible but extra work and
> if your embedded system doesn't need the extra facilities - why bother 8)
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/