123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384 |
- 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?
|