Return to BSD News archive
Newsgroups: comp.unix.bsd
Path: sserve!manuel.anu.edu.au!munnari.oz.au!news.hawaii.edu!ames!saimiri.primate.wisc.edu!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!hamblin.math.byu.edu!news.byu.edu!ux1!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: [386BSD] 16550 Not Resetting.
Message-ID: <1992Dec1.202945.10779@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
References: <CGD.92Nov26175845@toe.CS.Berkeley.EDU> <1992Nov28.115716.8219@runx.oz.au> <CGD.92Nov28202543@eden.CS.Berkeley.EDU>
Date: Tue, 1 Dec 92 20:29:45 GMT
Lines: 64
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:
>>There is no way that the BIOS or a DOS driver can fully initialize an
>>unsupported chip. Some of the bits to initialize a 16550 are in a register
>>that doesn't need initializing for 8250-16450's. Control-Alt-Del doesn't
>>reset the chip because the reset is soft.
>
><sigh> tell me, how long has the '550 been around?
It isn't the BIOS's job to know what hardware is in the machine -- it's the
machines job. The very idea of a "probe" routine is a dodo from a long
time ago, and is only necessitated by a stupid bus architecture (and we're
going to have to continue living with it for the forseeable future).
IMHO, it's the hardware designer who has fallen down on the job, since a
bus reset should return all devices to power-on state, and it doesn't do
this for 16550 based serial cards... ie: the hardware design is inapropriate
for the stupid bus architecture.
[ ...how to reset a 16550 for ":DOS mode"... ]
>but remember, to do this correctly, EACH driver in the system needs a
>"pre-reboot" entry point (or a placeholder which does nothing).
>
>What i'm saying is, it's not feasible to add this support, when this is
>the only instance thus far that i've seen that could use it, and this (only)
>instance is the cause of faulty design.
>
>the people who work on 386bsd can't be held accountable for the fact
>that other software running on the same machine my not work correctly.
I think we need to do something here. The 16550 is *not* the only place that
needs a soft device driver shutdown:
o 16550 FIFO shutdown
o WD8003EB shutdown
o SL/IP link shutdown
o DCD drop on all modem lines
All of these could be implemented with a "shutdown" -- or a "detach",
antecedant to the "attach".
Many people with WD8003's and compatables have found that a cold boot is needed
to keep their cards from "going away" -- they aren't recognized by the probe
routine in their initialized state.
The DCD drop on all lines is important for anyone who makes outgoing UUCP
(or other) connections long distance or on a shared line.
There are adequate reasons for a "detach" routine to support it's addition
to the device driver interface.
Terry Lambert
terry@icarus.weber.edu
terry_lambert@novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.
--
-------------------------------------------------------------------------------
"I have an 8 user poetic license" - me
Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------