| specialix.txt -- specialix IO8+ multiport serial driver readme. | |
| Copyright (C) 1997 Roger Wolff (R.E.Wolff@BitWizard.nl) | |
| Specialix pays for the development and support of this driver. | |
| Please DO contact io8-linux@specialix.co.uk if you require | |
| support. | |
| This driver was developed in the BitWizard linux device | |
| driver service. If you require a linux device driver for your | |
| product, please contact devices@BitWizard.nl for a quote. | |
| This code is firmly based on the riscom/8 serial driver, | |
| written by Dmitry Gorodchanin. The specialix IO8+ card | |
| programming information was obtained from the CL-CD1865 Data | |
| Book, and Specialix document number 6200059: IO8+ Hardware | |
| Functional Specification, augmented by document number 6200088: | |
| Merak Hardware Functional Specification. (IO8+/PCI is also | |
| called Merak) | |
| This program is free software; you can redistribute it and/or | |
| modify it under the terms of the GNU General Public License as | |
| published by the Free Software Foundation; either version 2 of | |
| the License, or (at your option) any later version. | |
| This program is distributed in the hope that it will be | |
| useful, but WITHOUT ANY WARRANTY; without even the implied | |
| warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR | |
| PURPOSE. See the GNU General Public License for more details. | |
| You should have received a copy of the GNU General Public | |
| License along with this program; if not, write to the Free | |
| Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, | |
| USA. | |
| Intro | |
| ===== | |
| This file contains some random information, that I like to have online | |
| instead of in a manual that can get lost. Ever misplace your Linux | |
| kernel sources? And the manual of one of the boards in your computer? | |
| Addresses and interrupts | |
| ======================== | |
| Address dip switch settings: | |
| The dip switch sets bits 2-9 of the IO address. | |
| 9 8 7 6 5 4 3 2 | |
| +-----------------+ | |
| 0 | X X X X X X X | | |
| | | = IoBase = 0x100 | |
| 1 | X | | |
| +-----------------+ ------ RS232 connectors ----> | |
| | | | | |
| edge connector | |
| | | | | |
| V V V | |
| Base address 0x100 caused a conflict in one of my computers once. I | |
| haven't the foggiest why. My Specialix card is now at 0x180. My | |
| other computer runs just fine with the Specialix card at 0x100.... | |
| The card occupies 4 addresses, but actually only two are really used. | |
| The PCI version doesn't have any dip switches. The BIOS assigns | |
| an IO address. | |
| The driver now still autoprobes at 0x100, 0x180, 0x250 and 0x260. If | |
| that causes trouble for you, please report that. I'll remove | |
| autoprobing then. | |
| The driver will tell the card what IRQ to use, so you don't have to | |
| change any jumpers to change the IRQ. Just use a command line | |
| argument (irq=xx) to the insmod program to set the interrupt. | |
| The BIOS assigns the IRQ on the PCI version. You have no say in what | |
| IRQ to use in that case. | |
| If your specialix cards are not at the default locations, you can use | |
| the kernel command line argument "specialix=io0,irq0,io1,irq1...". | |
| Here "io0" is the io address for the first card, and "irq0" is the | |
| irq line that the first card should use. And so on. | |
| Examples. | |
| You use the driver as a module and have three cards at 0x100, 0x250 | |
| and 0x180. And some way or another you want them detected in that | |
| order. Moreover irq 12 is taken (e.g. by your PS/2 mouse). | |
| insmod specialix.o iobase=0x100,0x250,0x180 irq=9,11,15 | |
| The same three cards, but now in the kernel would require you to | |
| add | |
| specialix=0x100,9,0x250,11,0x180,15 | |
| to the command line. This would become | |
| append="specialix=0x100,9,0x250,11,0x180,15" | |
| in your /etc/lilo.conf file if you use lilo. | |
| The Specialix driver is slightly odd: It allows you to have the second | |
| or third card detected without having a first card. This has | |
| advantages and disadvantages. A slot that isn't filled by an ISA card, | |
| might be filled if a PCI card is detected. Thus if you have an ISA | |
| card at 0x250 and a PCI card, you would get: | |
| sx0: specialix IO8+ Board at 0x100 not found. | |
| sx1: specialix IO8+ Board at 0x180 not found. | |
| sx2: specialix IO8+ board detected at 0x250, IRQ 12, CD1865 Rev. B. | |
| sx3: specialix IO8+ Board at 0x260 not found. | |
| sx0: specialix IO8+ board detected at 0xd800, IRQ 9, CD1865 Rev. B. | |
| This would happen if you don't give any probe hints to the driver. | |
| If you would specify: | |
| specialix=0x250,11 | |
| you'd get the following messages: | |
| sx0: specialix IO8+ board detected at 0x250, IRQ 11, CD1865 Rev. B. | |
| sx1: specialix IO8+ board detected at 0xd800, IRQ 9, CD1865 Rev. B. | |
| ISA probing is aborted after the IO address you gave is exhausted, and | |
| the PCI card is now detected as the second card. The ISA card is now | |
| also forced to IRQ11.... | |
| Baud rates | |
| ========== | |
| The rev 1.2 and below boards use a CL-CD1864. These chips can only | |
| do 64kbit. The rev 1.3 and newer boards use a CL-CD1865. These chips | |
| are officially capable of 115k2. | |
| The Specialix card uses a 25MHz crystal (in times two mode, which in | |
| fact is a divided by two mode). This is not enough to reach the rated | |
| 115k2 on all ports at the same time. With this clock rate you can only | |
| do 37% of this rate. This means that at 115k2 on all ports you are | |
| going to lose characters (The chip cannot handle that many incoming | |
| bits at this clock rate.) (Yes, you read that correctly: there is a | |
| limit to the number of -=bits=- per second that the chip can handle.) | |
| If you near the "limit" you will first start to see a graceful | |
| degradation in that the chip cannot keep the transmitter busy at all | |
| times. However with a central clock this slow, you can also get it to | |
| miss incoming characters. The driver will print a warning message when | |
| you are outside the official specs. The messages usually show up in | |
| the file /var/log/messages . | |
| The specialix card cannot reliably do 115k2. If you use it, you have | |
| to do "extensive testing" (*) to verify if it actually works. | |
| When "mgetty" communicates with my modem at 115k2 it reports: | |
| got: +++[0d]ATQ0V1H0[0d][0d][8a]O[cb][0d][8a] | |
| ^^^^ ^^^^ ^^^^ | |
| The three characters that have the "^^^" under them have suffered a | |
| bit error in the highest bit. In conclusion: I've tested it, and found | |
| that it simply DOESN'T work for me. I also suspect that this is also | |
| caused by the baud rate being just a little bit out of tune. | |
| I upgraded the crystal to 66Mhz on one of my Specialix cards. Works | |
| great! Contact me for details. (Voids warranty, requires a steady hand | |
| and more such restrictions....) | |
| (*) Cirrus logic CD1864 databook, page 40. | |
| Cables for the Specialix IO8+ | |
| ============================= | |
| The pinout of the connectors on the IO8+ is: | |
| pin short direction long name | |
| name | |
| Pin 1 DCD input Data Carrier Detect | |
| Pin 2 RXD input Receive | |
| Pin 3 DTR/RTS output Data Terminal Ready/Ready To Send | |
| Pin 4 GND - Ground | |
| Pin 5 TXD output Transmit | |
| Pin 6 CTS input Clear To Send | |
| -- 6 5 4 3 2 1 -- | |
| | | | |
| | | | |
| | | | |
| | | | |
| +----- -----+ | |
| |__________| | |
| clip | |
| Front view of an RJ12 connector. Cable moves "into" the paper. | |
| (the plug is ready to plug into your mouth this way...) | |
| NULL cable. I don't know who is going to use these except for | |
| testing purposes, but I tested the cards with this cable. (It | |
| took quite a while to figure out, so I'm not going to delete | |
| it. So there! :-) | |
| This end goes This end needs | |
| straight into the some twists in | |
| RJ12 plug. the wiring. | |
| IO8+ RJ12 IO8+ RJ12 | |
| 1 DCD white - | |
| - - 1 DCD | |
| 2 RXD black 5 TXD | |
| 3 DTR/RTS red 6 CTS | |
| 4 GND green 4 GND | |
| 5 TXD yellow 2 RXD | |
| 6 CTS blue 3 DTR/RTS | |
| Same NULL cable, but now sorted on the second column. | |
| 1 DCD white - | |
| - - 1 DCD | |
| 5 TXD yellow 2 RXD | |
| 6 CTS blue 3 DTR/RTS | |
| 4 GND green 4 GND | |
| 2 RXD black 5 TXD | |
| 3 DTR/RTS red 6 CTS | |
| This is a modem cable usable for hardware handshaking: | |
| RJ12 DB25 DB9 | |
| 1 DCD white 8 DCD 1 DCD | |
| 2 RXD black 3 RXD 2 RXD | |
| 3 DTR/RTS red 4 RTS 7 RTS | |
| 4 GND green 7 GND 5 GND | |
| 5 TXD yellow 2 TXD 3 TXD | |
| 6 CTS blue 5 CTS 8 CTS | |
| +---- 6 DSR 6 DSR | |
| +---- 20 DTR 4 DTR | |
| This is a modem cable usable for software handshaking: | |
| It allows you to reset the modem using the DTR ioctls. | |
| I (REW) have never tested this, "but xxxxxxxxxxxxx | |
| says that it works." If you test this, please | |
| tell me and I'll fill in your name on the xxx's. | |
| RJ12 DB25 DB9 | |
| 1 DCD white 8 DCD 1 DCD | |
| 2 RXD black 3 RXD 2 RXD | |
| 3 DTR/RTS red 20 DTR 4 DTR | |
| 4 GND green 7 GND 5 GND | |
| 5 TXD yellow 2 TXD 3 TXD | |
| 6 CTS blue 5 CTS 8 CTS | |
| +---- 6 DSR 6 DSR | |
| +---- 4 RTS 7 RTS | |
| I bought a 6 wire flat cable. It was colored as indicated. | |
| Check that yours is the same before you trust me on this. | |
| Hardware handshaking issues. | |
| ============================ | |
| The driver can be told to operate in two different ways. The default | |
| behaviour is specialix.sx_rtscts = 0 where the pin behaves as DTR when | |
| hardware handshaking is off. It behaves as the RTS hardware | |
| handshaking signal when hardware handshaking is selected. | |
| When you use this, you have to use the appropriate cable. The | |
| cable will either be compatible with hardware handshaking or with | |
| software handshaking. So switching on the fly is not really an | |
| option. | |
| I actually prefer to use the "specialix.sx_rtscts=1" option. | |
| This makes the DTR/RTS pin always an RTS pin, and ioctls to | |
| change DTR are always ignored. I have a cable that is configured | |
| for this. | |
| Ports and devices | |
| ================= | |
| Port 0 is the one furthest from the card-edge connector. | |
| Devices: | |
| You should make the devices as follows: | |
| bash | |
| cd /dev | |
| for i in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 \ | |
| 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 | |
| do | |
| echo -n "$i " | |
| mknod /dev/ttyW$i c 75 $i | |
| mknod /dev/cuw$i c 76 $i | |
| done | |
| echo "" | |
| If your system doesn't come with these devices preinstalled, bug your | |
| linux-vendor about this. They have had ample time to get this | |
| implemented by now. | |
| You cannot have more than 4 boards in one computer. The card only | |
| supports 4 different interrupts. If you really want this, contact me | |
| about this and I'll give you a few tips (requires soldering iron).... | |
| If you have enough PCI slots, you can probably use more than 4 PCI | |
| versions of the card though.... | |
| The PCI version of the card cannot adhere to the mechanical part of | |
| the PCI spec because the 8 serial connectors are simply too large. If | |
| it doesn't fit in your computer, bring back the card. | |
| ------------------------------------------------------------------------ | |
| Fixed bugs and restrictions: | |
| - During initialization, interrupts are blindly turned on. | |
| Having a shadow variable would cause an extra memory | |
| access on every IO instruction. | |
| - The interrupt (on the card) should be disabled when we | |
| don't allocate the Linux end of the interrupt. This allows | |
| a different driver/card to use it while all ports are not in | |
| use..... (a la standard serial port) | |
| == An extra _off variant of the sx_in and sx_out macros are | |
| now available. They don't set the interrupt enable bit. | |
| These are used during initialization. Normal operation uses | |
| the old variant which enables the interrupt line. | |
| - RTS/DTR issue needs to be implemented according to | |
| specialix' spec. | |
| I kind of like the "determinism" of the current | |
| implementation. Compile time flag? | |
| == Ok. Compile time flag! Default is how Specialix likes it. | |
| == Now a config time flag! Gets saved in your config file. Neat! | |
| - Can you set the IO address from the lilo command line? | |
| If you need this, bug me about it, I'll make it. | |
| == Hah! No bugging needed. Fixed! :-) | |
| - Cirrus logic hasn't gotten back to me yet why the CD1865 can | |
| and the CD1864 can't do 115k2. I suspect that this is | |
| because the CD1864 is not rated for 33MHz operation. | |
| Therefore the CD1864 versions of the card can't do 115k2 on | |
| all ports just like the CD1865 versions. The driver does | |
| not block 115k2 on CD1864 cards. | |
| == I called the Cirrus Logic representative here in Holland. | |
| The CD1864 databook is identical to the CD1865 databook, | |
| except for an extra warning at the end. Similar Bit errors | |
| have been observed in testing at 115k2 on both an 1865 and | |
| a 1864 chip. I see no reason why I would prohibit 115k2 on | |
| 1864 chips and not do it on 1865 chips. Actually there is | |
| reason to prohibit it on BOTH chips. I print a warning. | |
| If you use 115k2, you're on your own. | |
| - A spiky CD may send spurious HUPs. Also in CLOCAL??? | |
| -- A fix for this turned out to be counter productive. | |
| Different fix? Current behaviour is acceptable? | |
| -- Maybe the current implementation is correct. If anybody | |
| gets bitten by this, please report, and it will get fixed. | |
| -- Testing revealed that when in CLOCAL, the problem doesn't | |
| occur. As warned for in the CD1865 manual, the chip may | |
| send modem intr's on a spike. We could filter those out, | |
| but that would be a cludge anyway (You'd still risk getting | |
| a spurious HUP when two spikes occur.)..... | |
| Bugs & restrictions: | |
| - This is a difficult card to autoprobe. | |
| You have to WRITE to the address register to even | |
| read-probe a CD186x register. Disable autodetection? | |
| -- Specialix: any suggestions? | |