> Richard B. Johnson wrote:
> > On Mon, 15 Mar 1999, Wall, Tim wrote:
> >
> > > I have a single-board computer with a hardware watchdog which uses I/O
> > > addresses 0x80, 0x443, and 0x444.
> > >
> > > The problem is that something else in the system is writing to 0x80,
> > > which resets/disables the watchdog.
> > >
> >
> > 0x80 is the manufacturing test port. If you have a watchdog that
> > cares about that, it's broken. The kernel didn't reserve it, the
> > AT-Class hardware did. In fact during POST, you can read numbers
> > written to that port to see how far a, possibly defective, board
> > has gotten upon power up.
>
> But, using port 0x80 to keep the watchdog from activating is a good
> way of making sure that the system comes through the POST before the
> watchdog kicks in....
Hmmm. Then have the watchdog reset the system as soon as it attempts
to boot? This is not my idea of a "good way". The usual way is to
read or write something to the watchdog's port to turn it off during
POST. Thereafter, after the first access to its port turns it back
on. A common WD timer is the Dallas Semiconductor DS1232. It sits at
0x878. Writing a 1 starts it, thereafter it must be written with a
bit 0,0, followed by a bit 0,1 to keep it from resetting. Since this
is a "system controller", i.e., a port that can be configured to do
whatever the designer wanted, this of course is machine dependent.
In this case, setting bit 7,1 turns it off, which also happens upon
reset.
>
> Read Alans reply for the hint on how to get along.
>
> Roger.
I did. There may not be any other "safe" port. Writing to a port
that is not any anybody's hardware decode does nothing useful. You
need the hardware's bus activity to create the necessary delay.
Cheers,
Dick Johnson
***** FILE SYSTEM WAS MODIFIED *****
Penguin : Linux version 2.2.3 on an i686 machine (400.59 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/