patch-1.3.25 linux/drivers/char/README.scc
Next file: linux/drivers/char/cyclades.c
Previous file: linux/drivers/block/sonycd535.c
Back to the patch index
Back to the overall index
- Lines: 968
- Date:
Fri Sep 8 08:02:05 1995
- Orig file:
v1.3.24/linux/drivers/char/README.scc
- Orig date:
Sun Sep 3 12:26:52 1995
diff -u --recursive --new-file v1.3.24/linux/drivers/char/README.scc linux/drivers/char/README.scc
@@ -1,950 +1,41 @@
// 950824: note -- I will upload the new version 1.9 to ftp.ucsd.edu
// as soon as possible...
//
-// ****** The driver has it's own MAJOR number (22) now! ******
+// ******
+// ****** The driver has a n e w MAJOR number (34) now! ******
+// ******
//
// please remake /dev/sc*:
//
-// mknod /dev/sc1 c 22 0
-// mknod /dev/sc2 c 22 1
-// mknod /dev/sc3 c 22 2
-// mknod /dev/sc4 c 22 3
+// 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:
-=========
+You will find subset of the documentation in
-ftp.ucsd.edu:/hamradio/packet/tcpip/incoming/z8530drv-1.9.dl1bke.tar.gz
+ linux/Documentation/networking/z8530drv.txt
+
+
+To use this driver you MUST have the full package from
+
+ftp.ucsd.edu:/hamradio/packet/tcpip/incoming/z8530drv-1.9a.dl1bke.tar.gz
[
if you can't find it there, try:
- .../tcpip/linux/z8530drv-1.9.dl1bke.tar.gz
+ .../tcpip/linux/z8530drv-1.9a.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...
+The package includes the utilities necessary to initialize and
+control the driver.
Joerg Reuter ampr-net: dl1bke@db0pra.ampr.org
AX-25 : DL1BKE @ DB0ACH.#NRW.DEU.EU
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