This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Re: watchdog - powerpc


On Fri, May 23, 2003 at 10:05:37AM +0200, Bob Koninckx wrote:
> 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

The SA1110 and LAKI are different. Once its started, you cannot stop
it. You must keep polling it otherwise it causes a hardware reset. So
for these two targets at least, redboot needs to keep polling it, or
the target will reboot. 

> 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 :)

Unfortunately, its not possible to freeze it on our targets for
debugging. So when debugging we have ensure we don't start it in the
first place.

      Andrew

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]