patch-1.3.35 linux/Documentation/networking/z8530drv.txt

• Lines: 449
• Date: Sat Oct 14 10:55:16 1995
• Orig file: v1.3.34/linux/Documentation/networking/z8530drv.txt
• Orig date: Sat Sep 9 15:26:51 1995

diff -u --recursive --new-file v1.3.34/linux/Documentation/networking/z8530drv.txt linux/Documentation/networking/z8530drv.txt
@@ -1,5 +1,5 @@
-// 950824: note -- I will upload the new version 1.9 to ftp.ucsd.edu
-//         as soon as possible... 
+// 950913: note -- I will upload the new version 1.9a to ftp.ucsd.edu
+//         as soon as possible...
 //
 // ******
 // ****** The driver has a  n e w  MAJOR number (34) now! ******
@@ -7,15 +7,25 @@
 //
 // 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
+// mknod /dev/scc0 c 34 0
+// mknod /dev/scc1 c 34 1
+// mknod /dev/scc2 c 34 2
+// mknod /dev/scc3 c 34 3
 //
 // (and so on...)
 //
+// If you want to use the old device naming scheme use:
+//
+// ln -f /dev/scc0 /dev/sc1
+// ln -f /dev/scc1 /dev/sc2
+// ln -f /dev/scc2 /dev/sc3
+// ln -f /dev/scc3 /dev/sc4
+//
+// (you get the idea...)
+//
 // -dl1bke-
 
+
 This is a subset of the documentation. To use this driver you MUST have the
 full package from:
 
@@ -252,11 +262,11 @@
 delivered with this package. Change it to your needs:
 
 Each channel definition is divided into three sections. An
-example for /dev/sc1:
+example for /dev/scc0:
 
 # DEVICE
 
-device /dev/sc1		# the device for the following params
+device /dev/scc0		# the device for the following params
 
 # MODEM
 
@@ -318,10 +328,10 @@
 # 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
+attach asy 0 0 kissi scc0 256 256 1200    # Attach SCC channel 1 in 1200 baud
+attach asy 0 0 kissi scc1 256 256 1200    # Attach SCC channel 2 in 1200 baud
+attach asy 0 0 kissui scc2 256 256 38400  # Attach SCC channel 3 in 38400 baud
+attach asy 0 0 kissui scc3 256 256 9600   # Attach SCC channel 4 in 9600 baud
 #                ^
 #                 for WAMPES 921229 use here: ax25
 #
@@ -331,10 +341,10 @@
 ############################################
 # 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
+#attach asy scc0 0 ax25 scc0 256 256 1200
+#attach asy scc1 0 ax25 scc1 256 256 1200
+#attach asy scc2 0 ax25 scc2 256 256 300
+#attach asy scc3 0 ax25 scc3 256 256 4800
 #
 #
 
@@ -361,7 +371,7 @@
 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
+dl1bke-u:~$ sccstat /dev/scc0
 
 Parameters:
 
@@ -462,7 +472,7 @@
 speed:
      The baudrate on this channel in bits/sec
 
-     Example: sccparam /dev/sc4 speed 9600
+     Example: sccparam /dev/scc3 speed 9600
 
 txdelay:
      The delay (in units of 10ms) after keying of the 
@@ -474,7 +484,7 @@
      transmitter is ready for data.
      A normal value of this parameter is 30-36.
 
-     Example: sccparam /dev/sc1 txd 20
+     Example: sccparam /dev/scc0 txd 20
 
 persist:
      This is the probability that the transmitter will be keyed 
@@ -483,14 +493,14 @@
      should be somewhere near 50-60, and should be lowered when 
      the channel is used more heavily.
 
-     Example: sccparam /dev/sc3 persist 20
+     Example: sccparam /dev/scc2 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
+     Example: sccparam /dev/scc0 slot 20
 
 tail:
      The time the transmitter will remain keyed after the last 
@@ -501,7 +511,7 @@
      sufficient, e.g. 40ms at 1200 baud. (value 4)
      The value of this parameter is in 10ms units.
 
-     Example: sccparam /dev/sc3 4
+     Example: sccparam /dev/scc2 4
 
 full:
      The full-duplex mode switch. This can be one of the folowing 
@@ -517,7 +527,7 @@
           sent in that case, until a timeout (parameter 10) 
           occurs.
 
-     Example: sccparam /dev/sc1 fulldup off
+     Example: sccparam /dev/scc0 fulldup off
 
 wait:
      The initial waittime before any transmit attempt, after the 
@@ -526,7 +536,7 @@
      set to 0 for maximum performance.
      The value of this parameter is in 10ms units. 
 
-     Example: sccparam /dev/sc2 wait 4
+     Example: sccparam /dev/scc1 wait 4
 
 maxkey:
      The maximal time the transmitter will be keyed to send 
@@ -540,13 +550,13 @@
      The value 0 as well as "off" will disable this feature, 
      and allow infinite transmission time. 
 
-     Example: sccparam /dev/sc1 maxk 20
+     Example: sccparam /dev/scc0 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
+     Example: sccparam /dev/scc3 min 10
 
 idle
      This parameter specifies the maximum idle time in fullduplex 
@@ -555,7 +565,7 @@
      has same result as the fullduplex mode 1. This parameter
      can be disabled.
 
-     Example: sccparam /dev/sc3 idle off	# transmit forever
+     Example: sccparam /dev/scc2 idle off	# transmit forever
 
 maxdefer
      This is the maximum time (in seconds) to wait for a free channel
@@ -563,14 +573,14 @@
      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
+     Example: sccparam /dev/scc0 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
+     Example: sccparam /dev/scc2 txoff on
 
 group:
      It is possible to build special radio equipment to use more than 
@@ -610,56 +620,21 @@
      use a software dcd instead of the real one... Useful for a very
      slow squelch.
 
-     Example: sccparam /dev/sc1 soft on
+     Example: sccparam /dev/scc0 soft on
 
 
 slip:
      use slip encoding instead of kiss
 
-     Example: sccparam /dev/sc2 slip on
+     Example: sccparam /dev/scc1 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
 ==================
@@ -697,78 +672,15 @@
 - 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.
-
-
+Kernel panics: please read to /linux/README and find out if it
+really occured within the scc driver.
 
 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 output of sccstat /dev/scc# ("#" is the No. of the channel)
 - the settings of "speed", "clock" and "mode" for that channel
   in /etc/z8530drv.rc
 - your scc_config.h
@@ -779,79 +691,9 @@
 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 */
-
----------
+3. DRSI Boards
+==============
 
 I still can't test the DRSI board, but this configuration derived from
 the PE1CHL SCC driver configuration should work:
@@ -933,9 +775,6 @@
 #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, 
@@ -944,9 +783,16 @@
 *****************
 (mni tnx to Mike Bilow)
 
- 
-...an many thanks to Linus Torvalds and Alan Cox for including the driver
-   in the LinuX standard distribution...
+
+4. Thor RLC100
+==============
+
+Mysteriously this board seems not to work with the driver. Anyone
+got it up-and-running?
+
+
+Many thanks to Linus Torvalds and Alan Cox for including the driver
+in the LinuX standard distribution and their support.
 
 Joerg Reuter	ampr-net: dl1bke@db0pra.ampr.org
 		AX-25   : DL1BKE @ DB0ACH.#NRW.DEU.EU