Re: [ECOS] Re: watchdog - powerpc

[Bob Koninckx <bob dot koninckx at mech dot kuleuven dot ac dot be>]

On Fri, 2003-05-23 at 09:40, Andrew Lunn wrote:
> >> Or arguably just write a standard watchdog device driver (as lives in 
> >> devs/watchdog and uses io/watchdog) and include it in the RedBoot 
> >> image.... and if CYGPKG_IO_WATCHDOG isn't defined in <pkgconf/system.h> 
> >> just disable the watchdog entirely in SYPCR.
> >
> >That's what I planned to do. I was just looking for a way to avoid this
> >kind of coupling between redboot and the application. Because of the
> >write-once nature of the SYPCR register and the watchdog being enabled
> >by default, redboot and the application can not decide independently on
> >the use of a watchdog.
> 
> This is a generic problem actually. Recently code has been added so
> that the application can exist back to Redboot. If the application has
> started the watchdog, redboot needs to know to take over polling when
> the application returns. 

Not really, not in the case of the powerpc anyway. You have the
following possibilities

1. redboot does not disable it (which is more or less the same as
starting it). If redboot does not service it, then we might end up
having problems in redboot. If an application which decided to disable
it, returns to redboot, the latter will be serving a disabled watchdog,
which is not really usefull, but not really problematic either.

2. redboot does disable it, so there is no need for servicing it. Now
the application can not re-enable it due to the write-once nature of the
SYPCR configuration register. After the application returns, redboot
will thus still behave correctly.

Things would have been a lot easyer if the powerpc would start up with
the watchdog _disabled_ or SYPCR not being write-once ....

I suppose the only valid option is to _always_ use a watchdog in the
case of the powerpc and _never_ disable it. I have two arguments for
this. First, any embedded device will rely on a watchdog for its correct
operation. And second, this should also not interfere with the debugger
as the watchdog can be "frozen" during breakpoints etc (both with a
rom-monitor or BDM). It has the additional advantage that the watchdog
can be (ab)used to deliberately trigger a hard reset of the board from
software. This is how I am going to use it anyway. Unless somebody comes
up with some great idea :)

Bob

 

> 
>     Andrew
-- 
----------------------------------------------------------------------
ir. Bob Koninckx
Katholieke Universiteit Leuven
Division Production Engineering,                   tel.  +32 16 322535
Machine Design and Automation                      fax.  +32 16 322987
Celestijnenlaan 300B                  bob.koninckx@mech.kuleuven.ac.be
B-3001 Leuven Belgium               http://www.mech.kuleuven.ac.be/pma
----------------------------------------------------------------------


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss