I'm used to work on embedded systems, the Watch Dog Timer in our
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.
Now I want to use WDT under Linux, while I read
Documentation/watchdog/watchdog-api.txt and then look though some
drivers of WDT under Linux, it seems WDT under Linux has to be able to
be disabled, and it will be disabled from the beginning, and starting
to work after the application open the special driver file? The
sample code under Linux use a very bigger time span than our embedded
system:
while (1) {
ret = write(fd, "\0", 1);
if (ret != 1) {
ret = -1;
break;
}
ret = fsync(fd);
if (ret)
break;
sleep(10);
}
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?
On Wed, Dec 09, 2009 at 10:47:28PM +0800, Cypher Wu wrote:
> I'm used to work on embedded systems, the Watch Dog Timer in our
> 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.
> Now I want to use WDT under Linux, while I read
> Documentation/watchdog/watchdog-api.txt and then look though some
> drivers of WDT under Linux, it seems WDT under Linux has to be able to
> be disabled, and it will be disabled from the beginning, and starting
> to work after the application open the special driver file? The
> sample code under Linux use a very bigger time span than our embedded
> system:
You don't *have* to be able to disable the watchdog - the API supports
it but you can always fail to do so (and even where you can Linux
watchdogs support a non-disabling mode, look for WATCHDOG_NOWAYOUT in
existing drivers). Similarly, there's no problem with having the
watchdog be live at system startup - if the watchdog is already enabled
when the driver is opened then the driver just needs to handle that
gracefully.
> while (1) {
> ret = write(fd, "\0", 1);
...
> sleep(10);
> }
>
> Is this the pattern we have to follow to use WDT under Linux? We have
You're free to update the watchdog as often as you like, the 10s is
just a number that was picked which is suitable for that application.
> to choose a chip as WDT, and it seems the chip we've familiar under
> embedded systems can't be used under Linux?
Nothing about your watchdog sounds particularly unusual for Linux.
> 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)
On 09/12/09 14:47, Cypher Wu wrote:
> I'm used to work on embedded systems, the Watch Dog Timer in our
> 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.
wow 2 seconds :(
It's easy to patch grub stage 1 to pat the watchdog.
I was even able to get support for the complicated iTCO intel
watchdogs in there, though your watchdog may be much simpler.
Then when the kernel started it patted the watchdog as normal.
Note I did this to support robust remote upgrade (as the boot
loader wasn't touched on upgrade), rather than to support a
very short timeout.
cheers,
P?draig.
It seems WATCHDOG_NOWAYOUT is a software mechanism? If it is defined
as 1 then the WDT can't be stopped if it has been started whether bye
closing the device file or writing the magic character 'V'.
On Wed, Dec 9, 2009 at 10:59 PM, Mark Brown
<[email protected]> wrote:
> On Wed, Dec 09, 2009 at 10:47:28PM +0800, Cypher Wu wrote:
>> I'm used to work on embedded systems, the Watch Dog Timer in our
>> 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.
>
>> Now I want to use WDT under Linux, while I read
>> Documentation/watchdog/watchdog-api.txt and then look though some
>> drivers of WDT under Linux, it seems WDT under Linux has to be able to
>> be disabled, and it will be disabled from the beginning, and starting
>> to work after the application open the special driver file? The
>> sample code under Linux use a very bigger time span than our embedded
>> system:
>
> You don't *have* to be able to disable the watchdog - the API supports
> it but you can always fail to do so (and even where you can Linux
> watchdogs support a non-disabling mode, look for WATCHDOG_NOWAYOUT in
> existing drivers). Similarly, there's no problem with having the
> watchdog be live at system startup - if the watchdog is already enabled
> when the driver is opened then the driver just needs to handle that
> gracefully.
>
>> while (1) {
>> ret = write(fd, "\0", 1);
>
> ...
>
>> sleep(10);
>> }
>>
>
>> Is this the pattern we have to follow to use WDT under Linux? We have
>
> You're free to update the watchdog as often as you like, the 10s is
> just a number that was picked which is suitable for that application.
>
>> to choose a chip as WDT, and it seems the chip we've familiar under
>> embedded systems can't be used under Linux?
>
> Nothing about your watchdog sounds particularly unusual for Linux.
>
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 <[email protected]> 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)
>
>
Less than 2 seconds is not a thing in our embedded system, the WDT
we've already used will time out every 1.6s, and only a WDI connection
to support timer clearing. I'm not sure if we depend on a user
application to clearing the dog directly, is this too short for Linux
since it's not a RTOS.
2009/12/10 P?draig Brady <[email protected]>:
> On 09/12/09 14:47, Cypher Wu wrote:
>>
>> I'm used to work on embedded systems, the Watch Dog Timer in our
>> 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.
>
> wow 2 seconds :(
>
> It's easy to patch grub stage 1 to pat the watchdog.
> I was even able to get support for the complicated iTCO intel
> watchdogs in there, though your watchdog may be much simpler.
>
> Then when the kernel started it patted the watchdog as normal.
>
> Note I did this to support robust remote upgrade (as the boot
> loader wasn't touched on upgrade), rather than to support a
> very short timeout.
>
> cheers,
> P?draig.
>
On Fri, Dec 11, 2009 at 04:27:55PM +0800, Cypher Wu wrote:
Please reply in-line to e-mails, it makes the conversation much easier
to follow.
> It seems WATCHDOG_NOWAYOUT is a software mechanism? If it is defined
> as 1 then the WDT can't be stopped if it has been started whether bye
> closing the device file or writing the magic character 'V'.
Yes, it's a kernel build time configurable option to select this
behaviour. In effect all you'd be doing is making a driver which turns
it on all the time.
On Fri, Dec 11, 2009 at 6:21 PM, Mark Brown
<[email protected]> wrote:
> On Fri, Dec 11, 2009 at 04:27:55PM +0800, Cypher Wu wrote:
>
> Please reply in-line to e-mails, it makes the conversation much easier
> to follow.
>
>> It seems WATCHDOG_NOWAYOUT is a software mechanism? If it is defined
>> as 1 then the WDT can't be stopped if it has been started whether bye
>> closing the device file or writing the magic character 'V'.
>
> Yes, it's a kernel build time configurable option to select this
> behaviour. In effect all you'd be doing is making a driver which turns
> it on all the time.
>
My point is not making a driver which turns WDT on all the time, but
how to work with a WDT hardware which will startup to working just
after power on and the only interface it provides is clearing the
timer. This type of WDT is widely used in our embedded systems and we
usually install a callback in timer interrupt to clearing WD before
BSP starting the RTOS kernel, and then starting a task to clear WD and
uninstall the callback.
I'm wonder when cope with that type of WD, is there any framework
already in the Linux kernel and booter, or I've to modify them by
myself?
> timer. This type of WDT is widely used in our embedded systems and we
> usually install a callback in timer interrupt to clearing WD before
> BSP starting the RTOS kernel, and then starting a task to clear WD and
> uninstall the callback.
> I'm wonder when cope with that type of WD, is there any framework
> already in the Linux kernel and booter, or I've to modify them by
> myself?
Without knowing which boot environment you are using I don't know. For
the kernel itself you may need to touch the timer early on in boot (in
your platform setup code), then set up the driver early on.
There isn't a general framework for this although there may be one I
don't know about implemented in some other specific platform.
Alan