Return to BSD News archive
Path: sserve!manuel.anu.edu.au!munnari.oz.au!spool.mu.edu!agate!agate.berkeley.edu!cgd
From: cgd@erewhon.CS.Berkeley.EDU (Chris G. Demetriou)
Newsgroups: comp.unix.bsd
Subject: multiport serial driver
Date: 15 Nov 92 01:56:35
Organization: Kernel Hackers 'r' Us
Lines: 130
Distribution: world
Message-ID: <CGD.92Nov15015635@erewhon.CS.Berkeley.EDU>
NNTP-Posting-Host: erewhon.cs.berkeley.edu
i've completed a multiport extension to my serial driver stuff...
below is the readme.
note that if you are using the single-port driver, you should install
this new version; there were a few bugs which have been found and killed.
This should be available fromthe following places:
ref.tfs.com (140.145.254.251) ~cgd/com/com-multiport.tar.Z
agate.berkeley.edu (128.32.136.1)
~ftp/pub/386bsd-0.1/unofficial/cgd/com-multiport.tar.Z
enjoy, and, as usual, bugs and complaints to me...
(but remember: i'm *really* busy... end of the semester workload... 8-)
Chris
============= CUT HERE FOR NEW README =============
Spiffy Serial Driver, Yet Again!
It's back, and it handles interrupt sharing... 8-)
(also: a few bug fixes, changed the name of "comcontrol" and its use,
to make it less confusing.)
For the multiport handling:
It's been tested on an AST 4-port card, and various KW-531A
serial boards, all with 16450 and 16550 uarts....
(the hardware that i can support is the subset of the hardware
which i have docs for that i actually own... so if it doesn't
work for you, you get to fix it yourself, or send me hardware
and docs... 8-)
This one is (still) based on the patches to the standard serial driver
made by Brad Huntting and John Kohl. I've added my bidirectional ports
stuff, and the multiport handling...
The out-dialing has been tested extensively, and the bidirectional
aspects have been tested "somewhat" -- therefore this is only a BETA --
use it at your own risk.
This package (including this readme) is also available from
agate.berkeley.edu:pub/386BSD/386bsd-0.1/unofficial/fast-com.tar.Z.
Performance: well, I'm writing this from an xterm sent over a 9600
baud slip line, with a 8250 UART, and it's working... 8-)
Better than my other hacks to the driver...
Features:
performance -- fewer overflows
proper RTS/CTS flow control handling
bidirectional ports, like SunOS
what to do:
move com.c and comreg.h into /sys/i386/isa
apply the patches in "diffs"
make a new kernel
remake and re-install /bin/stty
compile comcontrol, and put it wherever you want.
in terms of device names, etc. this is the same as the patchkit-patched
com.c. that is, devices start at minor number 0.
Device Nodes:
Name: maj: min: purpose:
com00 8 0 dialin port 0, or dialin/dialout if "bidir"
com01 8 1 dialin port 1, or dialin/dialout if "bidir"
etc...
ttyd0 8 128 dialout port 0, if -bidir
ttyd1 8 129 dialout port 1, if -bidir
etc...
how to use:
defaults to "standard" behavior.
use comcontrol to turn on dialin/out behavior, as described below.
note that doing "stty clocal" basically means "carrier detected at all times
on both ports (dialin & dialout)"
have getty run on dialin port, tip out of dialout port.
The following options are possible (put them in your kernel config file):
COM_IGNOREFIFO
turns off checking for the 16550's FIFOs.
this checking can cause problems w/some 16450 clones,
apparently...
COM_MULTIPORT
turn on the interrupt-sharing features.
note that if two or more serial ports share the
same IRQ, all are considered to be on multiport boards.
(this can be a problem if your multiport board uses
IRQ3 or IRQ4, and you want to use an on-board serial port
as well... a fix for this will probably appear later...)
see the example kernel config file (EXAMPLE) for a bit more info.
dialout ports assume carrier exists until a real one is detected,
then CD follows it. dialout ports block on open until real DCD is
detected. (if you don't understand, see the Sun and "zs" manpages)
using comcontrol:
comcontrol <portname>
tells you the status of the port. "bidir" means that the bidirectional
features are disabled, and that the ttyd? ports aren't usable.
"-bidir" means that the bidir ports are enabled.
comcontrol <portname> [-]bidir
to enable/disable bidir ports. You must be root to use it in this manner.
in all cases <portname> is the full path name of the port, and it's
safest to use the dialin port, because that'll always work (i.e.
when bidir ports aren't enabled, you can't open the dialout ports).
Other random schtuff:
things need to be cleaned up a bit.
however, i wanted to get it out the door; i've put
it off too long already... 8-)
i think that's it.
have fun, bugs & comments to cgd@berkeley.edu
Chris
--
Chris G. Demetriou cgd@cs.berkeley.edu
"Sometimes it is better to have twenty million instructions by
Friday than twenty million instructions per second." -- Wes Clark