Contents of /alx-src/tags/kernel26-2.6.12-alx-r9/Documentation/specialix.txt
Parent Directory | Revision Log
Revision 630 -
(show annotations)
(download)
Wed Mar 4 11:03:09 2009 UTC (15 years, 6 months ago) by niro
File MIME type: text/plain
File size: 15155 byte(s)
Wed Mar 4 11:03:09 2009 UTC (15 years, 6 months ago) by niro
File MIME type: text/plain
File size: 15155 byte(s)
Tag kernel26-2.6.12-alx-r9
1 | |
2 | specialix.txt -- specialix IO8+ multiport serial driver readme. |
3 | |
4 | |
5 | |
6 | Copyright (C) 1997 Roger Wolff (R.E.Wolff@BitWizard.nl) |
7 | |
8 | Specialix pays for the development and support of this driver. |
9 | Please DO contact io8-linux@specialix.co.uk if you require |
10 | support. |
11 | |
12 | This driver was developed in the BitWizard linux device |
13 | driver service. If you require a linux device driver for your |
14 | product, please contact devices@BitWizard.nl for a quote. |
15 | |
16 | This code is firmly based on the riscom/8 serial driver, |
17 | written by Dmitry Gorodchanin. The specialix IO8+ card |
18 | programming information was obtained from the CL-CD1865 Data |
19 | Book, and Specialix document number 6200059: IO8+ Hardware |
20 | Functional Specification, augmented by document number 6200088: |
21 | Merak Hardware Functional Specification. (IO8+/PCI is also |
22 | called Merak) |
23 | |
24 | |
25 | This program is free software; you can redistribute it and/or |
26 | modify it under the terms of the GNU General Public License as |
27 | published by the Free Software Foundation; either version 2 of |
28 | the License, or (at your option) any later version. |
29 | |
30 | This program is distributed in the hope that it will be |
31 | useful, but WITHOUT ANY WARRANTY; without even the implied |
32 | warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR |
33 | PURPOSE. See the GNU General Public License for more details. |
34 | |
35 | You should have received a copy of the GNU General Public |
36 | License along with this program; if not, write to the Free |
37 | Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, |
38 | USA. |
39 | |
40 | |
41 | Intro |
42 | ===== |
43 | |
44 | |
45 | This file contains some random information, that I like to have online |
46 | instead of in a manual that can get lost. Ever misplace your Linux |
47 | kernel sources? And the manual of one of the boards in your computer? |
48 | |
49 | |
50 | Addresses and interrupts |
51 | ======================== |
52 | |
53 | Address dip switch settings: |
54 | The dip switch sets bits 2-9 of the IO address. |
55 | |
56 | 9 8 7 6 5 4 3 2 |
57 | +-----------------+ |
58 | 0 | X X X X X X X | |
59 | | | = IoBase = 0x100 |
60 | 1 | X | |
61 | +-----------------+ ------ RS232 connectors ----> |
62 | |
63 | | | | |
64 | edge connector |
65 | | | | |
66 | V V V |
67 | |
68 | Base address 0x100 caused a conflict in one of my computers once. I |
69 | haven't the foggiest why. My Specialix card is now at 0x180. My |
70 | other computer runs just fine with the Specialix card at 0x100.... |
71 | The card occupies 4 addresses, but actually only two are really used. |
72 | |
73 | The PCI version doesn't have any dip switches. The BIOS assigns |
74 | an IO address. |
75 | |
76 | The driver now still autoprobes at 0x100, 0x180, 0x250 and 0x260. If |
77 | that causes trouble for you, please report that. I'll remove |
78 | autoprobing then. |
79 | |
80 | The driver will tell the card what IRQ to use, so you don't have to |
81 | change any jumpers to change the IRQ. Just use a command line |
82 | argument (irq=xx) to the insmod program to set the interrupt. |
83 | |
84 | The BIOS assigns the IRQ on the PCI version. You have no say in what |
85 | IRQ to use in that case. |
86 | |
87 | If your specialix cards are not at the default locations, you can use |
88 | the kernel command line argument "specialix=io0,irq0,io1,irq1...". |
89 | Here "io0" is the io address for the first card, and "irq0" is the |
90 | irq line that the first card should use. And so on. |
91 | |
92 | Examples. |
93 | |
94 | You use the driver as a module and have three cards at 0x100, 0x250 |
95 | and 0x180. And some way or another you want them detected in that |
96 | order. Moreover irq 12 is taken (e.g. by your PS/2 mouse). |
97 | |
98 | insmod specialix.o iobase=0x100,0x250,0x180 irq=9,11,15 |
99 | |
100 | The same three cards, but now in the kernel would require you to |
101 | add |
102 | |
103 | specialix=0x100,9,0x250,11,0x180,15 |
104 | |
105 | to the command line. This would become |
106 | |
107 | append="specialix=0x100,9,0x250,11,0x180,15" |
108 | |
109 | in your /etc/lilo.conf file if you use lilo. |
110 | |
111 | The Specialix driver is slightly odd: It allows you to have the second |
112 | or third card detected without having a first card. This has |
113 | advantages and disadvantages. A slot that isn't filled by an ISA card, |
114 | might be filled if a PCI card is detected. Thus if you have an ISA |
115 | card at 0x250 and a PCI card, you would get: |
116 | |
117 | sx0: specialix IO8+ Board at 0x100 not found. |
118 | sx1: specialix IO8+ Board at 0x180 not found. |
119 | sx2: specialix IO8+ board detected at 0x250, IRQ 12, CD1865 Rev. B. |
120 | sx3: specialix IO8+ Board at 0x260 not found. |
121 | sx0: specialix IO8+ board detected at 0xd800, IRQ 9, CD1865 Rev. B. |
122 | |
123 | This would happen if you don't give any probe hints to the driver. |
124 | If you would specify: |
125 | |
126 | specialix=0x250,11 |
127 | |
128 | you'd get the following messages: |
129 | |
130 | sx0: specialix IO8+ board detected at 0x250, IRQ 11, CD1865 Rev. B. |
131 | sx1: specialix IO8+ board detected at 0xd800, IRQ 9, CD1865 Rev. B. |
132 | |
133 | ISA probing is aborted after the IO address you gave is exhausted, and |
134 | the PCI card is now detected as the second card. The ISA card is now |
135 | also forced to IRQ11.... |
136 | |
137 | |
138 | Baud rates |
139 | ========== |
140 | |
141 | The rev 1.2 and below boards use a CL-CD1864. These chips can only |
142 | do 64kbit. The rev 1.3 and newer boards use a CL-CD1865. These chips |
143 | are officially capable of 115k2. |
144 | |
145 | The Specialix card uses a 25MHz crystal (in times two mode, which in |
146 | fact is a divided by two mode). This is not enough to reach the rated |
147 | 115k2 on all ports at the same time. With this clock rate you can only |
148 | do 37% of this rate. This means that at 115k2 on all ports you are |
149 | going to lose characters (The chip cannot handle that many incoming |
150 | bits at this clock rate.) (Yes, you read that correctly: there is a |
151 | limit to the number of -=bits=- per second that the chip can handle.) |
152 | |
153 | If you near the "limit" you will first start to see a graceful |
154 | degradation in that the chip cannot keep the transmitter busy at all |
155 | times. However with a central clock this slow, you can also get it to |
156 | miss incoming characters. The driver will print a warning message when |
157 | you are outside the official specs. The messages usually show up in |
158 | the file /var/log/messages . |
159 | |
160 | The specialix card cannot reliably do 115k2. If you use it, you have |
161 | to do "extensive testing" (*) to verify if it actually works. |
162 | |
163 | When "mgetty" communicates with my modem at 115k2 it reports: |
164 | got: +++[0d]ATQ0V1H0[0d][0d][8a]O[cb][0d][8a] |
165 | ^^^^ ^^^^ ^^^^ |
166 | |
167 | The three characters that have the "^^^" under them have suffered a |
168 | bit error in the highest bit. In conclusion: I've tested it, and found |
169 | that it simply DOESN'T work for me. I also suspect that this is also |
170 | caused by the baud rate being just a little bit out of tune. |
171 | |
172 | I upgraded the crystal to 66Mhz on one of my Specialix cards. Works |
173 | great! Contact me for details. (Voids warranty, requires a steady hand |
174 | and more such restrictions....) |
175 | |
176 | |
177 | (*) Cirrus logic CD1864 databook, page 40. |
178 | |
179 | |
180 | Cables for the Specialix IO8+ |
181 | ============================= |
182 | |
183 | The pinout of the connectors on the IO8+ is: |
184 | |
185 | pin short direction long name |
186 | name |
187 | Pin 1 DCD input Data Carrier Detect |
188 | Pin 2 RXD input Receive |
189 | Pin 3 DTR/RTS output Data Terminal Ready/Ready To Send |
190 | Pin 4 GND - Ground |
191 | Pin 5 TXD output Transmit |
192 | Pin 6 CTS input Clear To Send |
193 | |
194 | |
195 | -- 6 5 4 3 2 1 -- |
196 | | | |
197 | | | |
198 | | | |
199 | | | |
200 | +----- -----+ |
201 | |__________| |
202 | clip |
203 | |
204 | Front view of an RJ12 connector. Cable moves "into" the paper. |
205 | (the plug is ready to plug into your mouth this way...) |
206 | |
207 | |
208 | NULL cable. I don't know who is going to use these except for |
209 | testing purposes, but I tested the cards with this cable. (It |
210 | took quite a while to figure out, so I'm not going to delete |
211 | it. So there! :-) |
212 | |
213 | |
214 | This end goes This end needs |
215 | straight into the some twists in |
216 | RJ12 plug. the wiring. |
217 | IO8+ RJ12 IO8+ RJ12 |
218 | 1 DCD white - |
219 | - - 1 DCD |
220 | 2 RXD black 5 TXD |
221 | 3 DTR/RTS red 6 CTS |
222 | 4 GND green 4 GND |
223 | 5 TXD yellow 2 RXD |
224 | 6 CTS blue 3 DTR/RTS |
225 | |
226 | |
227 | Same NULL cable, but now sorted on the second column. |
228 | |
229 | 1 DCD white - |
230 | - - 1 DCD |
231 | 5 TXD yellow 2 RXD |
232 | 6 CTS blue 3 DTR/RTS |
233 | 4 GND green 4 GND |
234 | 2 RXD black 5 TXD |
235 | 3 DTR/RTS red 6 CTS |
236 | |
237 | |
238 | |
239 | This is a modem cable usable for hardware handshaking: |
240 | RJ12 DB25 DB9 |
241 | 1 DCD white 8 DCD 1 DCD |
242 | 2 RXD black 3 RXD 2 RXD |
243 | 3 DTR/RTS red 4 RTS 7 RTS |
244 | 4 GND green 7 GND 5 GND |
245 | 5 TXD yellow 2 TXD 3 TXD |
246 | 6 CTS blue 5 CTS 8 CTS |
247 | +---- 6 DSR 6 DSR |
248 | +---- 20 DTR 4 DTR |
249 | |
250 | This is a modem cable usable for software handshaking: |
251 | It allows you to reset the modem using the DTR ioctls. |
252 | I (REW) have never tested this, "but xxxxxxxxxxxxx |
253 | says that it works." If you test this, please |
254 | tell me and I'll fill in your name on the xxx's. |
255 | |
256 | RJ12 DB25 DB9 |
257 | 1 DCD white 8 DCD 1 DCD |
258 | 2 RXD black 3 RXD 2 RXD |
259 | 3 DTR/RTS red 20 DTR 4 DTR |
260 | 4 GND green 7 GND 5 GND |
261 | 5 TXD yellow 2 TXD 3 TXD |
262 | 6 CTS blue 5 CTS 8 CTS |
263 | +---- 6 DSR 6 DSR |
264 | +---- 4 RTS 7 RTS |
265 | |
266 | I bought a 6 wire flat cable. It was colored as indicated. |
267 | Check that yours is the same before you trust me on this. |
268 | |
269 | |
270 | Hardware handshaking issues. |
271 | ============================ |
272 | |
273 | The driver can be compiled in two different ways. The default |
274 | ("Specialix DTR/RTS pin is RTS" is off) the pin behaves as DTR when |
275 | hardware handshaking is off. It behaves as the RTS hardware |
276 | handshaking signal when hardware handshaking is selected. |
277 | |
278 | When you use this, you have to use the appropriate cable. The |
279 | cable will either be compatible with hardware handshaking or with |
280 | software handshaking. So switching on the fly is not really an |
281 | option. |
282 | |
283 | I actually prefer to use the "Specialix DTR/RTS pin is RTS" option. |
284 | This makes the DTR/RTS pin always an RTS pin, and ioctls to |
285 | change DTR are always ignored. I have a cable that is configured |
286 | for this. |
287 | |
288 | |
289 | Ports and devices |
290 | ================= |
291 | |
292 | Port 0 is the one furthest from the card-edge connector. |
293 | |
294 | Devices: |
295 | |
296 | You should make the devices as follows: |
297 | |
298 | bash |
299 | cd /dev |
300 | for i in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 \ |
301 | 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
302 | do |
303 | echo -n "$i " |
304 | mknod /dev/ttyW$i c 75 $i |
305 | mknod /dev/cuw$i c 76 $i |
306 | done |
307 | echo "" |
308 | |
309 | If your system doesn't come with these devices preinstalled, bug your |
310 | linux-vendor about this. They have had ample time to get this |
311 | implemented by now. |
312 | |
313 | You cannot have more than 4 boards in one computer. The card only |
314 | supports 4 different interrupts. If you really want this, contact me |
315 | about this and I'll give you a few tips (requires soldering iron).... |
316 | |
317 | If you have enough PCI slots, you can probably use more than 4 PCI |
318 | versions of the card though.... |
319 | |
320 | The PCI version of the card cannot adhere to the mechanical part of |
321 | the PCI spec because the 8 serial connectors are simply too large. If |
322 | it doesn't fit in your computer, bring back the card. |
323 | |
324 | |
325 | ------------------------------------------------------------------------ |
326 | |
327 | |
328 | Fixed bugs and restrictions: |
329 | - During initialization, interrupts are blindly turned on. |
330 | Having a shadow variable would cause an extra memory |
331 | access on every IO instruction. |
332 | - The interrupt (on the card) should be disabled when we |
333 | don't allocate the Linux end of the interrupt. This allows |
334 | a different driver/card to use it while all ports are not in |
335 | use..... (a la standard serial port) |
336 | == An extra _off variant of the sx_in and sx_out macros are |
337 | now available. They don't set the interrupt enable bit. |
338 | These are used during initialization. Normal operation uses |
339 | the old variant which enables the interrupt line. |
340 | - RTS/DTR issue needs to be implemented according to |
341 | specialix' spec. |
342 | I kind of like the "determinism" of the current |
343 | implementation. Compile time flag? |
344 | == Ok. Compile time flag! Default is how Specialix likes it. |
345 | == Now a config time flag! Gets saved in your config file. Neat! |
346 | - Can you set the IO address from the lilo command line? |
347 | If you need this, bug me about it, I'll make it. |
348 | == Hah! No bugging needed. Fixed! :-) |
349 | - Cirrus logic hasn't gotten back to me yet why the CD1865 can |
350 | and the CD1864 can't do 115k2. I suspect that this is |
351 | because the CD1864 is not rated for 33MHz operation. |
352 | Therefore the CD1864 versions of the card can't do 115k2 on |
353 | all ports just like the CD1865 versions. The driver does |
354 | not block 115k2 on CD1864 cards. |
355 | == I called the Cirrus Logic representative here in Holland. |
356 | The CD1864 databook is identical to the CD1865 databook, |
357 | except for an extra warning at the end. Similar Bit errors |
358 | have been observed in testing at 115k2 on both an 1865 and |
359 | a 1864 chip. I see no reason why I would prohibit 115k2 on |
360 | 1864 chips and not do it on 1865 chips. Actually there is |
361 | reason to prohibit it on BOTH chips. I print a warning. |
362 | If you use 115k2, you're on your own. |
363 | - A spiky CD may send spurious HUPs. Also in CLOCAL??? |
364 | -- A fix for this turned out to be counter productive. |
365 | Different fix? Current behaviour is acceptable? |
366 | -- Maybe the current implementation is correct. If anybody |
367 | gets bitten by this, please report, and it will get fixed. |
368 | |
369 | -- Testing revealed that when in CLOCAL, the problem doesn't |
370 | occur. As warned for in the CD1865 manual, the chip may |
371 | send modem intr's on a spike. We could filter those out, |
372 | but that would be a cludge anyway (You'd still risk getting |
373 | a spurious HUP when two spikes occur.)..... |
374 | |
375 | |
376 | |
377 | Bugs & restrictions: |
378 | - This is a difficult card to autoprobe. |
379 | You have to WRITE to the address register to even |
380 | read-probe a CD186x register. Disable autodetection? |
381 | -- Specialix: any suggestions? |
382 | - Arbitrary baud rates are not implemented yet. |
383 | If you need this, bug me about it. |
384 | |
385 |