patch-1.3.25 linux/Documentation/networking/z8530drv.txt
Next file: linux/Makefile
Previous file: linux/Documentation/networking/arcnet.txt
Back to the patch index
Back to the overall index
- Lines: 954
- Date:
Fri Sep 8 08:02:05 1995
- Orig file:
v1.3.24/linux/Documentation/networking/z8530drv.txt
- Orig date:
Thu Jan 1 02:00:00 1970
diff -u --recursive --new-file v1.3.24/linux/Documentation/networking/z8530drv.txt linux/Documentation/networking/z8530drv.txt
@@ -0,0 +1,953 @@
+// 950824: note -- I will upload the new version 1.9 to ftp.ucsd.edu
+// as soon as possible...
+//
+// ******
+// ****** The driver has a n e w MAJOR number (34) now! ******
+// ******
+//
+// please remake /dev/sc*:
+//
+// mknod /dev/sc1 c 34 0
+// mknod /dev/sc2 c 34 1
+// mknod /dev/sc3 c 34 2
+// mknod /dev/sc4 c 34 3
+//
+// (and so on...)
+//
+// -dl1bke-
+
+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.9.dl1bke.tar.gz
+
+[
+ if you can't find it there, try:
+ .../tcpip/linux/z8530drv-1.9.dl1bke.tar.gz
+
+]
+
+and various mirrors (i.e. nic.switch.ch)
+
+AX.25 BBS
+=========
+
+UNIX @ DB0ACH.#NRW.DEU.EU, subject: Z8530D19.Pxx/Pyy
+
+(AX.25 call: DB0ACH-8)
+
+and various BBS that received the file through AUTO7P or 7PSERV
+with the filename Z8530D19.TGZ
+
+
+---------------------------------------------------------------------------
+
+
+ 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!
+The 1.3.* kernel series is for alpha tests again... you get the idea!
+
+------------
+
+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)
+
+
+...an many thanks to Linus Torvalds and Alan Cox for including the driver
+ in the LinuX standard distribution...
+
+Joerg Reuter ampr-net: dl1bke@db0pra.ampr.org
+ AX-25 : DL1BKE @ DB0ACH.#NRW.DEU.EU
+ Internet: jreuter@lykos.tng.oche.de
FUNET's LINUX-ADM group, linux-adm@nic.funet.fi
TCL-scripts by Sam Shen, slshen@lbl.gov
with Sam's (original) version of this