freebsd-nq/sys/i386/isa
Søren Schmidt 8b8a0b53b1 Add support for busmaster DMA on some PCI IDE chipsets.
I changed a few bits here and there, mainly renaming wd82371.c
to ide_pci.c now that it's supposed to handle different chipsets.

It runs on my P6 natoma board with two Maxtor drives, and also
on a Fujitsu machine I have at work with an Opti chipset and
a Quantum drive.

Submitted by:cgull@smoke.marlboro.vt.us <John Hood>

Original readme:

*** WARNING ***

This code has so far been tested on exactly one motherboard with two
identical drives known for their good DMA support.

This code, in the right circumstances, could corrupt data subtly,
silently, and invisibly, in much the same way that older PCI IDE
controllers do.  It's ALPHA-quality code; there's one or two major
gaps in my understanding of PCI IDE still.  Don't use this code on any
system with data that you care about; it's only good for hack boxes.
Expect that any data may be silently and randomly corrupted at any
moment.  It's a disk driver.  It has bugs.  Disk drivers with bugs
munch data.  It's a fact of life.

I also *STRONGLY* recommend getting a copy of your chipset's manual
and the ATA-2 or ATA-3 spec and making sure that timing modes on your
disk drives and IDE controller are being setup correctly by the BIOS--
because the driver makes only the lamest of attempts to do this just
now.

*** END WARNING ***

that said, i happen to think the code is working pretty well...

WHAT IT DOES:

this code adds support to the wd driver for bus mastering PCI IDE
controllers that follow the SFF-8038 standard.  (all the bus mastering
PCI IDE controllers i've seen so far do follow this standard.)  it
should provide busmastering on nearly any current P5 or P6 chipset,
specifically including any Intel chipset using one of the PIIX south
bridges-- this includes the '430FX, '430VX, '430HX, '430TX, '440LX,
and (i think) the Orion '450GX chipsets.  specific support is also
included for the VIA Apollo VP-1 chipset, as it appears in the
relabeled "HXPro" incarnation seen on cheap US$70 taiwanese
motherboards (that's what's in my development machine).  it works out
of the box on controllers that do DMA mode2; if my understanding is
correct, it'll probably work on Ultra-DMA33 controllers as well.
it'll probably work on busmastering IDE controllers in PCI slots, too,
but this is an area i am less sure about.

it cuts CPU usage considerably and improves drive performance
slightly.  usable numbers are difficult to come by with existing
benchmark tools, but experimentation on my K5-P90 system, with VIA
VP-1 chipset and Quantum Fireball 1080 drives, shows that disk i/o on
raw partitions imposes perhaps 5% cpu load.  cpu load during
filesystem i/o drops a lot, from near 100% to anywhere between 30% and
70%.  (the improvement may not be as large on an Intel chipset; from
what i can tell, the VIA VP-1 may not be very efficient with PCI I/O.)
disk performance improves by 5% or 10% with these drives.

real, visible, end-user performance improvement on a single user
machine is about nil. :) a kernel compile was sped up by a whole three
seconds.  it *does* feel a bit better-behaved when the system is
swapping heavily, but a better disk driver is not the fix for *that*
problem.

THE CODE:

this code is a patch to wd.c and wd82371.c, and associated header
files.  it should be considered alpha code; more work needs to be
done.

wd.c has fairly clean patches to add calls to busmaster code, as
implemented in wd82371.c and potentially elsewhere (one could imagine,
say, a Mac having a different DMA controller).

wd82371.c has been considerably reworked: the wddma interface that it
presents has been changed (expect more changes), many bugs have been
fixed, a new internal interface has been added for supporting
different chipsets, and the PCI probe has been considerably extended.

the interface between wd82371.c and wd.c is still fairly clean, but
i'm not sure it's in the right place.  there's a mess of issues around
ATA/ATAPI that need to be sorted out, including ATAPI support, CD-ROM
support, tape support, LS-120/Zip support, SFF-8038i DMA, UltraDMA,
PCI IDE controllers, bus probes, buggy controllers, controller timing
setup, drive timing setup, world peace and kitchen sinks.  whatever
happens with all this and however it gets partitioned, it is fairly
clear that wd.c needs some significant rework-- probably a complete
rewrite.

timing setup on disk controllers is something i've entirely punted on.
on my development machine, it appears that the BIOS does at least some
of the necessary timing setup.  i chose to restrict operation to
drives that are already configured for Mode4 PIO and Mode2 multiword
DMA, since the timing is essentially the same and many if not most
chipsets use the same control registers for DMA and PIO timing.

does anybody *know* whether BIOSes are required to do timing setup for
DMA modes on drives under their care?

error recovery is probably weak.  early on in development, i was
getting drive errors induced by bugs in the driver; i used these to
flush out the worst of the bugs in the driver's error handling, but
problems may remain.  i haven't got a drive with bad sectors i can
watch the driver flail on.

complaints about how wd82371.c has been reindented will be ignored
until the FreeBSD project has a real style policy, there is a
mechanism for individual authors to match it (indent flags or an emacs
c-mode or whatever), and it is enforced.  if i'm going to use a source
style i don't like, it would help if i could figure out what it *is*
(style(9) is about half of a policy), and a way to reasonably
duplicate it.  i ended up wasting a while trying to figure out what
the right thing to do was before deciding reformatting the whole thing
was the worst possible thing to do, except for all the other
possibilities.

i have maintained wd.c's indentation; that was not too hard,
fortunately.

