|
Version: 2_cjc_2 (see the Changes log)
This software allows Linux to use the Central Data/Digi SCSI Terminal Servers (and even the rare Motorola OEM versions). The picture to the right shows (top to bottom) 4 Central Data ST-1620s, 1 Motorola STS-S8P, and 5 Motorola STS-S16Ps. Too bad I can only put 7 on a SCSI chain at a time. :) |
 |
Aug 12, 2000:
It works! Thanks to Digi's ELS driver being nothing more than a FAS
command pipe on top of all the TTY/serial code, I just ported my
userspace tool to a EL/STS pipe. :)
Sep 21, 2000:
Whoops, I forgot to release the STS unit table that Digi sent me. If
you have other STSs that are not part of my patches, you can get your
unittab settings from
this sts_unittab.c file.
Jan 19, 2001:
I've gotten around to checking in with Digi again, and it looks like they
put their latest version of the ELS drivers up, which includes my bug fix! :)
I've re-ported my changes to this new version of the driver. Their changes include much better packaging, and a lot of code clean-ups.
Next step is to port their module to Linux 2.4.x. I'll keep this web site posted.
Feb 9, 2001:
Ah! Robert gave me source code for the CenData firmware updater! Woo-hoo!
So, I've started working on a version for Linux, re-using my scsi generic
code from the STS driver. I figured I'd do a full rewrite because the
majority of the "cdupdate" code is written to use the "/dev/stsdiag" file,
which doesn't exist. That and I wanted another excuse to use "mmap".
Feb 13, 2001:
Well, here are a few things I've done:
Feb 16, 2001:
The 2.4.x port wasn't complete. Looks like 2.4 also cleaned up their TTY
code so that when cdscsid (or cdetherd) would reconnect to the ELS driver,
the "read" and "write" functions weren't set, so the "select" call never
returned for the els device. So that's been corrected. I also finished
changing the SCSI address code around so that "Host.Chan.ID.LUN" can be
used instead of /dev/sg*.
Everything appears to work again, so I've released version "2_cjc_2" now. I still need to put the FAS_GLOBAL code in, but I just didn't feel like it today. For the safest results, people should download the userspace code, run that once, and then load cdscsid. That'll make sure your STS gets at least one FAS_GLOBAL.
Jul 07, 2003:
Brian R. Swan dug through a RedHat 9.0 install to try and get things compiled
correctly, and sent me the resulting tarball. I haven't had a chance to look
through it yet, but I'll put it up here for other people to muck with if they
want it:
Jul 09, 2003:
Just got a note from Doug Rorem at the University of Illinois. They use
the STS driver to run a Digi 16 port at the IDOT office to manage all the
console ports for generating their travel congestion webpages:
older system
new w/ Tollway info
Full map
Cool!
Note from Don Elmore reads:
Kees:
It sounds like you're on the right track with the driver development, and I
hope I can give you what you need to get over the top.
The STS driver basically needs to do 3 things:
1. Communicate via the serial ports -- this is the same as with ELs.
2. Do the FAS protocol layer stuff -- this is also the same as EL.
3. Identify the SCSI units and communicate with them over SCSI -- not the
same, obviously.
I've included a link for the EtherLite Linux driver from our ftp site. If you
need more help, write again.
http://support.digi.com/support/drivers/linux/index-stsels.html