home *** CD-ROM | disk | FTP | other *** search
/ Chip 1998 September / CHIP Eylül 1998.iso / Slackwar / docs / linux-2.0.34 / networking / z8530drv.txt < prev   
Encoding:
Text File  |  1997-08-11  |  23.0 KB  |  782 lines

  1. This is a subset of the documentation. To use this driver you MUST have the
  2. full package "z8530drv-2.4c.dl1bke.tar.gz" from either ftp.pspt.fi, 
  3. sunsite.unc.edu or db0bm.automation.fh-aachen.de. Do not try to use the
  4. utilities from z8530drv-utils-3.0 as they will not work with the 2.4 series
  5. of the driver!
  6.  
  7. ---------------------------------------------------------------------------
  8.  
  9.  
  10.      SCC.C - Linux driver for Z8530 based HDLC cards for AX.25      
  11.  
  12.    ********************************************************************
  13.  
  14.         (c) 1993,1997 by Joerg Reuter DL1BKE
  15.  
  16.         portions (c) 1993 Guido ten Dolle PE1NNZ
  17.  
  18.         for the complete copyright notice see >> Copying.Z8530DRV <<
  19.  
  20.    ******************************************************************** 
  21.  
  22.  
  23. 1. Initialization of the driver
  24. ===============================
  25.  
  26. To use the driver, 3 steps must be performed:
  27.  
  28.      1. if compiled as module: loading the module
  29.      2. Setup of hardware, MODEM and KISS parameters with sccinit
  30.      3. Attachment of each channel in the packet software
  31.  
  32.  
  33. 1.1 Loading the module
  34. ======================
  35.  
  36. (If you're going to compile the driver as a part of the kernel image,
  37.  skip this chapter and continue with 1.2)
  38.  
  39. Before you can use a module, you'll have to load it with
  40.  
  41.     insmod scc.o
  42.  
  43. please read 'man insmod' that comes with modutils.
  44.  
  45. You should include the insmod in one of the /etc/rc.d/rc.* files,
  46. and don't forget to insert a call of sccinit after that. It
  47. will read  your
  48.  
  49.  
  50. 1.2. /etc/z8530drv.rc
  51. =====================
  52.  
  53. To setup all parameters you must run /sbin/sccinit from one
  54. of your rc.*-files. This has to be done BEFORE the start of
  55. NET or axattach. Sccinit reads the file /etc/z8530drv.rc
  56. and sets the hardware, MODEM and KISS parameters. A sample file is
  57. delivered with this package. Change it to your needs.
  58.  
  59. The file itself consists of two main sections.
  60.  
  61. 1.2.1 configuration of hardware parameters
  62. ==========================================
  63.  
  64. The hardware setup section defines the following parameters for each
  65. Z8530:
  66.  
  67. chip    1
  68. data_a  0x300                   # data port A
  69. ctrl_a  0x304                   # control port A
  70. data_b  0x301                   # data port B
  71. ctrl_b  0x305                   # control port B
  72. irq     5                       # IRQ No. 5
  73. pclock  4915200                 # clock
  74. board   BAYCOM                  # hardware type
  75. escc    no                      # enhanced SCC chip? (8580/85180/85280)
  76. vector  0                       # latch for interrupt vector
  77. special no                      # address of special function register
  78. option  0                       # option to set via sfr
  79.  
  80.  
  81. chip    - this is just a delimiter to make sccinit a bit simpler to
  82.       program. A parameter has no effect.
  83.  
  84. data_a  - the address of the data port A of this Z8530 (needed)
  85. ctrl_a  - the address of the control port A (needed)
  86. data_b  - the address of the data port B (needed)
  87. ctrl_b  - the address of the control port B (needed)
  88.  
  89. irq     - the used IRQ for this chip. Different chips can use different
  90.           IRQs or the same. If they share an interrupt, it needs to be
  91.       specified within one chip-definition only.
  92.  
  93. pclock  - the clock at the PCLK pin of the Z8530 (option, 4915200 is
  94.           default), measured in Hertz
  95.  
  96. board   - the "type" of the board:
  97.  
  98.        SCC type                 value
  99.        ---------------------------------
  100.        PA0HZP SCC card          PA0HZP
  101.        EAGLE card               EAGLE
  102.        PC100 card               PC100
  103.        PRIMUS-PC (DG9BL) card   PRIMUS
  104.        BayCom (U)SCC card       BAYCOM
  105.  
  106. escc    - if you want support for ESCC chips (8580, 85180, 85280), set
  107.           this to "yes" (option, defaults to "no")
  108.  
  109. vector  - address of the vector latch (aka "intack port") for PA0HZP
  110.           cards. There can be only one vector latch for all chips!
  111.       (option, defaults to 0)
  112.  
  113. special - address of the special function register on several cards.
  114.           (option, defaults to 0)
  115.  
  116. option  - The value you write into that register (option, default is 0)
  117.  
  118. You can specify up to four chips (8 channels). If this is not enough,
  119. just change
  120.  
  121.     #define MAXSCC 4
  122.  
  123. to a higher value.
  124.  
  125. Example for the BayCom USCC:
  126. ----------------------------
  127.  
  128. chip    1
  129. data_a  0x300                   # data port A
  130. ctrl_a  0x304                   # control port A
  131. data_b  0x301                   # data port B
  132. ctrl_b  0x305                   # control port B
  133. irq     5                       # IRQ No. 5 (#)
  134. board   BAYCOM                  # hardware type (*)
  135. #
  136. # SCC chip 2
  137. #
  138. chip    2
  139. data_a  0x302
  140. ctrl_a  0x306
  141. data_b  0x303
  142. ctrl_b  0x307
  143. board   BAYCOM
  144.  
  145. An example for a PA0HZP card:
  146. -----------------------------
  147.  
  148. chip 1
  149. data_a 0x153
  150. data_b 0x151
  151. ctrl_a 0x152
  152. ctrl_b 0x150
  153. irq 9
  154. pclock 4915200
  155. board PA0HZP
  156. vector 0x168
  157. escc no
  158. #
  159. #
  160. #
  161. chip 2
  162. data_a 0x157
  163. data_b 0x155
  164. ctrl_a 0x156
  165. ctrl_b 0x154
  166. irq 9
  167. pclock 4915200
  168. board PA0HZP
  169. vector 0x168
  170. escc no
  171.  
  172. A DRSI would should probably work with this:
  173. --------------------------------------------
  174. (actually: two DRSI cards...)
  175.  
  176. chip 1
  177. data_a 0x303
  178. data_b 0x301
  179. ctrl_a 0x302
  180. ctrl_b 0x300
  181. irq 7
  182. pclock 4915200
  183. board DRSI
  184. escc no
  185. #
  186. #
  187. #
  188. chip 2
  189. data_a 0x313
  190. data_b 0x311
  191. ctrl_a 0x312
  192. ctrl_b 0x310
  193. irq 7
  194. pclock 4915200
  195. board DRSI
  196. escc no
  197.  
  198. Note that you cannot use the on-board baudrate generator off DRSI
  199. cards. Use "mode dpll" for clock source (see below).
  200.  
  201. This is based on information provided by Mike Bilow (and verified
  202. by Paul Helay)
  203.  
  204. The utility "gencfg"
  205. --------------------
  206.  
  207. If you only know the parameters for the PE1CHL driver for DOS,
  208. run gencfg. It will generate the correct port addresses (I hope).
  209. Its parameters are exactly the same as the ones you use with
  210. the "attach scc" command in net, except that the string "init" must 
  211. not appear. Example:
  212.  
  213. gencfg 2 0x150 4 2 0 1 0x168 9 4915200 
  214.  
  215. will print a skeleton z8530drv.rc for the OptoSCC to stdout.
  216.  
  217. gencfg 2 0x300 2 4 5 -4 0 7 4915200 0x10
  218.  
  219. does the same for the BayCom USCC card. I my opinion it is much easier
  220. to edit scc_config.h... 
  221.  
  222.  
  223. 1.2.2 channel configuration
  224. ===========================
  225.  
  226. The channel definition is divided into three sub sections for each
  227. channel:
  228.  
  229. An example for /dev/scc0:
  230.  
  231. # DEVICE
  232.  
  233. device /dev/scc0    # the device for the following params
  234.  
  235. # MODEM / BUFFERS
  236.  
  237. speed 1200        # the default baudrate
  238. clock dpll        # clock source: 
  239.             #     dpll     = normal halfduplex operation
  240.             #     external = MODEM provides own Rx/Tx clock
  241.             #    divider  = use fullduplex divider if
  242.             #           installed (1)
  243. mode nrzi        # HDLC encoding mode
  244.             #    nrzi = 1k2 MODEM, G3RUH 9k6 MODEM
  245.             #    nrz  = DF9IC 9k6 MODEM
  246.             #
  247. rxbuffers 8        # number of rx buffers allocated
  248.             #         (option, default is 4)
  249. txbuffers 16        # number of tx buffers allocated
  250.             #        (option, default is 16)
  251. bufsize    384        # size of buffers. Note that this must include
  252.             # the AX.25 header, not only the data field!
  253.             # (optional, defaults to 384)
  254.  
  255. # KISS (Layer 1)
  256.  
  257. txdelay 36              # (see chapter 1.4)
  258. persist 64
  259. slot    8
  260. tail    8
  261. fulldup 0
  262. wait    12
  263. min     3
  264. maxkey  7
  265. idle    3
  266. maxdef  120
  267. group   0
  268. txoff   off
  269. softdcd on                   
  270. slip    off
  271.  
  272. The order WITHIN these sections is unimportant. The order OF these
  273. sections IS important. The MODEM parameters are set with the first
  274. recognized KISS parameter...
  275.  
  276. Please note that you can initialize the board only once after boot. 
  277. You can change all parameters but "mode" and "clock" later with the
  278. Sccparam program or through KISS. Just to avoid security holes... 
  279.  
  280. (1) this divider is usually mounted on the SCC-PBC (PA0HZP) or not
  281.     present at all (BayCom). It feeds back the output of the DPLL 
  282.     (digital pll) as transmit clock. Using this mode without a divider 
  283.     installed will normally result in keying the transceiver until 
  284.     maxkey expires --- of course without sending anything (useful).
  285.  
  286.  
  287. 2. Attachment of a channel by your AX.25 software
  288. =================================================
  289.  
  290. 2.1 KA9Q NOS derivates
  291. ======================
  292.  
  293. When the linux has startup, the SCC driver has been initialized,
  294. you can attach the channels in your packet software. This is done
  295. by open the scc devices by using the attach asy command.
  296. The SCC-drivers emulates the scc devices as serial asy ports,
  297. this means e.g. that the baudrate can be set in the attach command.
  298.  
  299.  
  300. Example Wampes:
  301.  
  302. #############################################################################################
  303. # Wampes device attach
  304. # NOTE: Interfacename and the device must be the same!!
  305. # Usage: attach asy 0 0 slip|vjslip|ax25ui|ax25i|nrs|kissui <label> 0 <mtu> <speed> [ip_addr]
  306. #
  307. attach asy 0 0 kissi  scc0 256 256 1200   # Attach SCC channel 1 in 1200 baud
  308. attach asy 0 0 kissi  scc1 256 256 1200   # Attach SCC channel 2 in 1200 baud
  309. attach asy 0 0 kissui scc2 256 256 38400  # Attach SCC channel 3 in 38400 baud
  310. attach asy 0 0 kissui scc3 256 256 9600   # Attach SCC channel 4 in 9600 baud
  311. #              ^^^^
  312. #              for WAMPES 921229 use here: ax25
  313. #
  314.  
  315. Example JNOS:
  316.  
  317. ############################################
  318. # JNOS device attach
  319. #
  320. attach asy scc0 0 ax25 scc0 256 256 1200
  321. attach asy scc1 0 ax25 scc1 256 256 1200
  322. attach asy scc2 0 ax25 scc2 256 256 300
  323. attach asy scc3 0 ax25 scc3 256 256 4800
  324. #
  325. #
  326.  
  327.  
  328. It allows AX.25 communication without a TNC.  Only a MODEM is
  329. needed. The parameters have the same meaning as in KISS mode.
  330. In fact, the AX.25 mode is emulating an extended KISS TNC, so
  331. the same commands can be used to set the parameters of the
  332. interface (see below).
  333.  
  334. To be able to run fullduplex using an SCC in AX.25 mode, an 
  335. external divider must be available, that divides the baudrate 
  336. generator clock available on the TRxC pin by 32, and puts the 
  337. resulting signal on the RTxC pint of the same channel of the SCC.  
  338. Such a divider is not necessary for normal CSMA packet radio 
  339. operation, but interrupt overhead is slightly reduced if you 
  340. still install it.  
  341.  
  342. 2.2 Kernel AX.25
  343. ================
  344.  
  345. Well, as said before: The driver emulates a KISS TNC, so you
  346. can simply run
  347.  
  348.     axattach -s 1200 /dev/scc0 DL1BKE
  349.  
  350. to establish the link between kernel AX.25 and z8530drv.
  351.  
  352.  
  353. 3. Adjustment and Display of parameters
  354. =======================================
  355.  
  356. 3.1 Displaying SCC Parameters:
  357. ==============================
  358.  
  359. Once a SCC channel has been attached, the parameter settings and 
  360. some statistic information can be shown using the param program:
  361.  
  362. dl1bke-u:~$ sccstat /dev/scc0
  363.  
  364. Parameters:
  365.  
  366. speed       : 1200 baud
  367. txdelay     : 36
  368. persist     : 255
  369. slottime    : 0
  370. txtail      : 8
  371. fulldup     : 1
  372. waittime    : 12
  373. mintime     : 3 sec
  374. maxkeyup    : 7 sec
  375. idletime    : 3 sec
  376. maxdefer    : 120 sec
  377. group       : 0x00
  378. txoff       : off
  379. softdcd     : on
  380. SLIP        : off
  381.  
  382. Status:
  383.  
  384. HDLC                  Z8530           Interrupts         Queues
  385. -----------------------------------------------------------------------
  386. Sent       :     273  RxOver :     0  RxInts :   125074  RxQueue :    0
  387. Received   :    1095  TxUnder:     0  TxInts :     4684  TxQueue :    0
  388. RxErrors   :    1591                  ExInts :    11776  NoSpace :    0
  389. KissErrors :       0                  SpInts :     1503
  390. Tx State   :    idle
  391.  
  392. Memory allocated:
  393.  
  394. Buffer size:     384
  395. rx buffers :       4
  396. tx buffers :       8
  397.  
  398.  
  399. The status info shown is:
  400.  
  401. Sent        - number of frames transmitted
  402. Received    - number of frames received
  403. RxErrors    - number of receive errors (CRC, ABORT)
  404. KissErrors    - number of KISS errors (should be zero...)
  405. Tx State    - status of the Tx interrupt handler: idle/busy/active/tail (2)
  406. RxOver        - number of receiver overruns
  407. TxUnder        - number of transmitter underruns     
  408. RxInts        - number of receiver interrupts
  409. TxInts        - number of transmitter interrupts
  410. EpInts        - number of receiver special condition interrupts
  411. SpInts        - number of external/status interrupts
  412. RxQueue        - number of received packets enqueued for this channel
  413. TxQueue        - number of packets enqueued for Tx
  414. NoSpace        - number of times the receiver buffer pool was found empty
  415.  
  416.  
  417. An overrun is abnormal. If lots of these occur, the product of
  418. baudrate and number of interfaces is too high for the processing
  419. power of you computer. If "Space" errors occur, specify a higher
  420. number of buffers in the "scc.h" file.
  421.  
  422.  
  423. 3.2 Setting Parameters
  424. ======================
  425.  
  426.  
  427. The setting of parameters of the emulated KISS TNC is done in the 
  428. same way in the SCC driver. You can change parameters by using
  429. the command param in NET or NOS
  430.  
  431.      param <iface> <paramname> <value>
  432.  
  433. or use the program "sccparam":
  434.  
  435.      sccparam <device> <paramname> <decimal-|hexadecimal value>
  436.  
  437. You can change the following parameters:
  438.  
  439. param        : value
  440. ------------------------
  441. speed       : 1200
  442. txdelay     : 36
  443. persist     : 255
  444. slottime    : 0
  445. txtail      : 8
  446. fulldup     : 1
  447. waittime    : 12
  448. mintime     : 3
  449. maxkeyup    : 7
  450. idletime    : 3
  451. maxdefer    : 120
  452. group       : 0x00
  453. txoff       : off
  454. softdcd     : on
  455. SLIP        : off
  456.  
  457.  
  458. The parameters have the following meaning:
  459.  
  460. speed:
  461.      The baudrate on this channel in bits/sec
  462.  
  463.      Example: sccparam /dev/scc3 speed 9600
  464.  
  465. txdelay:
  466.      The delay (in units of 10ms) after keying of the 
  467.      transmitter, until the first byte is sent. This is usually 
  468.      called "TXDELAY" in a TNC.  When 0 is specified, the driver 
  469.      will just wait until the CTS signal is asserted. This 
  470.      assumes the presence of a timer or other circuitry in the 
  471.      MODEM and/or transmitter, that asserts CTS when the 
  472.      transmitter is ready for data.
  473.      A normal value of this parameter is 30-36.
  474.  
  475.      Example: sccparam /dev/scc0 txd 20
  476.  
  477. persist:
  478.      This is the probability that the transmitter will be keyed 
  479.      when the channel is found to be free.  It is a value from 0 
  480.      to 255, and the probability is (value+1)/256.  The value 
  481.      should be somewhere near 50-60, and should be lowered when 
  482.      the channel is used more heavily.
  483.  
  484.      Example: sccparam /dev/scc2 persist 20
  485.  
  486. slottime:
  487.      This is the time between samples of the channel. It is 
  488.      expressed in units of 10ms.  About 200-300 ms (value 20-30) 
  489.      seems to be a good value.
  490.  
  491.      Example: sccparam /dev/scc0 slot 20
  492.  
  493. tail:
  494.      The time the transmitter will remain keyed after the last 
  495.      byte of a packet has been transferred to the SCC. This is 
  496.      necessary because the CRC and a flag still have to leave the 
  497.      SCC before the transmitter is keyed down. The value depends 
  498.      on the baudrate selected.  A few character times should be 
  499.      sufficient, e.g. 40ms at 1200 baud. (value 4)
  500.      The value of this parameter is in 10ms units.
  501.  
  502.      Example: sccparam /dev/scc2 4
  503.  
  504. full:
  505.      The full-duplex mode switch. This can be one of the following 
  506.      values:
  507.  
  508.      0:   The interface will operate in CSMA mode (the normal 
  509.           half-duplex packet radio operation)
  510.      1:   Fullduplex mode, i.e. the transmitter will be keyed at 
  511.           any time, without checking the received carrier.  It 
  512.           will be unkeyed when there are no packets to be sent.
  513.      2:   Like 1, but the transmitter will remain keyed, also 
  514.           when there are no packets to be sent.  Flags will be 
  515.           sent in that case, until a timeout (parameter 10) 
  516.           occurs.
  517.  
  518.      Example: sccparam /dev/scc0 fulldup off
  519.  
  520. wait:
  521.      The initial waittime before any transmit attempt, after the 
  522.      frame has been queue for transmit.  This is the length of 
  523.      the first slot in CSMA mode.  In fullduplex modes it is
  524.      set to 0 for maximum performance.
  525.      The value of this parameter is in 10ms units. 
  526.  
  527.      Example: sccparam /dev/scc1 wait 4
  528.  
  529. maxkey:
  530.      The maximal time the transmitter will be keyed to send 
  531.      packets, in seconds.  This can be useful on busy CSMA 
  532.      channels, to avoid "getting a bad reputation" when you are 
  533.      generating a lot of traffic.  After the specified time has 
  534.      elapsed, no new frame will be started. Instead, the trans-
  535.      mitter will be switched off for a specified time (parameter 
  536.      min), and then the selected algorithm for keyup will be 
  537.      started again.
  538.      The value 0 as well as "off" will disable this feature, 
  539.      and allow infinite transmission time. 
  540.  
  541.      Example: sccparam /dev/scc0 maxk 20
  542.  
  543. min:
  544.      This is the time the transmitter will be switched off when 
  545.      the maximum transmission time is exceeded.
  546.  
  547.      Example: sccparam /dev/scc3 min 10
  548.  
  549. idle
  550.      This parameter specifies the maximum idle time in fullduplex 
  551.      2 mode, in seconds.  When no frames have been sent for this 
  552.      time, the transmitter will be keyed down.  A value of 0 is
  553.      has same result as the fullduplex mode 1. This parameter
  554.      can be disabled.
  555.  
  556.      Example: sccparam /dev/scc2 idle off    # transmit forever
  557.  
  558. maxdefer
  559.      This is the maximum time (in seconds) to wait for a free channel
  560.      to send. When this timer expires the transmitter will be keyed 
  561.      IMMEDIATELY. If you love to get trouble with other users you
  562.      should set this to a very low value ;-)
  563.  
  564.      Example: sccparam /dev/scc0 maxdefer 240    # 2 minutes
  565.  
  566.  
  567. txoff:
  568.      When this parameter has the value 0, the transmission of packets
  569.      is enable. Otherwise it is disabled.
  570.  
  571.      Example: sccparam /dev/scc2 txoff on
  572.  
  573. group:
  574.      It is possible to build special radio equipment to use more than 
  575.      one frequency on the same bad, e.g. using several receivers and 
  576.      only one transmitter that can be switched between frequencies.
  577.      Also, you can connect several radios that are active on the same 
  578.      band.  In these cases, it is not possible, or not a good idea, to 
  579.      transmit on more than one frequency.  The SCC driver provides a 
  580.      method to lock transmitters on different interfaces, using the 
  581.      "param <interface> group <x>" command.  This will only work when 
  582.      you are using CSMA mode (parameter full = 0).
  583.      The number <x> must be 0 if you want no group restrictions, and 
  584.      can be computed as follows to create restricted groups:
  585.      <x> is the sum of some OCTAL numbers:
  586.  
  587.      200  This transmitter will only be keyed when all other 
  588.           transmitters in the group are off.
  589.      100  This transmitter will only be keyed when the carrier 
  590.           detect of all other interfaces in the group is off.
  591.      0xx  A byte that can be used to define different groups.  
  592.           Interfaces are in the same group, when the logical AND 
  593.           between their xx values is nonzero.
  594.  
  595.      Examples:
  596.      When 2 interfaces use group 201, their transmitters will never be 
  597.      keyed at the same time.
  598.      When 2 interfaces use group 101, the transmitters will only key 
  599.      when both channels are clear at the same time.  When group 301, 
  600.      the transmitters will not be keyed at the same time.
  601.  
  602.      Don't forget to convert the octal numbers into decimal before
  603.      you set the parameter.
  604.  
  605.      Example: (to be written)
  606.  
  607. softdcd:
  608.      use a software dcd instead of the real one... Useful for a very
  609.      slow squelch.
  610.  
  611.      Example: sccparam /dev/scc0 soft on
  612.  
  613.  
  614. slip:
  615.      use slip encoding instead of kiss
  616.  
  617.      Example: sccparam /dev/scc1 slip on
  618.  
  619.  
  620.  
  621. 4. Problems 
  622. ===========
  623.  
  624. If you have tx-problems with your BayCom USCC card please check
  625. the manufacturer of the 8530. SGS chips have a slightly
  626. different timing. Try Zilog... I have no information if this
  627. driver works with baudrates higher than 1200 baud. A solution is
  628. to write to register 8 instead to the data port, but this won't
  629. work with the ESCC chips *SIGH!*
  630.  
  631. I got reports that the driver has problems on some 386-based systems.
  632. (i.e. Amstrad) Those systems have a bogus AT bus timing which will
  633. lead to delayed answers on interrupts. You can recognize these
  634. problems by looking at the output of Sccstat for the suspected
  635. port. See if it shows under- and overruns you own such a system.
  636. Perhaps it will help if you simplify the scc_isr() function a bit.
  637. You'll find a slightly faster version in the files scc_isr_intack
  638. or scc_isr_novec.
  639.  
  640.  
  641. Delayed processing of received data: This depends on
  642.  
  643. - the kernel version
  644.  
  645. - kernel profiling compiled or not
  646.  
  647. - the rather slow receiver in tty_io.c
  648.  
  649. - a high interrupt load
  650.  
  651. - a high load of the machine --- running X, Xmorph, XV and Povray,
  652.   while compiling the kernel... hmm ... even with 32 MB RAM ...  ;-)
  653.  
  654. - NET's speed itself.
  655.  
  656.  
  657. Kernel panics: please read to /linux/README and find out if it
  658. really occurred within the scc driver.
  659.  
  660. If you can't solve a problem, send me
  661.  
  662. - a description of the problem,
  663. - information on your hardware (computer system, scc board, modem)
  664. - your kernel version
  665. - the output of sccstat /dev/scc# ("#" is the No. of the channel)
  666. - the settings of "speed", "clock" and "mode" for that channel
  667.   in /etc/z8530drv.rc
  668. - your scc_config.h
  669.  
  670.  
  671. And always remember: 
  672. The 1.1.* kernel series is for alpha tests -- use at your own risk ;-)
  673. The 1.2.* series should run reliable. This driver perhaps NOT!
  674. The 1.3.* kernel series is for alpha tests again... you get the idea!
  675.  
  676.  
  677. 3. DRSI Boards
  678. ==============
  679.  
  680. I still can't test the DRSI board, but this configuration derived from
  681. the PE1CHL SCC driver configuration should work:
  682.  
  683. An example of scc_config.h for 
  684.  
  685. One DRSI board installed:
  686. =========================
  687.  
  688. /* gencfg 1 0x300 0x10 2 0 1 0 7 4915200 */
  689.  
  690. /* file generated by $Id: gencfg.c,v 1.2 1994/11/29 21:42:24 JReuter Exp JReuter $ */
  691.  
  692. #include <linux/scc.h>
  693.  
  694. int     Nchips         = 1;
  695. io_port Vector_Latch = 0x0;
  696. int     Ivec         = 7;
  697. long    Clock         = 4915200;
  698. char    Board         = PA0HZP;
  699. int    Option         = 0;
  700. io_port Special_Port = 0x0;
  701.  
  702. io_port SCC_ctrl[MAXSCC * 2] =
  703. {0x302, 0x300, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0};
  704.  
  705. io_port SCC_data[MAXSCC * 2] =
  706. {0x303, 0x301, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0};
  707.  
  708. /* set to '1' if you have and want ESCC chip (8580/85180/85280) support */
  709.  
  710. /*                          Chip    */
  711. /*                            ========       */
  712. int SCC_Enhanced[MAXSCC] =    {0,    /* ...one...    */
  713.                  0,      /* ...two...    */
  714.                  0,      /* ...three...    */
  715.                  0};    /* ...four...    */
  716.  
  717. #define VERBOSE_BOOTMSG 1
  718. #undef  SCC_DELAY        /* perhaps a 486DX2 is a *bit* too fast */
  719. #undef  SCC_LDELAY        /* slow it even a bit more down */
  720. #undef  DONT_CHECK        /* don't look if the SCCs you specified are available */
  721.  
  722.  
  723.  
  724. Two boards installed:
  725. =====================
  726.  
  727. /* file generated by $Id: gencfg.c,v 1.2 1994/11/29 21:42:24 JReuter Exp JReuter $ */
  728.  
  729. #include <linux/scc.h>
  730.  
  731. int     Nchips         = 2;
  732. io_port Vector_Latch = 0x0;
  733. int     Ivec         = 7;
  734. long    Clock         = 4915200;
  735. char    Board         = PA0HZP;
  736. int    Option         = 0;
  737. io_port Special_Port = 0x0;
  738.  
  739. io_port SCC_ctrl[MAXSCC * 2] =
  740. {0x302, 0x300, 0x312, 0x310, 0x0, 0x0, 0x0, 0x0};
  741.  
  742. io_port SCC_data[MAXSCC * 2] =
  743. {0x303, 0x301, 0x313, 0x311, 0x0, 0x0, 0x0, 0x0};
  744.  
  745. /* set to '1' if you have and want ESCC chip (8580/85180/85280) support */
  746.  
  747. /*                          Chip    */
  748. /*                            ========       */
  749. int SCC_Enhanced[MAXSCC] =    {0,    /* ...one...    */
  750.                  0,      /* ...two...    */
  751.                  0,      /* ...three...    */
  752.                  0};    /* ...four...    */
  753.  
  754. #define VERBOSE_BOOTMSG 1
  755. #undef  SCC_DELAY        /* perhaps a 486DX2 is a *bit* too fast */
  756. #undef  SCC_LDELAY        /* slow it even a bit more down */
  757. #undef  DONT_CHECK        /* don't look if the SCCs you specified are available */
  758.  
  759.  
  760. *****************
  761.  
  762. You  m u s t  use "clock dpll" in /etc/z8530drv.rc for operation, 
  763. the on-board baudrate generator is not supported.
  764.  
  765. *****************
  766. (mni tnx to Mike Bilow)
  767.  
  768.  
  769. 4. Thor RLC100
  770. ==============
  771.  
  772. Mysteriously this board seems not to work with the driver. Anyone
  773. got it up-and-running?
  774.  
  775.  
  776. Many thanks to Linus Torvalds and Alan Cox for including the driver
  777. in the Linux standard distribution and their support.
  778.  
  779. Joerg Reuter    ampr-net: dl1bke@db0pra.ampr.org
  780.         WWW     : http://www.rat.de/jr
  781.         Internet: jreuter@poboxes.com
  782.