TO INSTALL:

my dev box is freebsd 2.2.2 release.  fortunately, wd.c is a living
fossil, and has diverged very little recently.  included in this
tarball is a patch file, 'otherdiffs', for all files except wd82371.c,
my edited wd82371.c, a patch file, 'wd82371.c-diff-exact', against the
2.2.2 dist of 82371.c, and another patch file,
'wd82371.c-diff-whitespace', generated with diff -b (ignore
whitespace).  most of you not using 2.2.2 will probably have to use
this last patchfile with 'patch --ignore-whitespace'.  apply from the
kernel source tree root. as far as i can tell, this should apply
cleanly on anything from -current back to 2.2.2 and probably back to
2.2.0.  you, the kernel hacker, can figure out what to do from here.
if you need more specific directions, you probably should not be
experimenting with this code yet.

to enable DMA support, set flag 0x2000 for that drive in your config
file or in userconfig, as you would the 32-bit-PIO flag.  the driver
will then turn on DMA support if your drive and controller pass its
tests.  it's a bit picky, probably.  on discovering DMA mode failures
or disk errors or transfers that the DMA controller can't deal with,
the driver will fall back to PIO, so it is wise to setup the flags as
if PIO were still important.

'controller wdc0 at isa? port "IO_WD1" bio irq 14 flags 0xa0ffa0ff
vector wdintr' should work with nearly any PCI IDE controller.

i would *strongly* suggest booting single-user at first, and thrashing
the drive a bit while it's still mounted read-only.  this should be
fairly safe, even if the driver goes completely out to lunch.  it
might save you a reinstall.

one way to tell whether the driver is really using DMA is to check the
interrupt count during disk i/o with vmstat; DMA mode will add an
extremely low number of interrupts, as compared to even multi-sector
PIO.

boot -v will give you a copious register dump of timing-related info
on Intel and VIAtech chipsets, as well as PIO/DMA mode information on
all hard drives.  refer to your ATA and chipset documentation to
interpret these.

WHAT I'D LIKE FROM YOU and THINGS TO TEST:

reports.  success reports, failure reports, any kind of reports. :)
send them to cgull+ide@smoke.marlboro.vt.us.

i'd also like to see the kernel messages from various BIOSes (boot -v;
dmesg), along with info on the motherboard and BIOS on that machine.

i'm especially interested in reports on how this code works on the
various Intel chipsets, and whether the register dump works
correctly.  i'm also interested in hearing about other chipsets.

i'm especially interested in hearing success/failure reports for PCI
IDE controllers on cards, such as CMD's or Promise's new busmastering
IDE controllers.

UltraDMA-33 reports.

interoperation with ATAPI peripherals-- FreeBSD doesn't work with my
old Hitachi IDE CDROM, so i can't tell if I've broken anything. :)

i'd especially like to hear how the drive copes in DMA operation on
drives with bad sectors.  i haven't been able to find any such yet.

success/failure reports on older IDE drives with early support for DMA
modes-- those introduced between 1.5 and 3 years ago, typically
ranging from perhaps 400MB to 1.6GB.

failure reports on operation with more than one drive would be
appreciated.  the driver was developed with two drives on one
controller, the worst-case situation, and has been tested with one
drive on each controller, but you never know...

any reports of messages from the driver during normal operation,
especially "reverting to PIO mode", or "dmaverify odd vaddr or length"
(the DMA controller is strongly halfword oriented, and i'm curious to
know if any FreeBSD usage actually needs misaligned transfers).

performance reports.  beware that bonnie's CPU usage reporting is
useless for IDE drives; the best test i've found has been to run a
program that runs a spin loop at an idle priority and reports how many
iterations it manages, and even that sometimes produces numbers i
don't believe.  performance reports of multi-drive operation are
especially interesting; my system cannot sustain full throughput on
two drives on separate controllers, but that may just be a lame
motherboard.

THINGS I'M STILL MISSING CLUE ON:

* who's responsible for configuring DMA timing modes on IDE drives?
the BIOS or the driver?

* is there a spec for dealing with Ultra-DMA extensions?

* are there any chipsets or with bugs relating to DMA transfer that
should be blacklisted?

* are there any ATA interfaces that use some other kind of DMA
controller in conjunction with standard ATA protocol?

FINAL NOTE:

after having looked at the ATA-3 spec, all i can say is, "it's ugly".
*especially* electrically.  the IDE bus is best modeled as an
unterminated transmission line, these days.

for maximum reliability, keep your IDE cables as short as possible and
as few as possible.  from what i can tell, most current chipsets have
both IDE ports wired into a single buss, to a greater or lesser
degree.  using two cables means you double the length of this bus.

SCSI may have its warts, but at least the basic analog design of the
bus is still somewhat reasonable.  IDE passed beyond the veil two
years ago.

  --John Hood, cgull@smoke.marlboro.vt.us
