*BSD News Article 8371


Return to BSD News archive

Newsgroups: comp.unix.bsd
Path: sserve!manuel.anu.edu.au!munnari.oz.au!metro!ipso!runxtsa!bde
From: bde@runx.oz.au (Bruce Evans)
Subject: Re: [386BSD] 16550 Not Resetting.
Message-ID: <1992Nov30.131213.18948@runx.oz.au>
Organization: RUNX Un*x Timeshare.  Sydney, Australia.
References: <CGD.92Nov26175845@toe.CS.Berkeley.EDU> <1992Nov28.115716.8219@runx.oz.au> <CGD.92Nov28202543@eden.CS.Berkeley.EDU>
Date: Mon, 30 Nov 92 13:12:13 GMT
Lines: 43

In article <CGD.92Nov28202543@eden.CS.Berkeley.EDU> cgd@eden.CS.Berkeley.EDU (Chris G. Demetriou) writes:
>In article <1992Nov28.115716.8219@runx.oz.au> bde@runx.oz.au (Bruce Evans) writes:
>>...  Some of the bits to initialize a 16550 are in a register
>>that doesn't need initializing for 8250-16450's. ...

><sigh>  tell me, how long has the '550 been around?

A fair while, but you will not find them in the average PC.  It might save a
whole $5 per 16550 to leave them out.

>>These bits are documented to be 0 for 8250-16450 chips.

>generally, good designers consider bits with no function
>but labeled as a certain value to be for identification only...
>and they consider them "reserved"... (and they mask them off, when checking/
>setting things...)

That's more or less what I said.  When bits are in a register that is
documented as read-only, only bad software and hackish software such as
the 386BSD probe sequence writes to the register at all.

>>	   outportb(port + 2, 0);		/* turn FIFO off */
>...
>but remember, to do this correctly, EACH driver in the system needs a
>"pre-reboot" entry point (or a placeholder which does nothing).

I meant the outportb as a hack for DOS (it's in Turbo C).  It works when
run from the DOS autoexec.bat because the com "drivers" in the BIOS don't
do anything much.

>Chris
>(a software-elitist...)

Blame the hardware.  After the software has put the h/w in a weird state,
it is often too difficult, and sometimes impossible, to recover without a
full h/w reset.  Yet the h/w doesn't provide any (standard?) way to force
a h/w reset from s/w.  386BSD shuts down by causing a triple fault.  My
understanding is that this doesn't reset the h/w, it just shuts down the
cpu, then on most systems the motherboard h/w detects the shutdown and
causes some sort of reset.  I wonder why the reset isn't full?  Perhaps
so that it can be used to switch 286's out of protected mode.
-- 
Bruce Evans  (bde@runx.oz.au)