Date: Thu, 1 Feb 1996 10:30:11 -0600 (CST) From: Joe Greco <jgreco@brasil.moneng.mei.com> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: dgy@rtd.com, freebsd-hackers@freefall.freebsd.org Subject: Re: Watchdog timers (was: Re: Multi-Port Async Cards) Message-ID: <199602011630.KAA08895@brasil.moneng.mei.com> In-Reply-To: <4664.823163192@time.cdrom.com> from "Jordan K. Hubbard" at Feb 1, 96 00:26:32 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > Does this gizmo *need* to reside within the "PC"? Are you really > > wanting to let it grab the bus, poke around, etc.? Or, would something > > more "passive" suffice (i.e. sitting on a serial port external to the > > PC)? > > Actually, I kind of liked the idea of letting it grab ahold of the > bus. It seems that a lot of problems one runs into in PCs these days > stem from individual cards or chipsets not *quite* playing by the > rules, and at times like that you really do want to watch every IRQ > line and have little service routines that are called when one changes > state, or whatever. It's the only way to tell if someone's bogusly > generating an interrupt, or to generate one yourself if you're trying > to simulate some weird peripheral. Well, that is getting a lot more complexicated... :-) I get the feeling I was barking up the right tree to begin with, but just didn't take it far enough. Take a PC card. Stick a microprocessor on it with two serial ports. Connect a 16450 to the PC bus as COM1:, and hard wire it to one of the uP's serial ports. You have "serial console" capability within FreeBSD. Connect an output line from the uP to the PC's reset line. And decode one or two I/O locations and make them available to the uP. Now: you can use the I/O location(s) to control a basic, easy-to-program watchdog function running on the uP. In addition, you can connect a modem (/terminal/whatever) to the uP's other serial port. You could password protect access, which would be handy for remote sites. Once connected, the port could just be a pass-thru to the other port, but you could use BREAK or some other escape sequence to get access to other functions: o Send BREAK to FreeBSD (i.e. break to DDB). One of my worries with serial consoles has been the danger of an inadvertent BREAK halting your system, just like a Sun :-( !! o Send hardware RESET (owwwwww) o See log of recent events (maybe a 10K buffer that saves FreeBSD's console output and writes an appropriate marker if'n'when a watchdog RESET happens, etc). o Etc. You now have a flexible platform which can be programmed to order. You can't do really fancy things like monitoring the PC bus, but you could if you expanded upon the hardware somewhat. Depending on the choice of uP and its I/O capabilities, one might conceivably consider adding multiple point temperature monitoring and/or voltage monitoring as well. This would still not be a terribly complicated device to build: you need a CPU, RAM, ROM, I/O, 2 serial ports, and a 16450. Most of the former can be found integrated in various embedded application uP's. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/546-7968
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602011630.KAA08895>