Merge tag 'omap-for-v5.8/fixes-merge-window-signed' of git://git.kernel.org/pub/scm...
[linux-2.6-microblaze.git] / Documentation / networking / z8530drv.rst
1 .. SPDX-License-Identifier: GPL-2.0
2 .. include:: <isonum.txt>
3
4 =========================================================
5 SCC.C - Linux driver for Z8530 based HDLC cards for AX.25
6 =========================================================
7
8
9 This is a subset of the documentation. To use this driver you MUST have the
10 full package from:
11
12 Internet:
13
14     1. ftp://ftp.ccac.rwth-aachen.de/pub/jr/z8530drv-utils_3.0-3.tar.gz
15
16     2. ftp://ftp.pspt.fi/pub/ham/linux/ax25/z8530drv-utils_3.0-3.tar.gz
17
18 Please note that the information in this document may be hopelessly outdated.
19 A new version of the documentation, along with links to other important
20 Linux Kernel AX.25 documentation and programs, is available on
21 http://yaina.de/jreuter
22
23 Copyright |copy| 1993,2000 by Joerg Reuter DL1BKE <jreuter@yaina.de>
24
25 portions Copyright |copy| 1993 Guido ten Dolle PE1NNZ
26
27 for the complete copyright notice see >> Copying.Z8530DRV <<
28
29 1. Initialization of the driver
30 ===============================
31
32 To use the driver, 3 steps must be performed:
33
34      1. if compiled as module: loading the module
35      2. Setup of hardware, MODEM and KISS parameters with sccinit
36      3. Attach each channel to the Linux kernel AX.25 with "ifconfig"
37
38 Unlike the versions below 2.4 this driver is a real network device
39 driver. If you want to run xNOS instead of our fine kernel AX.25
40 use a 2.x version (available from above sites) or read the
41 AX.25-HOWTO on how to emulate a KISS TNC on network device drivers.
42
43
44 1.1 Loading the module
45 ======================
46
47 (If you're going to compile the driver as a part of the kernel image,
48  skip this chapter and continue with 1.2)
49
50 Before you can use a module, you'll have to load it with::
51
52         insmod scc.o
53
54 please read 'man insmod' that comes with module-init-tools.
55
56 You should include the insmod in one of the /etc/rc.d/rc.* files,
57 and don't forget to insert a call of sccinit after that. It
58 will read your /etc/z8530drv.conf.
59
60 1.2. /etc/z8530drv.conf
61 =======================
62
63 To setup all parameters you must run /sbin/sccinit from one
64 of your rc.*-files. This has to be done BEFORE you can
65 "ifconfig" an interface. Sccinit reads the file /etc/z8530drv.conf
66 and sets the hardware, MODEM and KISS parameters. A sample file is
67 delivered with this package. Change it to your needs.
68
69 The file itself consists of two main sections.
70
71 1.2.1 configuration of hardware parameters
72 ==========================================
73
74 The hardware setup section defines the following parameters for each
75 Z8530::
76
77     chip    1
78     data_a  0x300                   # data port A
79     ctrl_a  0x304                   # control port A
80     data_b  0x301                   # data port B
81     ctrl_b  0x305                   # control port B
82     irq     5                       # IRQ No. 5
83     pclock  4915200                 # clock
84     board   BAYCOM                  # hardware type
85     escc    no                      # enhanced SCC chip? (8580/85180/85280)
86     vector  0                       # latch for interrupt vector
87     special no                      # address of special function register
88     option  0                       # option to set via sfr
89
90
91 chip
92         - this is just a delimiter to make sccinit a bit simpler to
93           program. A parameter has no effect.
94
95 data_a
96         - the address of the data port A of this Z8530 (needed)
97 ctrl_a
98         - the address of the control port A (needed)
99 data_b
100         - the address of the data port B (needed)
101 ctrl_b
102         - the address of the control port B (needed)
103
104 irq
105         - the used IRQ for this chip. Different chips can use different
106           IRQs or the same. If they share an interrupt, it needs to be
107           specified within one chip-definition only.
108
109 pclock  - the clock at the PCLK pin of the Z8530 (option, 4915200 is
110           default), measured in Hertz
111
112 board
113         - the "type" of the board:
114
115            =======================  ========
116            SCC type                 value
117            =======================  ========
118            PA0HZP SCC card          PA0HZP
119            EAGLE card               EAGLE
120            PC100 card               PC100
121            PRIMUS-PC (DG9BL) card   PRIMUS
122            BayCom (U)SCC card       BAYCOM
123            =======================  ========
124
125 escc
126         - if you want support for ESCC chips (8580, 85180, 85280), set
127           this to "yes" (option, defaults to "no")
128
129 vector
130         - address of the vector latch (aka "intack port") for PA0HZP
131           cards. There can be only one vector latch for all chips!
132           (option, defaults to 0)
133
134 special
135         - address of the special function register on several cards.
136           (option, defaults to 0)
137
138 option  - The value you write into that register (option, default is 0)
139
140 You can specify up to four chips (8 channels). If this is not enough,
141 just change::
142
143         #define MAXSCC 4
144
145 to a higher value.
146
147 Example for the BAYCOM USCC:
148 ----------------------------
149
150 ::
151
152         chip    1
153         data_a  0x300                   # data port A
154         ctrl_a  0x304                   # control port A
155         data_b  0x301                   # data port B
156         ctrl_b  0x305                   # control port B
157         irq     5                       # IRQ No. 5 (#)
158         board   BAYCOM                  # hardware type (*)
159         #
160         # SCC chip 2
161         #
162         chip    2
163         data_a  0x302
164         ctrl_a  0x306
165         data_b  0x303
166         ctrl_b  0x307
167         board   BAYCOM
168
169 An example for a PA0HZP card:
170 -----------------------------
171
172 ::
173
174         chip 1
175         data_a 0x153
176         data_b 0x151
177         ctrl_a 0x152
178         ctrl_b 0x150
179         irq 9
180         pclock 4915200
181         board PA0HZP
182         vector 0x168
183         escc no
184         #
185         #
186         #
187         chip 2
188         data_a 0x157
189         data_b 0x155
190         ctrl_a 0x156
191         ctrl_b 0x154
192         irq 9
193         pclock 4915200
194         board PA0HZP
195         vector 0x168
196         escc no
197
198 A DRSI would should probably work with this:
199 --------------------------------------------
200 (actually: two DRSI cards...)
201
202 ::
203
204         chip 1
205         data_a 0x303
206         data_b 0x301
207         ctrl_a 0x302
208         ctrl_b 0x300
209         irq 7
210         pclock 4915200
211         board DRSI
212         escc no
213         #
214         #
215         #
216         chip 2
217         data_a 0x313
218         data_b 0x311
219         ctrl_a 0x312
220         ctrl_b 0x310
221         irq 7
222         pclock 4915200
223         board DRSI
224         escc no
225
226 Note that you cannot use the on-board baudrate generator off DRSI
227 cards. Use "mode dpll" for clock source (see below).
228
229 This is based on information provided by Mike Bilow (and verified
230 by Paul Helay)
231
232 The utility "gencfg"
233 --------------------
234
235 If you only know the parameters for the PE1CHL driver for DOS,
236 run gencfg. It will generate the correct port addresses (I hope).
237 Its parameters are exactly the same as the ones you use with
238 the "attach scc" command in net, except that the string "init" must
239 not appear. Example::
240
241         gencfg 2 0x150 4 2 0 1 0x168 9 4915200
242
243 will print a skeleton z8530drv.conf for the OptoSCC to stdout.
244
245 ::
246
247         gencfg 2 0x300 2 4 5 -4 0 7 4915200 0x10
248
249 does the same for the BAYCOM USCC card. In my opinion it is much easier
250 to edit scc_config.h...
251
252
253 1.2.2 channel configuration
254 ===========================
255
256 The channel definition is divided into three sub sections for each
257 channel:
258
259 An example for scc0::
260
261         # DEVICE
262
263         device scc0     # the device for the following params
264
265         # MODEM / BUFFERS
266
267         speed 1200              # the default baudrate
268         clock dpll              # clock source:
269                                 #       dpll     = normal half duplex operation
270                                 #       external = MODEM provides own Rx/Tx clock
271                                 #       divider  = use full duplex divider if
272                                 #                  installed (1)
273         mode nrzi               # HDLC encoding mode
274                                 #       nrzi = 1k2 MODEM, G3RUH 9k6 MODEM
275                                 #       nrz  = DF9IC 9k6 MODEM
276                                 #
277         bufsize 384             # size of buffers. Note that this must include
278                                 # the AX.25 header, not only the data field!
279                                 # (optional, defaults to 384)
280
281         # KISS (Layer 1)
282
283         txdelay 36              # (see chapter 1.4)
284         persist 64
285         slot    8
286         tail    8
287         fulldup 0
288         wait    12
289         min     3
290         maxkey  7
291         idle    3
292         maxdef  120
293         group   0
294         txoff   off
295         softdcd on
296         slip    off
297
298 The order WITHIN these sections is unimportant. The order OF these
299 sections IS important. The MODEM parameters are set with the first
300 recognized KISS parameter...
301
302 Please note that you can initialize the board only once after boot
303 (or insmod). You can change all parameters but "mode" and "clock"
304 later with the Sccparam program or through KISS. Just to avoid
305 security holes...
306
307 (1) this divider is usually mounted on the SCC-PBC (PA0HZP) or not
308     present at all (BayCom). It feeds back the output of the DPLL
309     (digital pll) as transmit clock. Using this mode without a divider
310     installed will normally result in keying the transceiver until
311     maxkey expires --- of course without sending anything (useful).
312
313 2. Attachment of a channel by your AX.25 software
314 =================================================
315
316 2.1 Kernel AX.25
317 ================
318
319 To set up an AX.25 device you can simply type::
320
321         ifconfig scc0 44.128.1.1 hw ax25 dl0tha-7
322
323 This will create a network interface with the IP number 44.128.20.107
324 and the callsign "dl0tha". If you do not have any IP number (yet) you
325 can use any of the 44.128.0.0 network. Note that you do not need
326 axattach. The purpose of axattach (like slattach) is to create a KISS
327 network device linked to a TTY. Please read the documentation of the
328 ax25-utils and the AX.25-HOWTO to learn how to set the parameters of
329 the kernel AX.25.
330
331 2.2 NOS, NET and TFKISS
332 =======================
333
334 Since the TTY driver (aka KISS TNC emulation) is gone you need
335 to emulate the old behaviour. The cost of using these programs is
336 that you probably need to compile the kernel AX.25, regardless of whether
337 you actually use it or not. First setup your /etc/ax25/axports,
338 for example::
339
340         9k6     dl0tha-9  9600  255 4 9600 baud port (scc3)
341         axlink  dl0tha-15 38400 255 4 Link to NOS
342
343 Now "ifconfig" the scc device::
344
345         ifconfig scc3 44.128.1.1 hw ax25 dl0tha-9
346
347 You can now axattach a pseudo-TTY::
348
349         axattach /dev/ptys0 axlink
350
351 and start your NOS and attach /dev/ptys0 there. The problem is that
352 NOS is reachable only via digipeating through the kernel AX.25
353 (disastrous on a DAMA controlled channel). To solve this problem,
354 configure "rxecho" to echo the incoming frames from "9k6" to "axlink"
355 and outgoing frames from "axlink" to "9k6" and start::
356
357         rxecho
358
359 Or simply use "kissbridge" coming with z8530drv-utils::
360
361         ifconfig scc3 hw ax25 dl0tha-9
362         kissbridge scc3 /dev/ptys0
363
364
365 3. Adjustment and Display of parameters
366 =======================================
367
368 3.1 Displaying SCC Parameters:
369 ==============================
370
371 Once a SCC channel has been attached, the parameter settings and
372 some statistic information can be shown using the param program::
373
374         dl1bke-u:~$ sccstat scc0
375
376         Parameters:
377
378         speed       : 1200 baud
379         txdelay     : 36
380         persist     : 255
381         slottime    : 0
382         txtail      : 8
383         fulldup     : 1
384         waittime    : 12
385         mintime     : 3 sec
386         maxkeyup    : 7 sec
387         idletime    : 3 sec
388         maxdefer    : 120 sec
389         group       : 0x00
390         txoff       : off
391         softdcd     : on
392         SLIP        : off
393
394         Status:
395
396         HDLC                  Z8530           Interrupts         Buffers
397         -----------------------------------------------------------------------
398         Sent       :     273  RxOver :     0  RxInts :   125074  Size    :  384
399         Received   :    1095  TxUnder:     0  TxInts :     4684  NoSpace :    0
400         RxErrors   :    1591                  ExInts :    11776
401         TxErrors   :       0                  SpInts :     1503
402         Tx State   :    idle
403
404
405 The status info shown is:
406
407 ==============  ==============================================================
408 Sent            number of frames transmitted
409 Received        number of frames received
410 RxErrors        number of receive errors (CRC, ABORT)
411 TxErrors        number of discarded Tx frames (due to various reasons)
412 Tx State        status of the Tx interrupt handler: idle/busy/active/tail (2)
413 RxOver          number of receiver overruns
414 TxUnder         number of transmitter underruns
415 RxInts          number of receiver interrupts
416 TxInts          number of transmitter interrupts
417 EpInts          number of receiver special condition interrupts
418 SpInts          number of external/status interrupts
419 Size            maximum size of an AX.25 frame (*with* AX.25 headers!)
420 NoSpace         number of times a buffer could not get allocated
421 ==============  ==============================================================
422
423 An overrun is abnormal. If lots of these occur, the product of
424 baudrate and number of interfaces is too high for the processing
425 power of your computer. NoSpace errors are unlikely to be caused by the
426 driver or the kernel AX.25.
427
428
429 3.2 Setting Parameters
430 ======================
431
432
433 The setting of parameters of the emulated KISS TNC is done in the
434 same way in the SCC driver. You can change parameters by using
435 the kissparms program from the ax25-utils package or use the program
436 "sccparam"::
437
438      sccparam <device> <paramname> <decimal-|hexadecimal value>
439
440 You can change the following parameters:
441
442 ===========   =====
443 param         value
444 ===========   =====
445 speed         1200
446 txdelay       36
447 persist       255
448 slottime      0
449 txtail        8
450 fulldup       1
451 waittime      12
452 mintime       3
453 maxkeyup      7
454 idletime      3
455 maxdefer      120
456 group         0x00
457 txoff         off
458 softdcd       on
459 SLIP          off
460 ===========   =====
461
462
463 The parameters have the following meaning:
464
465 speed:
466      The baudrate on this channel in bits/sec
467
468      Example: sccparam /dev/scc3 speed 9600
469
470 txdelay:
471      The delay (in units of 10 ms) after keying of the
472      transmitter, until the first byte is sent. This is usually
473      called "TXDELAY" in a TNC.  When 0 is specified, the driver
474      will just wait until the CTS signal is asserted. This
475      assumes the presence of a timer or other circuitry in the
476      MODEM and/or transmitter, that asserts CTS when the
477      transmitter is ready for data.
478      A normal value of this parameter is 30-36.
479
480      Example: sccparam /dev/scc0 txd 20
481
482 persist:
483      This is the probability that the transmitter will be keyed
484      when the channel is found to be free.  It is a value from 0
485      to 255, and the probability is (value+1)/256.  The value
486      should be somewhere near 50-60, and should be lowered when
487      the channel is used more heavily.
488
489      Example: sccparam /dev/scc2 persist 20
490
491 slottime:
492      This is the time between samples of the channel. It is
493      expressed in units of 10 ms.  About 200-300 ms (value 20-30)
494      seems to be a good value.
495
496      Example: sccparam /dev/scc0 slot 20
497
498 tail:
499      The time the transmitter will remain keyed after the last
500      byte of a packet has been transferred to the SCC. This is
501      necessary because the CRC and a flag still have to leave the
502      SCC before the transmitter is keyed down. The value depends
503      on the baudrate selected.  A few character times should be
504      sufficient, e.g. 40ms at 1200 baud. (value 4)
505      The value of this parameter is in 10 ms units.
506
507      Example: sccparam /dev/scc2 4
508
509 full:
510      The full-duplex mode switch. This can be one of the following
511      values:
512
513      0:   The interface will operate in CSMA mode (the normal
514           half-duplex packet radio operation)
515      1:   Fullduplex mode, i.e. the transmitter will be keyed at
516           any time, without checking the received carrier.  It
517           will be unkeyed when there are no packets to be sent.
518      2:   Like 1, but the transmitter will remain keyed, also
519           when there are no packets to be sent.  Flags will be
520           sent in that case, until a timeout (parameter 10)
521           occurs.
522
523      Example: sccparam /dev/scc0 fulldup off
524
525 wait:
526      The initial waittime before any transmit attempt, after the
527      frame has been queue for transmit.  This is the length of
528      the first slot in CSMA mode.  In full duplex modes it is
529      set to 0 for maximum performance.
530      The value of this parameter is in 10 ms units.
531
532      Example: sccparam /dev/scc1 wait 4
533
534 maxkey:
535      The maximal time the transmitter will be keyed to send
536      packets, in seconds.  This can be useful on busy CSMA
537      channels, to avoid "getting a bad reputation" when you are
538      generating a lot of traffic.  After the specified time has
539      elapsed, no new frame will be started. Instead, the trans-
540      mitter will be switched off for a specified time (parameter
541      min), and then the selected algorithm for keyup will be
542      started again.
543      The value 0 as well as "off" will disable this feature,
544      and allow infinite transmission time.
545
546      Example: sccparam /dev/scc0 maxk 20
547
548 min:
549      This is the time the transmitter will be switched off when
550      the maximum transmission time is exceeded.
551
552      Example: sccparam /dev/scc3 min 10
553
554 idle:
555      This parameter specifies the maximum idle time in full duplex
556      2 mode, in seconds.  When no frames have been sent for this
557      time, the transmitter will be keyed down.  A value of 0 is
558      has same result as the fullduplex mode 1. This parameter
559      can be disabled.
560
561      Example: sccparam /dev/scc2 idle off       # transmit forever
562
563 maxdefer
564      This is the maximum time (in seconds) to wait for a free channel
565      to send. When this timer expires the transmitter will be keyed
566      IMMEDIATELY. If you love to get trouble with other users you
567      should set this to a very low value ;-)
568
569      Example: sccparam /dev/scc0 maxdefer 240   # 2 minutes
570
571
572 txoff:
573      When this parameter has the value 0, the transmission of packets
574      is enable. Otherwise it is disabled.
575
576      Example: sccparam /dev/scc2 txoff on
577
578 group:
579      It is possible to build special radio equipment to use more than
580      one frequency on the same band, e.g. using several receivers and
581      only one transmitter that can be switched between frequencies.
582      Also, you can connect several radios that are active on the same
583      band.  In these cases, it is not possible, or not a good idea, to
584      transmit on more than one frequency.  The SCC driver provides a
585      method to lock transmitters on different interfaces, using the
586      "param <interface> group <x>" command.  This will only work when
587      you are using CSMA mode (parameter full = 0).
588
589      The number <x> must be 0 if you want no group restrictions, and
590      can be computed as follows to create restricted groups:
591      <x> is the sum of some OCTAL numbers:
592
593
594      ===  =======================================================
595      200  This transmitter will only be keyed when all other
596           transmitters in the group are off.
597      100  This transmitter will only be keyed when the carrier
598           detect of all other interfaces in the group is off.
599      0xx  A byte that can be used to define different groups.
600           Interfaces are in the same group, when the logical AND
601           between their xx values is nonzero.
602      ===  =======================================================
603
604      Examples:
605
606      When 2 interfaces use group 201, their transmitters will never be
607      keyed at the same time.
608
609      When 2 interfaces use group 101, the transmitters will only key
610      when both channels are clear at the same time.  When group 301,
611      the transmitters will not be keyed at the same time.
612
613      Don't forget to convert the octal numbers into decimal before
614      you set the parameter.
615
616      Example: (to be written)
617
618 softdcd:
619      use a software dcd instead of the real one... Useful for a very
620      slow squelch.
621
622      Example: sccparam /dev/scc0 soft on
623
624
625 4. Problems
626 ===========
627
628 If you have tx-problems with your BayCom USCC card please check
629 the manufacturer of the 8530. SGS chips have a slightly
630 different timing. Try Zilog...  A solution is to write to register 8
631 instead to the data port, but this won't work with the ESCC chips.
632 *SIGH!*
633
634 A very common problem is that the PTT locks until the maxkeyup timer
635 expires, although interrupts and clock source are correct. In most
636 cases compiling the driver with CONFIG_SCC_DELAY (set with
637 make config) solves the problems. For more hints read the (pseudo) FAQ
638 and the documentation coming with z8530drv-utils.
639
640 I got reports that the driver has problems on some 386-based systems.
641 (i.e. Amstrad) Those systems have a bogus AT bus timing which will
642 lead to delayed answers on interrupts. You can recognize these
643 problems by looking at the output of Sccstat for the suspected
644 port. If it shows under- and overruns you own such a system.
645
646 Delayed processing of received data: This depends on
647
648 - the kernel version
649
650 - kernel profiling compiled or not
651
652 - a high interrupt load
653
654 - a high load of the machine --- running X, Xmorph, XV and Povray,
655   while compiling the kernel... hmm ... even with 32 MB RAM ...  ;-)
656   Or running a named for the whole .ampr.org domain on an 8 MB
657   box...
658
659 - using information from rxecho or kissbridge.
660
661 Kernel panics: please read /linux/README and find out if it
662 really occurred within the scc driver.
663
664 If you cannot solve a problem, send me
665
666 - a description of the problem,
667 - information on your hardware (computer system, scc board, modem)
668 - your kernel version
669 - the output of cat /proc/net/z8530
670
671 4. Thor RLC100
672 ==============
673
674 Mysteriously this board seems not to work with the driver. Anyone
675 got it up-and-running?
676
677
678 Many thanks to Linus Torvalds and Alan Cox for including the driver
679 in the Linux standard distribution and their support.
680
681 ::
682
683         Joerg Reuter    ampr-net: dl1bke@db0pra.ampr.org
684                         AX-25   : DL1BKE @ DB0ABH.#BAY.DEU.EU
685                         Internet: jreuter@yaina.de
686                         WWW     : http://yaina.de/jreuter