diff options
Diffstat (limited to 'drivers/char/README.scc')
| -rw-r--r-- | drivers/char/README.scc | 933 |
1 files changed, 933 insertions, 0 deletions
diff --git a/drivers/char/README.scc b/drivers/char/README.scc new file mode 100644 index 000000000..c48c33c23 --- /dev/null +++ b/drivers/char/README.scc @@ -0,0 +1,933 @@ +This is a subset of the documentation. To use this driver you MUST have the +full package from: + +Internet: +========= + +ftp.ucsd.edu:/hamradio/packet/tcpip/incoming/z8530drv-1.8.dl1bke.tar.gz + +and various mirrors (i.e. nic.switch.ch) + +AX.25 BBS +========= + +UNIX @ DB0ACH.#NRW.DEU.EU, subject: Z8530D18.Pxx/Pyy + +(AX.25 call: DB0ACH-8) + +and various BBS that received the file through AUTO7P or 7PSERV +with the filename Z8530D18.TGZ + + +--------------------------------------------------------------------------- + +!! Version 1.8 +!! +!! Deutscher Text siehe scc_ger.doc +!! +!! perhaps somebody could correct the English documentation (grammar, +!! spelling)? +!! +!! BTW: REAL programmers don't document... +!! + + + SCC.C - Linux driver for Z8530 based HDLC cards for AX.25 + + ******************************************************************** + + (c) 1994 by Joerg Reuter DL1BKE + + portions (c) 1994 Hans Alblas PE1AYX + and (c) 1993 Guido ten Dolle PE1NNZ + + for the complete copyright notice see >> Copying.Z8530DRV << + + ******************************************************************** + + +0. Installation of the package +============================== + +Run SCC-Install. If one (or more) of the patches fails PLEASE consult +chapter 2 (and READ IT of course!) + + + +1. Initialization and attachment of the channels +================================================ + +To use the driver, 3 steps must be performed: + + 1. Global initialization of the driver in the kernel + 2. Setup of parameters with sccinit + 2. Attachment of each channel in the packet software + +The global initialization is needed to reset all SCCs and to +install a common interrupt handler. Also, the hardware addresses +of the chips are defined in this step. In the second step, each +channel is set up for the intended use. + + + +1.1. Initialization +=================== + +Initialization of the hardware is performed by setting the defines and +variables in the file "/linux/drivers/char/scc_config.h". You can change +a number of parameters. + + + +################################################################################################ +# For OptoSCC card e.g: +# + +int Nchips = 2 ; /* number of chips */ +io_port Vector_Latch = 0x168 ; /* addr. of INTACK-Latch (0 for poll mode) +*/ +int Ivec = 9 ; /* interrupt vector */ +long Clock = 4915200 ; /* frequency of the scc clock */ +char Pclk = 1 ; /* use PCLK (1) or RTxC (0) */ +char Board = PA0HZP ; /* what type of SCC card do you use? */ +int Option = 0 ; /* command for extra hardware */ +io_port Special_Port = 0 ; /* port address for special hardware */ + /* (for EAGLE, PC100, PRIMUS, DRSI) */ + + /* ^ never remove the semicolon !! */ + + +/* Channel A B Chip */ +/* ============ ======== */ +/* Control ports: */ + +io_port SCC_ctrl[MAXSCC * 2] = {0x152, 0x150, /* ...one... */ + 0x156, 0x154, /* ...two... */ + 0, 0, /* ...three... */ + 0, 0}; /* ...four... */ + + +/* Data ports: */ + +io_port SCC_data[MAXSCC * 2] = {0x153, 0x151, /* ...one... */ + 0x157, 0x155, /* ...two... */ + 0, 0, /* ...three... */ + 0, 0}; /* ...four... */ + + +/* set to '1' if you have and want ESCC chip (8580/85180/85280) support */ + +/* Chip */ +/* ======== */ +int SCC_Enhanced[MAXSCC] = {0, /* ...one... */ + 0, /* ...two... */ + 0, /* ...three... */ + 0}; /* ...four... */ + +/* some useful #defines. You might need them or not */ + +#define VERBOSE_BOOTMSG 1 +#undef SCC_DELAY /* perhaps a 486DX2 is a *bit* too fast */ +#undef SCC_LDELAY /* slow it even a bit more down */ +#undef DONT_CHECK /* don't look if the SCCs you specified are available */ + + +/*********** END OF CONFIGURATION PARAMETERS ********************************************/ + + + + +################################################################################################ +# For Baycom (U)SCC card e.g: +# + +int Nchips = 2 ; /* number of chips */ +io_port Vector_Latch = 0 ; /* addr. of INTACK-Latch (0 for poll mode) */ +int Ivec = 7 ; /* interrupt vector */ +long Clock = 4915200 ; /* frequency of the scc clock */ +char Board = BAYCOM ; /* what type of SCC card do you use? */ +int Option = 0 ; /* command for extra hardware */ +io_port Special_Port = 0 ; /* port address for special hardware */ + /* (for EAGLE, PC100, PRIMUS, DRSI) */ + + /* ^ never remove the semicolon !! */ + + + +/* Channel A B Chip */ +/* ============ ======== */ +/* Control ports: */ + +io_port SCC_ctrl[MAXSCC * 2] = {0x304, 0x305, /* ...one... */ + 0x306, 0x307, /* ...two... */ + 0, 0, /* ...three... */ + 0, 0}; /* ...four... */ + +/* Data ports: */ + +io_port SCC_data[MAXSCC * 2] = {0x300, 0x301, /* ...one... */ + 0x302, 0x303, /* ...two... */ + 0, 0, /* ...three... */ + 0, 0}; /* ...four... */ + + +/* set to '1' if you have and want ESCC chip (8580/85180/85280) support */ + +/* Chip */ +/* ======== */ +int SCC_Enhanced[MAXSCC] = {0, /* ...one... */ + 0, /* ...two... */ + 0, /* ...three... */ + 0}; /* ...four... */ + +/* some useful #defines. You might need them or not */ + +#define VERBOSE_BOOTMSG 1 +#undef SCC_DELAY /* perhaps a 486DX2 is a *bit* too fast */ +#undef SCC_LDELAY /* slow it even a bit more down */ +#undef DONT_CHECK /* don't look if the SCCs you specified are available */ + +After you changed a parameter you have to recompile a new kernel image file. + +The channel number ranges from 0 to (2 * Nchips) - 1, +where Nchips is the number of chips. + +The crystal clock is specified as 4.9152 MHz. Other frequencies +can be used, and this parameter should be adjusted accordingly. + + +You can define your scc type with Board + + SCC type value + --------------------------------- + PA0HZP SCC card PA0HZP + EAGLE card EAGLE + PC100 card PC100 + PRIMUS-PC (DG9BL) card PRIMUS + BayCom (U)SCC card BAYCOM + + +NOTE: +===== + +If you only know the parameters for the PE1CHL driver for DOS, +run gencfg. It will generate the correct port addresses (I hope). +Its parameters are exactly the same as the ones you use with +the "attach scc" command in net, except that the string "init" must +not appear. Example: + +gencfg 2 0x150 4 2 0 1 0x168 9 4915200 + +will print a short form of scc_config.h for the OptoSCC to stdout. +("short" <=> few comments). + +gencfg 2 0x300 2 4 5 -4 0 7 4915200 0x10 + +does the same for the BayCom USCC card. I my opinion it is much easier +to edit scc_config.h... + + +1.2 initializing the driver on bootup +===================================== + + +To setup a number parameters you must run /sbin/sccinit from one +of your rc.*-files. This has to be done BEFORE the start of +NET or the ax25attach. Sccinit reads the file /etc/z8530drv.rc +and sets the MODEM and KISS parameters. A sample file is +delivered with this package. Change it to your needs: + +Each channel definition is divided into three sections. An +example for /dev/sc1: + +# DEVICE + +device /dev/sc1 # the device for the following params + +# MODEM + +speed 1200 # the default baudrate +clock dpll # clock source: + # dpll = normal halfduplex operation + # external = MODEM provides own Rx/Tx clock + # divider = use fullduplex divider if + # installed (1) +mode nrzi # HDLC encoding mode + # nrzi = 1k2 MODEM, G3RUH 9k6 MODEM + # nrz = DF9IC 9k6 MODEM +# KISS (Layer 1) + +txdelay 36 # (see chapter 1.4) +persist 64 +slot 8 +tail 8 +fulldup 0 +wait 12 +min 3 +maxkey 7 +idle 3 +maxdef 120 +group 0 +txoff off +softdcd on +slip off + +The order WITHIN these sections is unimportant. The order OF these +sections IS important. The MODEM parameters are set with the first +recognized KISS paramer... + +Please note that you can initialize the board only once after boot. +You can change all paramters but "mode" and "clock" later with the +Sccparam program or through KISS. Just to avoid securety holes... + +(1) this divider is usually mounted on the SCC-PBC (PA0HZP) or not + present at all (BayCom). It feeds back the output of the DPLL + (digital pll) as transmit clock. Using this mode without a divider + installed will normally result in keying the transceiver until + maxkey expires --- of course without sending anything (useful). + + +1.3. Attach commands +==================== + +When the linux has startup, the SCC driver has been initialized, +you can attach the channels in your packet software. This is done +by open the scc devices by using the attach asy command. +The SCC-drivers emulates the scc devices as serial asy ports, +this means e.g. that the baudrate can be set in the attach command. + + +Example Wampes: + +############################################################################################# +# Wampes device attach +# NOTE: Interfacename and the device must be the same!! +# Usage: attach asy 0 0 slip|vjslip|ax25ui|ax25i|nrs|kissui <label> 0 <mtu> <speed> [ip_addr] +# +attach asy 0 0 kissi sc1 256 256 1200 # Attach SCC channel 1 in 1200 baud +attach asy 0 0 kissi sc2 256 256 1200 # Attach SCC channel 2 in 1200 baud +attach asy 0 0 kissui sc3 256 256 38400 # Attach SCC channel 3 in 38400 baud +attach asy 0 0 kissui sc4 256 256 9600 # Attach SCC channel 4 in 9600 baud +# ^ +# for WAMPES 921229 use here: ax25 +# + +Example JNOS: + +############################################ +# JNOS device attach +# +#attach asy sc1 0 ax25 sc1 256 256 1200 +#attach asy sc2 0 ax25 sc2 256 256 1200 +#attach asy sc3 0 ax25 sc3 256 256 300 +#attach asy sc4 0 ax25 sc4 256 256 4800 +# +# + + +It allows AX.25 communication without a TNC. Only a MODEM is +needed. The parameters have the same meaning as in KISS mode. +In fact, the AX.25 mode is emulating an extended KISS TNC, so +the same commands can be used to set the parameters of the +interface (see below). + +To be able to run fullduplex using an SCC in AX.25 mode, an +external divider must be available, that divides the baudrate +generator clock available on the TRxC pin by 32, and puts the +resulting signal on the RTxC pint of the same channel of the SCC. +Such a divider is not necessary for normal CSMA packet radio +operation, but interrupt overhead is slightly reduced if you +still install it. + + + +1.4. Displaying SCC Parameters: +=============================== + +Once a SCC channel has been attached, the parameter settings and +some statistic information can be shown using the param program: + +dl1bke-u:~$ sccstat /dev/sc1 + +Parameters: + +speed : 1200 baud +txdelay : 36 +persist : 255 +slottime : 0 +txtail : 8 +fulldup : 1 +waittime : 12 +mintime : 3 sec +maxkeyup : 7 sec +idletime : 3 sec +maxdefer : 120 sec +group : 0x00 +txoff : off +softdcd : on +SLIP : off + +Status: + +HDLC Z8530 Interrupts Queues +----------------------------------------------------------------------- +Sent : 273 RxOver : 0 RxInts : 125074 RxQueue : 0 +Received : 1095 TxUnder: 0 TxInts : 4684 TxQueue : 0 +RxErrors : 1591 ExInts : 11776 +KissErrors : 0 SpInts : 1503 NoSpace : 0 +Tx State : idle + +Memory allocated: + +Total : 1 +RxAlloc: 0 +TxAlloc: 1 + + +The status info shown is: + +Sent - number of frames transmitted +Received - number of frames received +RxErrors - number of receive errors (CRC, ABORT) +KissErrors - number of KISS errors (should be zero...) +Tx State - status of the Tx interrupt handler: idle/busy/active/tail (2) +RxOver - number of receiver overruns +TxUnder - number of transmitter underruns +RxInts - number of receiver interrupts +TxInts - number of transmitter interrupts +EpInts - number of receiver special condition interrupts +SpInts - number of external/status interrupts +RxQueue - number of received packets enqueued for this channel +TxQueue - number of packets enqueued for Tx +NoSpace - number of times the receiver buffer pool was found empty + + +An overrun is abnormal. If lots of these occur, the product of +baudrate and number of interfaces is too high for the processing +power of you computer. If "Space" errors occur, specify a higher +number of buffers in the "scc.h" file. + + +1.5 Setting Parameters +====================== + + +The setting of parameters of the emulated KISS TNC is done in the +same way in the SCC driver. You can change parameters by using +the command param in NET or NOS + + param <iface> <paramname> <value> + +or use the program "sccparam": + + sccparam <device> <paramname> <decimal-|hexadecimal value> + +You can change the following parameters: + +param : value +------------------------ +speed : 1200 +txdelay : 36 +persist : 255 +slottime : 0 +txtail : 8 +fulldup : 1 +waittime : 12 +mintime : 3 +maxkeyup : 7 +idletime : 3 +maxdefer : 120 +group : 0x00 +txoff : off +softdcd : on +SLIP : off + + +The parameters have the following meaning: + +speed: + The baudrate on this channel in bits/sec + + Example: sccparam /dev/sc4 speed 9600 + +txdelay: + The delay (in units of 10ms) after keying of the + transmitter, until the first byte is sent. This is usually + called "TXDELAY" in a TNC. When 0 is specified, the driver + will just wait until the CTS signal is asserted. This + assumes the presence of a timer or other circuitry in the + MODEM and/or transmitter, that asserts CTS when the + transmitter is ready for data. + A normal value of this parameter is 30-36. + + Example: sccparam /dev/sc1 txd 20 + +persist: + This is the probability that the transmitter will be keyed + when the channel is found to be free. It is a value from 0 + to 255, and the probability is (value+1)/256. The value + should be somewhere near 50-60, and should be lowered when + the channel is used more heavily. + + Example: sccparam /dev/sc3 persist 20 + +slottime: + This is the time between samples of the channel. It is + expressed in units of 10ms. About 200-300 ms (value 20-30) + seems to be a good value. + + Example: sccparam /dev/sc1 slot 20 + +tail: + The time the transmitter will remain keyed after the last + byte of a packet has been transferred to the SCC. This is + necessary because the CRC and a flag still have to leave the + SCC before the transmitter is keyed down. The value depends + on the baudrate selected. A few character times should be + sufficient, e.g. 40ms at 1200 baud. (value 4) + The value of this parameter is in 10ms units. + + Example: sccparam /dev/sc3 4 + +full: + The full-duplex mode switch. This can be one of the folowing + values: + + 0: The interface will operate in CSMA mode (the normal + half-duplex packet radio operation) + 1: Fullduplex mode, i.e. the transmitter will be keyed at + any time, without checking the received carrier. It + will be unkeyed when there are no packets to be sent. + 2: Like 1, but the transmitter will remain keyed, also + when there are no packets to be sent. Flags will be + sent in that case, until a timeout (parameter 10) + occurs. + + Example: sccparam /dev/sc1 fulldup off + +wait: + The initial waittime before any transmit attempt, after the + frame has been queue for transmit. This is the length of + the first slot in CSMA mode. In fullduplex modes it is + set to 0 for maximum performance. + The value of this parameter is in 10ms units. + + Example: sccparam /dev/sc2 wait 4 + +maxkey: + The maximal time the transmitter will be keyed to send + packets, in seconds. This can be useful on busy CSMA + channels, to avoid "getting a bad reputation" when you are + generating a lot of traffic. After the specified time has + elapsed, no new frame will be started. Instead, the trans- + mitter will be switched off for a specified time (parameter + min), and then the selected algorithm for keyup will be + started again. + The value 0 as well as "off" will disable this feature, + and allow infinite transmission time. + + Example: sccparam /dev/sc1 maxk 20 + +min: + This is the time the transmitter will be switched off when + the maximum transmission time is exceeded. + + Example: sccparam /dev/sc4 min 10 + +idle + This parameter specifies the maximum idle time in fullduplex + 2 mode, in seconds. When no frames have been sent for this + time, the transmitter will be keyed down. A value of 0 is + has same result as the fullduplex mode 1. This parameter + can be disabled. + + Example: sccparam /dev/sc3 idle off # transmit forever + +maxdefer + This is the maximum time (in seconds) to wait for a free channel + to send. When this timer expires the transmitter will be keyed + IMMEDIATLY. If you love to get trouble with other users you + should set this to a very low value ;-) + + Example: sccparam /dev/sc1 maxdefer 240 # 2 minutes + + +txoff: + When this parameter has the value 0, the transmission of packets + is enable. Otherwise it is disabled. + + Example: sccparam /dev/sc3 txoff on + +group: + It is possible to build special radio equipment to use more than + one frequency on the same bad, e.g. using several receivers and + only one transmitter that can be switched between frequencies. + Also, you can connect several radios that are active on the same + band. In these cases, it is not possible, or not a good idea, to + transmit on more than one frequency. The SCC driver provides a + method to lock transmitters on different interfaces, using the + "param <interface> group <x>" command. This will only work when + you are using CSMA mode (parameter full = 0). + The number <x> must be 0 if you want no group restrictions, and + can be computed as follows to create restricted groups: + <x> is the sum of some OCTAL numbers: + + 200 This transmitter will only be keyed when all other + transmitters in the group are off. + 100 This transmitter will only be keyed when the carrier + detect of all other interfaces in the group is off. + 0xx A byte that can be used to define different groups. + Interfaces are in the same group, when the logical AND + between their xx values is nonzero. + + Examples: + When 2 interfaces use group 201, their transmitters will never be + keyed at the same time. + When 2 interfaces use group 101, the transmitters will only key + when both channels are clear at the same time. When group 301, + the transmitters will not be keyed at the same time. + + Don't forget to convert the octal numbers into decimal before + you set the parameter. + + Example: (to be written) + +softdcd: + use a software dcd instead of the real one... Useful for a very + slow squelch. + + Example: sccparam /dev/sc1 soft on + + +slip: + use slip encoding instead of kiss + + Example: sccparam /dev/sc2 slip on + + + +2. Problems +=========== + +We are poking around in somebody else's code, so everything may change +from one patchlevel to another... If the patches fail, try the +following: + +2.1 /linux/drivers/char/Makefile +================================ + +Add "scc.o" to the definition of OBJS and "scc.c" to SRCS + + +2.2 /linux/include/linux/tty_driver.h +===================================== + +add the following DEFINE: + +#define TTY_DRIVER_TYPE_SCC 0x0005 + + +2.3 /linux/drivers/char/tty_io.c +================================ + +in tty_init() add the line + + kmem_start=scc_init(kmem_start); + +just before "return kmem_start". + +2.4 /linux/arch/i386/config.in +============================== + +somewhere in that file add: + + comment 'Z8530 SCC driver for Amateur Packet Radio' + bool 'KISS emulator for Z8530 based HDLC cards' CONFIG_SCC y + comment '' + + + +2.5 Other problems +================== + +If you have tx-problems with your BayCom USCC card please check +the manufacturer of the 8530. SGS chips have a slightly +different timing. Try Zilog... I have no information if this +driver works with baudrates higher than 1200 baud. A solution is +to write to register 8 instead to the data port, but this won't +work with the ESCC chips *SIGH!* + +I got reports that the driver has problems on some 386-based systems. +(i.e. Amstrad) Those systems have a bogus AT bus timing which will +lead to delayed answers on interrupts. You can recognize these +problems by looking at the output of Sccstat for the suspected +port. See if it shows under- and overruns you own such a system. +Perhaps it will help if you simplify the scc_isr() function a bit. +You'll find a slightly faster version in the files scc_isr_intack +or scc_isr_novec. + + +Delayed processing of received data: This depends on + +- the kernel version + +- kernel profiling compiled or not + +- the rather slow receiver in tty_io.c + +- a high interrupt load + +- a high load of the maching --- running X, Xmorph, XV and Povray, + while compiling the kernel... hmm ... even with 32 MB RAM ... ;-) + +- NET's speed itself. + + +Kernel panics (based on excerpts from /linux/README) + + +- if a bug results in a message like + + unable to handle kernel paging request at address C0000010 + Oops: 0002 + EIP: 0010:XXXXXXXX + eax: xxxxxxxx ebx: xxxxxxxx ecx: xxxxxxxx edx: xxxxxxxx + esi: xxxxxxxx edi: xxxxxxxx ebp: xxxxxxxx + ds: xxxx es: xxxx fs: xxxx gs: xxxx + Pid: xx, process nr: xx + xx xx xx xx xx xx xx xx xx xx + + or similar kernel debugging information on your screen or in your + system log, please duplicate it *exactly*. The dump may look + incomprehensible to you, but it does contain information that may + help debugging the problem. The text above the dump is also + important: it tells something about why the kernel dumped code (in + the above example it's due to a bad kernel pointer) + +- in debugging dumps like the above, please look up what the EIP value + means. The hex value as such doesn't help me or anybody else very much: + it will depend on your particular kernel setup. What you should do is + take the hex value from the EIP line (ignore the "0010:"), and look it up + in the kernel namelist to see which kernel function contains the offending + address. + + To find out the kernel function name, you'll need to + + less /linux/System.map + + This will give you a list of kernel addresses sorted in ascending + order, from which it is simple to find the function that contains the + offending address. Note that the address given by the kernel + debugging messages will not necessarily match exactly with the + function addresses (in fact, that is very unlikely), so you can't + just 'grep' the list: the list will, however, give you the starting + point of each kernel function, so by looking for the function that + has a starting address lower than the one you are searching for but + is followed by a function with a higher address you will find the one + you want. In fact, it may be [IS!] a good idea to include a bit of + "context" in your problem report, giving a few lines around the + interesting one. + + I included a small program which does this for you. Just call + + grep_eip /linux/System.map address + + for example: grep_eip /linux/System.map 182f98 + +- alternately, you can use gdb on a running kernel. (read-only; i.e. you + cannot change values or set break points.) To do this, first compile the + kernel with -g; edit arch/i386/Makefile appropriately, then do a "make + clean". You'll also need to enable CONFIG_PROC_FS (via "make config"). + + After you've rebooted with the new kernel, do "gdb vmlinux /proc/kcore". + You can now use all the usual gdb commands. The command to look up the + point where your system crashed is "l *0xXXXXXXXX". (Replace the XXXes + with the EIP value.) + + gdb'ing a non-running kernel currently fails because gdb (wrongly) + disregards the starting offset for which the kernel is compiled. + + + +If you can't solve a problem, send me + +- a description of the problem, +- information on your hardware (computer system, scc board, modem) +- your kernel version +- the output of sccstat /dev/sc# ("#" is the No. of the channel) +- the settings of "speed", "clock" and "mode" for that channel + in /etc/z8530drv.rc +- your scc_config.h + + +And always remember: +The 1.1.* kernel series is for alpha tests -- use at your own risk ;-) +The 1.2.* series should run reliable. This driver perhaps NOT! + +------------ + +Example scc_config.h + +#include <linux/scc.h> + +/********* CONFIGURATION PARAMATERES; PLEASE CHANGE THIS TO YOUR OWN SITUATION **********/ + +/* SCC hardware parameters */ + +/* use the following board types: + * + * PA0HZP OptoSCC (PA0HZP) + * EAGLE EAGLE + * PC100 PC100 + * PRIMUS PRIMUS-PC (DG9BL) + * DRSI DRSI PC*Packet + * BAYCOM BayCom (U)SCC + * + */ + +int Nchips = 2 ; /* number of chips */ +io_port Vector_Latch = 0 ; /* addr. of INTACK-Latch (0 for poll mode) */ +int Ivec = 7 ; /* interrupt vector */ +long Clock = 4915200 ; /* frequency of the scc clock */ +char Board = BAYCOM ; /* what type of SCC card do you use? */ +int Option = 0 ; /* command for extra hardware */ +io_port Special_Port = 0 ; /* port address for special hardware */ + /* (for EAGLE, PC100, PRIMUS, DRSI) */ + + /* ^ never remove the semicolon !! */ + + + +/* Channel A B Chip */ +/* ============ ======== */ +/* Control ports: */ + +io_port SCC_ctrl[MAXSCC * 2] = {0x304, 0x305, /* ...one... */ + 0x306, 0x307, /* ...two... */ + 0, 0, /* ...three... */ + 0, 0}; /* ...four... */ + +/* Data ports: */ + +io_port SCC_data[MAXSCC * 2] = {0x300, 0x301, /* ...one... */ + 0x302, 0x303, /* ...two... */ + 0, 0, /* ...three... */ + 0, 0}; /* ...four... */ + + +/* set to '1' if you have and want ESCC chip (8580/85180/85280) support */ + +/* Chip */ +/* ======== */ +int SCC_Enhanced[MAXSCC] = {0, /* ...one... */ + 0, /* ...two... */ + 0, /* ...three... */ + 0}; /* ...four... */ + +/* some useful #defines. You might need them or not */ + +#define VERBOSE_BOOTMSG 1 +#undef SCC_DELAY /* perhaps a 486DX2 is a *bit* too fast */ +#undef SCC_LDELAY /* slow it even a bit more down */ +#undef DONT_CHECK /* don't look if the SCCs you specified are available */ + + +/* The external clocking, nrz and fullduplex divider configuration is gone */ +/* you can set these parameters in /etc/z8530drv.rc and initialize the */ +/* driver with sccinit */ + +--------- + +I still can't test the DRSI board, but this configuration derived from +the PE1CHL SCC driver configuration should work: + +An example of scc_config.h for + +One DRSI board installed: +========================= + +/* gencfg 1 0x300 0x10 2 0 1 0 7 4915200 */ + +/* file generated by $Id: gencfg.c,v 1.2 1994/11/29 21:42:24 JReuter Exp JReuter $ */ + +#include <linux/scc.h> + +int Nchips = 1; +io_port Vector_Latch = 0x0; +int Ivec = 7; +long Clock = 4915200; +char Board = PA0HZP; +int Option = 0; +io_port Special_Port = 0x0; + +io_port SCC_ctrl[MAXSCC * 2] = +{0x302, 0x300, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}; + +io_port SCC_data[MAXSCC * 2] = +{0x303, 0x301, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}; + +/* set to '1' if you have and want ESCC chip (8580/85180/85280) support */ + +/* Chip */ +/* ======== */ +int SCC_Enhanced[MAXSCC] = {0, /* ...one... */ + 0, /* ...two... */ + 0, /* ...three... */ + 0}; /* ...four... */ + +#define VERBOSE_BOOTMSG 1 +#undef SCC_DELAY /* perhaps a 486DX2 is a *bit* too fast */ +#undef SCC_LDELAY /* slow it even a bit more down */ +#undef DONT_CHECK /* don't look if the SCCs you specified are available */ + + + +Two boards installed: +===================== + +/* file generated by $Id: gencfg.c,v 1.2 1994/11/29 21:42:24 JReuter Exp JReuter $ */ + +#include <linux/scc.h> + +int Nchips = 2; +io_port Vector_Latch = 0x0; +int Ivec = 7; +long Clock = 4915200; +char Board = PA0HZP; +int Option = 0; +io_port Special_Port = 0x0; + +io_port SCC_ctrl[MAXSCC * 2] = +{0x302, 0x300, 0x312, 0x310, 0x0, 0x0, 0x0, 0x0}; + +io_port SCC_data[MAXSCC * 2] = +{0x303, 0x301, 0x313, 0x311, 0x0, 0x0, 0x0, 0x0}; + +/* set to '1' if you have and want ESCC chip (8580/85180/85280) support */ + +/* Chip */ +/* ======== */ +int SCC_Enhanced[MAXSCC] = {0, /* ...one... */ + 0, /* ...two... */ + 0, /* ...three... */ + 0}; /* ...four... */ + +#define VERBOSE_BOOTMSG 1 +#undef SCC_DELAY /* perhaps a 486DX2 is a *bit* too fast */ +#undef SCC_LDELAY /* slow it even a bit more down */ +#undef DONT_CHECK /* don't look if the SCCs you specified are available */ + + + + + +***************** + +You m u s t use "clock dpll" in /etc/z8530drv.rc for operation, +the on-board baudrate generator is not supported. + +***************** + + +(mni tnx to Mike Bilow) + |