1997-07-29 12:57:25 +00:00
..
bs Include <sys/conf.h> 1997-06-03 08:23:26 +00:00
ic Was superseded by ns16550.h 4-5 years ago. 1997-06-02 03:10:10 +00:00
matcd Removed unused #includes. 1997-07-20 11:14:53 +00:00
pcvt Finished (?) converting md_regs to a `struct trapframe *'. Some bogus casts 1997-07-20 12:33:19 +00:00
sound Removed unused #includes. 1997-07-20 11:58:40 +00:00
adv_isa.c Back out part 1 of the MCFH that changed $Id$ to $FreeBSD$. We are not 1997-02-22 09:48:43 +00:00
aha1542.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
aic6360.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
aic_98.h More merge and update. 1996-10-30 22:41:46 +00:00
apic_ipl.h Fixed missing indent protection in copyright. 1997-07-20 12:18:53 +00:00
apic_ipl.s Removed the simplelock functions. 1997-07-24 23:49:44 +00:00
apic_vector.s Modified the PEND_INTS algorithm to fix the ISA INT loss problem. 1997-07-28 03:59:54 +00:00
asc.c YAMF22 1997-04-14 16:47:38 +00:00
ascreg.h Back out part 1 of the MCFH that changed $Id$ to $FreeBSD$. We are not 1997-02-22 09:48:43 +00:00
atapi.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
atapi.h More merge and update. 1996-10-30 22:41:46 +00:00
atpic_vector.s Removed the defunct GET_MPLOCK/REL_MPLOCK macros. 1997-07-24 03:24:57 +00:00
b004.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
b004.h Cleaned up all headers that include <sys/ioctl.h> or <sys/ioccom.h>: 1996-09-21 14:59:43 +00:00
bt5xx-445.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
clock.c clock.c: 1997-07-26 01:53:04 +00:00
cronyx.c Moved some definitions of initialized data nearer to the start of 1997-07-20 10:07:55 +00:00
ctx.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
ctxreg.h Back out part 1 of the MCFH that changed $Id$ to $FreeBSD$. We are not 1997-02-22 09:48:43 +00:00
cx.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
cxreg.h Fix a bunch of spelling errors in the comment fields of 1996-01-30 23:02:38 +00:00
cy.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
cyreg.h Back out part 1 of the MCFH that changed $Id$ to $FreeBSD$. We are not 1997-02-22 09:48:43 +00:00
diskslice_machdep.c Avoid division by 0 in check_part(). (It occurred when max_nsectors == 0. 1997-04-19 14:14:17 +00:00
elink.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
elink.h Back out part 1 of the MCFH that changed $Id$ to $FreeBSD$. We are not 1997-02-22 09:48:43 +00:00
fd.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
fdc.h Back out part 1 of the MCFH that changed $Id$ to $FreeBSD$. We are not 1997-02-22 09:48:43 +00:00
fdreg.h Back out part 1 of the MCFH that changed $Id$ to $FreeBSD$. We are not 1997-02-22 09:48:43 +00:00
ft.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
ftreg.h Moved the ft.c from 1.1.5.1 over. It works on my Conner thingie. Got 1994-09-25 06:04:25 +00:00
gpib.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
gpib.h Cleaned up all headers that include <sys/ioctl.h> or <sys/ioccom.h>: 1996-09-21 14:59:43 +00:00
gpibreg.h Fixed pessimized (short) i/o port types. 1996-10-08 21:08:18 +00:00
gsc.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
gscreg.h Remove trailing whitespace. 1995-05-30 08:16:23 +00:00
icu_ipl.h Uniformized idempotency ifdef. 1997-07-20 12:26:34 +00:00
icu_ipl.s Split vector.s into UP and SMP specific files: 1997-05-26 17:58:27 +00:00
icu_vector.s Removed the defunct GET_MPLOCK/REL_MPLOCK macros. 1997-07-24 03:24:57 +00:00
icu.h Last commit didn't take, operator error??? 1997-07-22 20:12:32 +00:00
if_ar.c Major overhaul of the SyncPPP layer. Basically, this comprises now a 1997-05-19 22:03:09 +00:00
if_arregs.h Back out part 1 of the MCFH that changed $Id$ to $FreeBSD$. We are not 1997-02-22 09:48:43 +00:00
if_cx.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
if_ed.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
if_edreg.h Back out part 1 of the MCFH that changed $Id$ to $FreeBSD$. We are not 1997-02-22 09:48:43 +00:00
if_eg.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
if_egreg.h Update driver. 1996-08-04 10:58:17 +00:00
if_el.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
if_elreg.h Back out part 1 of the MCFH that changed $Id$ to $FreeBSD$. We are not 1997-02-22 09:48:43 +00:00
if_ep.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
if_epreg.h Back out part 1 of the MCFH that changed $Id$ to $FreeBSD$. We are not 1997-02-22 09:48:43 +00:00
if_ex.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
if_exreg.h Add the ex driver (Intel EtherExpress Pro/10). 1997-01-16 12:19:21 +00:00
if_fe.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
if_fereg.h Back out part 1 of the MCFH that changed $Id$ to $FreeBSD$. We are not 1997-02-22 09:48:43 +00:00
if_ie507.h Back out part 1 of the MCFH that changed $Id$ to $FreeBSD$. We are not 1997-02-22 09:48:43 +00:00
if_ie.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
if_iee16.h New name for the EtherExpress register file. 1997-04-14 00:40:04 +00:00
if_iereg.h Back out part 1 of the MCFH that changed $Id$ to $FreeBSD$. We are not 1997-02-22 09:48:43 +00:00
if_le.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
if_lnc.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
if_lnc.h Updated #includes to 4.4Lite style. 1996-09-10 08:32:01 +00:00
if_sr.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
if_srregs.h Back out part 1 of the MCFH that changed $Id$ to $FreeBSD$. We are not 1997-02-22 09:48:43 +00:00
if_wl.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
if_wl.h Add 'wl' Wavelan driver. 1997-05-22 08:50:14 +00:00
if_ze.c Omit printout of imen, INTRGET() is not MP-safe yet... 1997-07-20 23:07:39 +00:00
if_zp.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
if_zpreg.h Back out part 1 of the MCFH that changed $Id$ to $FreeBSD$. We are not 1997-02-22 09:48:43 +00:00
intr_machdep.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
intr_machdep.h SMP or APIC_IO: 1997-07-19 02:28:30 +00:00
ipl_funcs.c Bruce's original implementation of the splxxx() routines, but as C code 1997-05-31 08:57:05 +00:00
ipl.s New simple_lock code in asm: 1997-07-23 20:47:19 +00:00
isa_device.h Fix a difference between the declaration & definition of isa_dmastatus(). 1997-07-24 18:05:22 +00:00
isa.c Return to using disable/enable_intr() for guarding DMA register access. 1997-07-29 05:24:36 +00:00
isa.h Back out part 1 of the MCFH that changed $Id$ to $FreeBSD$. We are not 1997-02-22 09:48:43 +00:00
istallion.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
joy.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
kbdio.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
kbdio.h Back out part 1 of the MCFH that changed $Id$ to $FreeBSD$. We are not 1997-02-22 09:48:43 +00:00
kbdtables.h Back out part 1 of the MCFH that changed $Id$ to $FreeBSD$. We are not 1997-02-22 09:48:43 +00:00
labpc.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
lpt.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
lptreg.h Back out part 1 of the MCFH that changed $Id$ to $FreeBSD$. We are not 1997-02-22 09:48:43 +00:00
mcd.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
mcdreg.h Back out part 1 of the MCFH that changed $Id$ to $FreeBSD$. We are not 1997-02-22 09:48:43 +00:00
mse.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
ncr5380.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
nmi.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
npx.c Made the SMP case ignore the possibility of an INT13 interface. 1997-07-21 07:57:50 +00:00
pcaudio.c Back out part 1 of the MCFH that changed $Id$ to $FreeBSD$. We are not 1997-02-22 09:48:43 +00:00
pcibus.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
pcibus.h Completely replace the PCI bus driver code to make it better reflect 1997-05-26 15:08:43 +00:00
pcic.h Updated #includes to 4.4Lite style. 1996-09-10 08:32:01 +00:00
pcicx.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
prof_machdep.c Back out part 1 of the MCFH that changed $Id$ to $FreeBSD$. We are not 1997-02-22 09:48:43 +00:00
psm.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
qcam.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
qcamdefs.h Remove devconf, it never grew up to be of any use. 1996-09-06 23:09:20 +00:00
qcamio.c Updated #includes to 4.4Lite style. 1996-09-10 08:32:01 +00:00
qcamreg.h Update to version 1.1beta5d of the driver. This driver now runs under 1996-05-04 07:03:55 +00:00
random_machdep.c don't #ifdef out reference to i586_ctr_freq. 1997-05-04 14:28:22 +00:00
rc.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
rcreg.h Allow any speed from 0..76800 1995-08-02 10:17:35 +00:00
README.le Back out part 1 of the MCFH that changed $Id$ to $FreeBSD$. We are not 1997-02-22 09:48:43 +00:00
README.stl Some trivial updates to the information in here, A good deal of this 1996-05-04 08:51:42 +00:00
rtc.h Back out part 1 of the MCFH that changed $Id$ to $FreeBSD$. We are not 1997-02-22 09:48:43 +00:00
scd.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
scdreg.h Back out part 1 of the MCFH that changed $Id$ to $FreeBSD$. We are not 1997-02-22 09:48:43 +00:00
seagate.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
si_code.c Back out part 1 of the MCFH that changed $Id$ to $FreeBSD$. We are not 1997-02-22 09:48:43 +00:00
si.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
sio.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
sioreg.h Bring back CONSPEED as a last-ditch default if you can't change the speed 1997-06-04 16:25:15 +00:00
sireg.h Back out part 1 of the MCFH that changed $Id$ to $FreeBSD$. We are not 1997-02-22 09:48:43 +00:00
spigot.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
spkr.c Back out part 1 of the MCFH that changed $Id$ to $FreeBSD$. We are not 1997-02-22 09:48:43 +00:00
stallion.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
syscons.c Fix a brino in my last commit. 1997-07-26 07:58:29 +00:00
syscons.h Screen saver related fixes. 1997-07-15 14:43:27 +00:00
timerreg.h Back out part 1 of the MCFH that changed $Id$ to $FreeBSD$. We are not 1997-02-22 09:48:43 +00:00
tw.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
ultra14f.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
vector.s Split vector.s into UP and SMP specific files: 1997-05-26 17:58:27 +00:00
wcd.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
wd7000.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
wd.c Add support for busmaster DMA on some PCI IDE chipsets. 1997-07-29 12:57:25 +00:00
wdc_p.h Add support for the buggy CMD640B PCI EIDE controller chip, which 1997-03-11 23:17:28 +00:00
wdreg.h Add support for busmaster DMA on some PCI IDE chipsets. 1997-07-29 12:57:25 +00:00
wt.c Removed unused #includes. 1997-07-20 14:10:18 +00:00
wtreg.h Back out part 1 of the MCFH that changed $Id$ to $FreeBSD$. We are not 1997-02-22 09:48:43 +00:00

Stallion Multiport Serial Driver Readme
---------------------------------------

Version: 0.0.5 alpha
Date:    20MAR96
Author:  Greg Ungerer (gerg@stallion.oz.au)



1. INTRODUCTION

This is a FreeBSD driver for some of the Stallion Technologies range of
multiport serial boards. This driver is still very new, so it should be
considered to be of very alpha quality.

This driver has not been developed by Stallion Technologies. I developed it
in my spare time in the hope that it would be useful. As such there is no
warranty or support of any form. What this means is that this driver is not
officially supported by Stallion Technologies, so don't ring their support
if you can't get it working. They will probably not be able to help you.
Instead email me if you have problems or bug reports and I will do what I
can... (Sorry to sound so heavy handed, but I need to stress that this driver
is not officially supported in any way.)

This package actually contains two drivers. One is for the true Stallion
intelligent multiport boards, and the other is for the smart range of boards.

All host driver source is included in this package, and is copyrighted under
a BSD style copyright. The board "firmware" code in this package is copyright
Stallion Technologies (the files cdk.sys and 2681.sys).


1.1 SMART MULTIPORT BOARD DRIVER

This driver supports the EasyIO and EasyConnection 8/32 range of boards.
These boards are not classic intelligent multiport boards, but are host
based multiport boards that use high performance Cirrus Logic CL-CD1400 RISC
UART's (they have built in FIFO's, automatic flow control and some other
good stuff).

The EasyIO range of cards comes in 3 forms, the EasyIO-4, EasyIO-8 and the
EasyIO-8M. All of these are non-expandable, low cost, ISA, multiport boards
with 4, 8 and 8 RS-232C ports respectively. Each EasyIO board requires 8
bytes of I/O address space and 1 interrupt. On an EISA system it is possible
to share 1 interrupt between multiple boards. The EasyIO-4 has 10 pin RJ
connectors, and the EasyIO-8 comes with a dongle cable with either 10 pin RJ
connectors or DB-25 connectors. The EasyIO-8M has 6 pin RJ connectors.

The EasyConnection 8/32 family of boards is a relatively low cost modular
range of multiport serial boards. The EasyConnection 8/32 boards can be
configured to have from 8 to 32 serial ports by plugging in external serial
port modules that contain either 8 or 16 ports each. There is a wide range
of external modules available that offer: DB-25 connectors, RJ-45 connectors
(both with RS-232 D and E compatible drivers), and also RS-422 and RS-485
ports. The EasyConnection 8/32 boards come in ISA, PCI and MCA bus versions.
The board takes the form of a host adapter card, with an external connector
cable that plugs into the external modules. The external modules just clip
together to add ports (BTW, they are NOT hot pluggable). Each ISA
EasyConnection 8/32 board requires two separate I/O address ranges, one two
bytes in size and a secondary region of 32 bytes. Each PCI EasyConnection
8/32 requires two regions of I/O address space, normally these will be
automatically allocated by the system BIOS at system power on time. Each MCA
EasyConnection board requires one I/O address region 64 bytes in size. All
board types also require one interrupt. On EISA systems multiple boards can
share one interrupt. The secondary I/O range of the ISA board (the 32 byte
range) can be shared between multiple boards on any bus type.


1.2 INTELLIGENT MULTIPORT BOARD DRIVER

This driver is for Stallion's range of true intelligent multiport boards.
It supports the EasyConnection 8/64, ONboard, Brumby and original Stallion
families of multiport boards. The EasyConnection 8/64 and ONboard boards come
in ISA, EISA and Microchannel bus versions. The Brumby and Stallion boards
are only available in ISA versions.

The EasyConnection 8/64 family of boards is a medium cost, high performance,
modular range of intelligent multiport serial boards. The EasyConnection 8/64
boards can be configured to have from 8 to 64 serial ports by plugging in
external serial port modules that contain either 8 or 16 ports each (these
modules are the same used by the EasyConnection 8/32 board). There is a wide
range of external modules available that offer: DB-25 connectors, RJ-45
connectors (both with RS-232 D and E compatible drivers), and also RS-422 and
RS-485 ports. The board takes the form of a host adapter card, with an external
connector cable that plugs into the external modules. The external modules
just clip together to add ports (BTW, they are NOT hot pluggable). Each
EasyConnection 8/64 board requires 4 bytes of I/O address space and a region
of memory space. The size of the memory region required depends on the exact
board type. The EISA version requires 64 Kbytes of address space (that can
reside anywhere in the 4 Gigabyte physical address space). The ISA and MCA
boards require 4 Kbytes of address space (which must reside in the lower
1 Mbyte of physical address space - typically in the c8000 to e0000 range).
No interrupts are required. The physical memory region of multiple
EasyConnection 8/64 boards can be shared, but each board must have a separate
I/O address space.

The ONboard family of boards are traditional intelligent multiport serial
boards. They are Stallion's older range of boards with a limited expansion
capability. They come in 4, 8, 12, 16 and 32 port versions. The board uses
the same base card (which has 4 ports on it) and is expanded to more ports
via a mezzanine board that attaches directly onto the board. External panels
plug into the ONboard providing RS-232C ports with DB-25 plugs. An RS-422
DB-25 dual interface panel is also available. The ISA and microchannel
ONboards require 16 bytes of I/O address space and 64K bytes of memory
space. The memory space can be anywhere in the 16 Mbyte ISA bus address
range. No interrupt is required. The EISA ONboard requires 64 Kbytes of
memory space that can be anywhere in the 4 Gigabyte physical address space.
All ONboard boards can share their memory region with other ONboards (or
EasyConnection 8/64 boards).

The Brumby family of boards are traditional, low cost intelligent multiport
serial boards. They are non-expandable and come in 4, 8 and 16 port versions.
They are only available for the ISA bus. The serial ports are all on DB-25
"dongle" cables that attach to the rear of the board. Each Brumby board
requires 16 bytes of I/O address space and 16 Kbytes of memory space. No
interrupts are required.

The original Stallion boards are old. They went out of production some years
back. They offer limited expandability and are available in 8 or 16 port
configurations. An external panel houses 16 RS-232C ports with DB-9
connectors. They require 16 bytes of I/O address space, and either 64K or
128K of memory space. No interrupt is required. I will not actively support
these boards, although they will work with the driver.

That's the boards supported by the second driver. The ONboard, Brumby and
Stallion boards are Stallion's older range of intelligent multiports - so
there are lots of them around. They only support a maximum baud rate of
38400. The EasyConnection 8/64 is a true high performance intelligent
multiport board, having much greater throughput than any of Stallion's
older boards. It also supports speeds up to 115200 baud.


1.3 HOW TO GET BOARDS

Stallion Technologies has offices all over the world, as well as many more
distributors and resellers. To find out about local availability please
contact the nearest Stallion office and they can give you all the information
you need.

	Stallion Technologies Sales and Support Offices
	===============================================

	Stallion Technologies Pty. Ltd.
	P.O. Box 954
	Toowong, QLD 4066, Australia
	Tel. +61 7 3270 4242
	Fax. +61 7 3270 4245
	Email: support@stallion.oz.au

	Stallion Technologies Inc.
	2880 Research Park Drive,
	Soquel,  CA 95073,  USA.
	Tel. +1 408 477 0440
	Fax. +1 408 477 0444
	Email: support@staltec.com

	Stallion Technologies Deutschland GmbH.
	Martin-Behaim-Strasse 12
	63263 Neu-Isenburg
	Germany
	Tel. +49 6102 73970
	Fax. +49 6102 739710

Another good source of information about the Stallion range of boards and
local availability is on the Stallion Web page. Check it out at
http://www.stallion.com.



2. INSTALLATION

This driver, as is, will work on a FreeBSD 2.1 system. It will run on
a 2.0.5 system, or -current version systems by changing a define in the
driver source.

You will need to build a new kernel to use this driver. So the first thing
you need is to have the full kernel source. Most people will have this
(I hope!). The following assumes that the kernel source is in /usr/src/sys.

The drivers can support up to 8 boards. For the smart board driver any
combination of EasyIO and EasyConnection 8/32 boards can be installed. For
the intelligent any combination of EasyConnection 8/64, ONboard, Brumby or
original Stallion. So there is a theoretical maximum of 512 ports.
(Off-course I have not tested a system with this many!)


[[[ The install instructions are obsolete, it is now standard ]]]
[[[ Skip forward to item 4, editing your kernel config file   ]]]

2.1 Instructions to install:

1. Copy the driver source files into the kernel source tree.

        cp stallion.c istallion.c cdk.h comstats.h /usr/src/sys/i386/isa
        cp scd1400.h /usr/src/sys/i386/isa/ic

   Note: if you are NOT using FreeBSD 2.1.0 then you will need to edit the
   stallion.c and istallion.c files and change the VFREEBSD define to match
   your version.

2. Skip to next step if on a FreeBSD kernel later than 2.1.0.
   Add a character device switch table entry for the driver that you which
   to use into the cdevsw table structure. This involves adding some code
   into the kernel conf.c file. 

   If you are using an EasyIO or EasyConnection 8/32 then you need to use
   the stallion.c driver. All other board types (EasyConnection 8/64,
   ONboard, Brumby, Stallion) use the istallion.c driver. You can also have
   a mix of boards using both drivers. You will need to use a different
   major device number for the second driver though (not the default 72 -
   see below for more details on this).

2.1. If using the stallion.c driver then do:

        cd /usr/src/sys/i386/i386
        vi conf.c
            - add the following lines (in 2.1 I put them at line 729):

/* Stallion Multiport Serial Driver */
#include "stl.h"
#if	NSTL > 0
d_open_t        stlopen;
d_close_t       stlclose;
d_read_t        stlread;
d_write_t       stlwrite;
d_ioctl_t	stlioctl;
d_stop_t        stlstop;
d_ttycv_t	stldevtotty;
#define stlreset	nxreset
#define	stlmmap		nxmmap
#define stlstrategy	nxstrategy
#else
#define	stlopen		nxopen
#define stlclose	nxclose
#define stlread		nxread
#define stlwrite	nxwrite
#define stlioctl	nxioctl
#define stlstop		nxstop
#define stlreset	nxreset
#define stlmmap		nxmmap
#define stlstrategy	nxstrategy
#define	stldevtotty	nxdevtotty
#endif


            - and then inside the actual cdevsw structure definition, at the
              last entry add (this is now line 1384 in the 2.1 conf.c):

	{ stlopen,	stlclose,	stlread,	stlwrite,	/*72*/
	  stlioctl,	stlstop,	stlreset,	stldevtotty,/*stallion*/
	  ttselect,	stlmmap,	stlstrategy },

            - the line above used major number 72, but this may be different
              on your system. Take note of what major number you are using.
              
            - save the file and exit vi.


2.2. If using the istallion.c driver then do:

        cd /usr/src/sys/i386/i386
        vi conf.c
            - add the following lines (in 2.1 I put them at line 729):

/* Stallion Intelligent Multiport Serial Driver */
#include "stl.h"
#if	NSTL > 0
d_open_t        stliopen;
d_close_t       stliclose;
d_read_t        stliread;
d_write_t       stliwrite;
d_ioctl_t	stliioctl;
d_stop_t        stlistop;
d_ttycv_t	stlidevtotty;
#define stlireset	nxreset
#define	stlimmap	nxmmap
#define stlistrategy	nxstrategy
#else
#define	stliopen	nxopen
#define stliclose	nxclose
#define stliread	nxread
#define stliwrite	nxwrite
#define stliioctl	nxioctl
#define stlistop	nxstop
#define stlireset	nxreset
#define stlimmap	nxmmap
#define stlistrategy	nxstrategy
#define	stlidevtotty	nxdevtotty
#endif


            - and then inside the actual cdevsw structure definition, at the
              last entry add (this is now line 1384 in the 2.1 conf.c):

	{ stliopen,	stliclose,	stliread,     stliwrite,	/*72*/
	  stliioctl,	stlistop,	stlireset,    stlidevtotty,/*istallion*/
	  ttselect,	stlimmap,	stlistrategy },

            - the line above used major number 72, but this may be different
              on your system. Take note of what major number you are using.
              
            - save the file and exit vi.

3. Add the driver source files to the kernel files list:

        cd /usr/src/sys/i386/conf
        vi files.i386
            - add the following definition lines into the list (it is stored
              alphabetically, so insert them appropriately):

i386/isa/istallion.c		optional	stli	device-driver

i386/isa/stallion.c		optional	stl	device-driver

            - save the file and exit vi.

4. Add board probe entries into the kernel configuration file:

        cd /usr/src/sys/i386/conf
        cp GENERIC MYKERNEL
            - if you already have a kernel config that you use then you
              could just use that (instead of MYKERNEL)
        vi MYKERNEL
            - if only using ECH-PCI boards then you don't need to enter a
              configuration line, the kernel will automatically detect
              the board at boot up, so skip to step 5.
            - enter a line for each board that you want to use. For stallion.c
              boards entries should look like:

device		stl0	at isa? port 0x2a0 tty irq 10 vector stlintr

              For istallion.c boards, the entries should look like:

device		stli0	at isa? port 0x2a0 tty iomem 0xcc000 iosiz 0x1000 flags 23

              (I suggest you put them after the sio? entries)
              (Don't enter lines for ECH-PCI boards)
            - change the entry resources as required. For the Stallion.c
              entries this may involve changing the port address or irq.
              For the istallion.c entries this may involve changing the port
              address, iomem address, iosiz value and the flags. Select from
              the following table for appropriate flags and iosiz values for
              your board type:

              EasyConnection 8/64 ISA:     flags 23         iosiz 0x1000
              EasyConnection 8/64 EISA:    flags 24         iosiz 0x10000
              EasyConnection 8/64 MCA:     flags 25         iosiz 0x1000
              ONboard ISA:                 flags 4          iosiz 0x10000
              ONboard EISA:                flags 7          iosiz 0x10000
              ONboard MCA:                 flags 3          iosiz 0x10000
              Brumby:                      flags 2          iosiz 0x4000
              Stallion:                    flags 1          iosiz 0x10000

            - save the file and exit

5. Build a new kernel using this configuration.

        cd /usr/src/sys/i386/conf
        config MYKERNEL
        cd ../../compile/MYKERNEL
        make depend
        make all
        make install


And there you have it!  It is a little bit of effort to get it in there...

Once you have a new kernel built reboot to start it up. On startup the
Stallion board probes will report on whether the boards were found or not.
For each board found the driver will print out the type of board found,
and how many panels and ports it has. 

If a board is not found by the driver but is actually in the system then the
most likely problem is that the IO address is incorrect. The easiest thing to
do is change the DIP switches on the board to the desired address and reboot.

On EasyIO and EasyConnection 8/32 boards the IRQ is software programmable,
so if there is a conflict you may need to change the IRQ used for a board in
the MYKERNEL configuration file and rebuild the kernel.

Note that the secondary IO address of the EasyConnection 8/32 boards is hard
coded into the stallion.c driver code. It is currently set to IO address
0x280. If you need to use a different address then you will need to edit this
file and change the variable named stl_ioshared.

On intelligent boards it is possible that the board shared memory region is
clashing with that of some other device. Check for this and change the device
or kernel configuration as required.


2.2 INTELLIGENT DRIVER OPERATION

The intelligent boards also need to have their "firmware" code downloaded
to them. This is done via a user level application supplied in the driver
package called "stlload". Compile this program where ever you dropped the
package files, by typing "make". In its simplest form you can then type
    ./stlload -i cdk.sys
in this directory and that will download board 0 (assuming board 0 is an
EasyConnection 8/64 board). To download to an ONboard, Brumby or Stallion do:
    ./stlload -i 2681.sys

Normally you would want all boards to be downloaded as part of the standard
system startup. To achieve this, add one of the lines above into the
/etc/rc.serial file. To download each board just add the "-b <brd-number>"
option to the line. You will need to download code for every board. You should
probably move the stlload program into a system directory, such as /usr/sbin.
Also, the default location of the cdk.sys image file in the stlload
down-loader is /usr/lib/stallion. Create that directory and put the cdk.sys
and 2681.sys files in it. (It's a convenient place to put them anyway). As an
example your /etc/rc.serial file might have the following lines added to it
(if you had 3 boards):
    /usr/sbin/stlload -b 0 -i /usr/lib/stallion/cdk.sys
    /usr/sbin/stlload -b 1 -i /usr/lib/stallion/2681.sys
    /usr/sbin/stlload -b 2 -i /usr/lib/stallion/2681.sys

The image files cdk.sys and 2681.sys are specific to the board types. The
cdk.sys will only function correctly on an EasyConnection 8/64 board. Similarly
the 2681.sys image will only operate on ONboard, Brumby and Stallion boards.
If you load the wrong image file into a board it will fail to start up, and
of course the ports will not be operational!



3. USING THE DRIVER

Once the driver is installed you will need to setup some device nodes to
access the serial ports. Use the supplied "mkdevnods" script to automatically
create all required device entries for your boards. To make device nodes for
more than 1 board then just supply the number of boards you are using as a
command line parameter to mkdevnods and it will create nodes for that number
of boards. By default it will create device nodes for 1 board only.

Note that if the driver is not installed at character major number 72 then
you will need to edit the mkdevnods script and modify the STL_SERIALMAJOR
variable to the major number you are using.

Device nodes created for the normal serial port devices are named /dev/ttyEX
where X is the port number. (The second boards ports will start from ttyE64,
the third boards from ttyE128, etc). It will also create a set of modem call
out devices named cueX where again X is the port number.

For the most part the Stallion driver tries to emulate the standard PC system
com ports and the standard sio serial driver. The idea is that you should
be able to use Stallion board ports and com ports inter-changeably without
modifying anything but the device name. Anything that doesn't work like that
should be considered a bug in this driver!

Since this driver tries to emulate the standard serial ports as much as
possible then most system utilities should work as they do for the standard
com ports. Most importantly "stty" works as expected and "comcontrol" can be
used just like for the serial ports.

This driver should work with anything that works on standard com serial ports.
Having said that, I have used it on at least the following types of "things"
under FreeBSD:
    a) standard dumb terminals (using getty)
    b) modems (using cu, etc)
    c) ppp (through pppd, kernel ppp)



4. NOTES

Be aware that these drivers are still very new, so there is sure to be some
bugs in them. Please email me any feedback on bugs, problems, or even good
experiences with these drivers!

You can use both drivers at once if you have a mix of board types installed
in a system. However to do this you will need to change the major number used
by one of the drivers. Currently both drivers use default major number 72 for
their devices. Change one driver to use some other major number (how this is
achieved will depend on the kernel version you are using), and then modify the
mkdevnods script to make device nodes based on those new major numbers. For
example, you could change the stallion.c driver to use major number 73. You
will also need to create device nodes with different names for the ports, for
eg ttyFXXX.

Currently the intelligent board driver (istallion.c) does not have the
ability to share a boards memory region with other boards (you can only do
this on EasyConnection 8/64 and ONboards normally anyway). It also does
not currently support any memory address ranges above the low 1Mb region.
These will be fixed in a future release of the driver.

Finding a free physical memory address range can be a problem. The older
boards like the Stallion and ONboard need large areas (64K or even 128K), so
they can be very difficult to get into a system. If you have 16 Mb of RAM
then you have no choice but to put them somewhere in the 640K -> 1Mb range.
ONboards require 64K, so typically 0xd0000 is good, or 0xe0000 on some
systems. If you have an original Stallion board, "V4.0" or Rev.O, then you
need a 64K memory address space, so again 0xd0000 and 0xe0000 are good. Older
Stallion boards are a much bigger problem. They need 128K of address space and
must be on a 128K boundary. If you don't have a VGA card then 0xc0000 might be
usable - there is really no other place you can put them below 1Mb.

Both the ONboard and old Stallion boards can use higher memory addresses as
well, but you must have less than 16Mb of RAM to be able to use them. Usual
high memory addresses used include 0xec0000 and 0xf00000.

The Brumby boards only require 16Kb of address space, so you can usually
squeeze them in somewhere. Common addresses are 0xc8000, 0xcc000, or in
the 0xd0000 range. EasyConnection 8/64 boards are even better, they only
require 4Kb of address space, again usually 0xc8000, 0xcc000 or 0xd0000
are good.

If you are using an EasyConnection 8/64-EI or ONboard/E then usually the
0xd0000 or 0xe0000 ranges are the best options below 1Mb. If neither of
them can be used then the high memory support to use the really high address
ranges is the best option. Typically the 2Gb range is convenient for them,
and gets them well out of the way.

The ports of the EasyIO-8M board do not have DCD or DTR signals. So these
ports cannot be used as real modem devices. Generally when using these
ports you should only use the cueX devices.

There is a new utility in this package that reports statistics on the
serial ports. You will need to have the ncurses library installed on your
system to build it.

To build the statistics display program type:
    make stlstats
Once compiled simply run it (you will need to be root) and it will display
a port summary for the first board and panel installed. Use the digits to
select different board numbers, or 'n' to cycle through the panels on a
board. To look at detailed port information then hit 'p', that will display
detailed port 0 information. Use the digits and letters 'a' through 'f' to
select the different ports (on this board and panel).



5. ACKNOWLEDGEMENTS

This driver is loosely based on the code of the FreeBSD sio serial driver.
A big thanks to Stallion Technologies for the use of their equipment.