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:
Brian R. Swan's rh9 tarball
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:
new w/ Tollway info
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