mirror of
				https://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson
				synced 2025-10-31 20:42:39 +00:00 
			
		
		
		
	 53cb47268e
			
		
	
	
		53cb47268e
		
	
	
	
	
		
			
			This patch fixes typos in various Documentation txts. The patch addresses some words starting with the letter 'S'. Signed-off-by: Matt LaPlante <kernel1@cyberdogtech.com> Acked-by: Alan Cox <alan@redhat.com> Acked-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: Adrian Bunk <bunk@stusta.de>
		
			
				
	
	
		
			370 lines
		
	
	
		
			12 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
			
		
		
	
	
			370 lines
		
	
	
		
			12 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
| 
 | |
| SliceCOM adapter user's documentation - for the 0.51 driver version
 | |
| 
 | |
| Written by Bartók István <bartoki@itc.hu>
 | |
| 
 | |
| English translation: Lakatos György <gyuri@itc.hu>
 | |
| Mon Dec 11 15:28:42 CET 2000
 | |
| 
 | |
| Last modified: Wed Aug 29 17:25:37 CEST 2001
 | |
| 
 | |
| -----------------------------------------------------------------
 | |
| 
 | |
| Usage:
 | |
| 
 | |
| Compiling the kernel:
 | |
| 
 | |
| Code maturity level options
 | |
| 	[*] Prompt for development and/or incomplete code/drivers
 | |
| 
 | |
| Network device support
 | |
| 	Wan interfaces
 | |
| 		<M> MultiGate (COMX) synchronous
 | |
| 			<M> Support for MUNICH based boards: SliceCOM, PCICOM (NEW)
 | |
| 			<M> Support for HDLC and syncPPP...
 | |
| 
 | |
| 
 | |
| Loading the modules:
 | |
| 
 | |
| modprobe comx
 | |
| 
 | |
| modprobe comx-proto-ppp		# module for  Cisco-HDLC and SyncPPP protocols
 | |
| 
 | |
| modprobe comx-hw-munich		# the module logs information by the kernel
 | |
| 				# about the detected boards
 | |
| 
 | |
| 
 | |
| Configuring the board:
 | |
| 
 | |
| # This interface will use the Cisco-HDLC line protocol,
 | |
| # the timeslices assigned are 1,2 (128 KiBit line speed)
 | |
| # (the first data timeslice in the G.703 frame is no. 1)
 | |
| #
 | |
| mkdir /proc/comx/comx0.1/
 | |
| echo slicecom	>/proc/comx/comx0.1/boardtype
 | |
| echo hdlc	>/proc/comx/comx0.1/protocol
 | |
| echo 1 2	>/proc/comx/comx0.1/timeslots
 | |
| 
 | |
| 
 | |
| # This interface uses SyncPPP line protocol, the assigned 
 | |
| # is no. 3 (64 KiBit line speed)
 | |
| #
 | |
| mkdir /proc/comx/comx0.2/
 | |
| echo slicecom	>/proc/comx/comx0.2/boardtype
 | |
| echo ppp	>/proc/comx/comx0.2/protocol
 | |
| echo 3		>/proc/comx/comx0.2/timeslots
 | |
| 
 | |
| ...
 | |
| 
 | |
| ifconfig comx0.1 up
 | |
| ifconfig comx0.2 up
 | |
| 
 | |
| -----------------------------------------------------------------
 | |
| 
 | |
| The COMX interfaces use a 10 packet transmit queue by default, however WAN
 | |
| networks sometimes use bigger values (20 to 100), to utilize the line better
 | |
| by large traffic (though the line delay increases because of more packets
 | |
| join the queue).
 | |
| 
 | |
| # ifconfig comx0 txqueuelen 50
 | |
| 
 | |
| This option is only supported by the ifconfig command of the later 
 | |
| distributions, which came with 2.2 kernels, such as RedHat 6.1 or Debian 2.2.
 | |
| 
 | |
| You can download a newer netbase packet from 
 | |
| http://www.debian.org/~rcw/2.2/netbase/ for Debian 2.1, which has a new
 | |
| ifconfig. You can get further information about using 2.2 kernel with
 | |
| Debian 2.1 from http://www.debian.org/releases/stable/running-kernel-2.2
 | |
| 
 | |
| -----------------------------------------------------------------
 | |
| 
 | |
| The SliceCom LEDs:
 | |
| 
 | |
| red	- on, if the interface is unconfigured, or it gets Remote Alarm-s
 | |
| green	- on, if the board finds frame-sync in the received signal 	
 | |
| 
 | |
| A bit more detailed:
 | |
| 
 | |
| red:	green:	meaning:
 | |
| 
 | |
| -	-	no frame-sync, no signal received, or signal SNAFU.
 | |
| -	on	"Everything is OK"
 | |
| on	on	Reception is ok, but the remote end sends Remote Alarm
 | |
| on	-	The interface is unconfigured
 | |
| 
 | |
| -----------------------------------------------------------------
 | |
| 
 | |
| A more detailed description of the hardware setting options:
 | |
| 
 | |
| The general and the protocol layer options described in the 'comx.txt' file
 | |
| apply to the SliceCom as well, I only summarize the SliceCom hardware specific
 | |
| settings below.
 | |
| 
 | |
| The '/proc/comx' configuring interface:
 | |
| 
 | |
| An interface directory should be created for every timeslot group with
 | |
| 'mkdir', e,g: 'comx0', 'comx1' etc. The timeslots can be assigned here to the
 | |
| specific interface. The Cisco-like naming convention (serial3:1 - first
 | |
| timeslot group of the 3rd. board) can't be used here, because these mean IP
 | |
| aliasing in Linux.
 | |
| 
 | |
| You can give any meaningful name to keep the configuration clear; 
 | |
| e.g: 'comx0.1', 'comx0.2', 'comx1.1', comx1.2', if you have two boards
 | |
| with two interfaces each.
 | |
| 
 | |
| Settings, which apply to the board:
 | |
| 
 | |
| Neither 'io' nor 'irq' settings required, the driver uses the resources
 | |
| given by the PCI BIOS.
 | |
| 
 | |
| comx0/boardnum	- board number of the SliceCom in the PC (using the 'natural'
 | |
| 		PCI order) as listed in '/proc/pci' or the output of the
 | |
| 	 	'lspci' command, generally the slots nearer to the motherboard
 | |
| 		PCI driver chips have the lower numbers.
 | |
| 		
 | |
| 		Default: 0 (the counting starts with 0)
 | |
| 
 | |
| Though the options below are to be set on a single interface, they apply to the
 | |
| whole board. The restriction, to use them on 'UP' interfaces, is because the 
 | |
| command sequence below could lead to unpredicable results.
 | |
| 
 | |
| 	# echo 0        >boardnum
 | |
| 	# echo internal >clock_source
 | |
| 	# echo 1        >boardnum
 | |
| 
 | |
| The sequence would set the clock source of board 0.
 | |
| 
 | |
| These settings will persist after all the interfaces are cleared, but are
 | |
| cleared when the driver module is unloaded and loaded again.
 | |
| 
 | |
| comx0/clock_source - source of the transmit clock
 | |
| 	Usage:
 | |
| 
 | |
| 	# echo line     >/proc/comx/comx0/clock_source
 | |
| 	# echo internal >/proc/comx/comx0/clock_source
 | |
| 
 | |
| 	line	- The Tx clock is being decoded if the input data stream,
 | |
| 		if no clock seen on the input, then the board will use it's
 | |
| 		own clock generator.
 | |
| 
 | |
| 	internal - The Tx clock is supplied by the builtin clock generator. 	
 | |
| 
 | |
| 	Default: line
 | |
| 
 | |
| 	Normally, the telecommunication company's end device (the HDSL
 | |
| 	modem) provides the Tx clock, that's why 'line' is the default.
 | |
| 
 | |
| comx0/framing	- Switching CRC4 off/on
 | |
| 
 | |
| 	CRC4: 16 PCM frames (The 32 64Kibit channels are multiplexed into a
 | |
| 	PCM frame, nothing to do with HDLC frames) are divided into 2x8
 | |
| 	groups, each group has a 4 bit CRC.
 | |
| 
 | |
| 	# echo crc4	>/proc/comx/comx0/framing
 | |
| 	# echo no-crc4	>/proc/comx/comx0/framing
 | |
| 
 | |
| 	Default is 'crc4', the Hungarian MATAV lines behave like this. 
 | |
| 	The traffic generally passes if this setting on both ends don't match.
 | |
| 
 | |
| comx0/linecode	- Setting the line coding
 | |
| 
 | |
| 	# echo hdb3	>/proc/comx/comx0/linecode
 | |
| 	# echo ami	>/proc/comx/comx0/linecode
 | |
| 
 | |
| 	Default a 'hdb3', MATAV lines use this.
 | |
| 	
 | |
| 	(AMI coding is rarely used with E1 lines). Frame sync may occur, if
 | |
| 	this setting doesn't match the other end's, but CRC4 and data errors
 | |
| 	will come, which will result in CRC errors on HDLC/SyncPPP level. 
 | |
| 
 | |
| comx0/reg	- direct access to the board's MUNICH (reg) and FALC (lbireg)
 | |
| comx0/lbireg	circuit's registers  
 | |
| 
 | |
| 	# echo >reg 0x04 0x0	- write 0 to register 4
 | |
| 	# echo >reg 0x104	- write the contents of register 4 with
 | |
| 				printk() to syslog
 | |
| 
 | |
| WARNING! These are only for development purposes, messing with this will
 | |
| 	result much trouble!
 | |
| 
 | |
| comx0/loopback - Places a loop to the board's G.703 signals
 | |
| 
 | |
| 	# echo none   >/proc/comx/comx0/loopback
 | |
| 	# echo local  >/proc/comx/comx0/loopback
 | |
| 	# echo remote >/proc/comx/comx0/loopback
 | |
| 
 | |
| 	none   - normal operation, no loop
 | |
| 	local  - the board receives it's own output
 | |
| 	remote - the board sends the received data to the remote side
 | |
| 
 | |
| 	Default: none
 | |
| 
 | |
| -----------------------------------------------------------------
 | |
| 
 | |
| Interface (channel group in Cisco terms) settings: 
 | |
| 
 | |
| comx0/timeslots	- which timeslots belong to the given interface
 | |
| 
 | |
| 	Setting:
 | |
| 
 | |
| 	# echo '1 5 2 6 7 8' >/proc/comx/comx0/timeslots
 | |
| 
 | |
| 	# cat /proc/comx/comx0/timeslots
 | |
| 	1 2 5 6 7 8 
 | |
| 	#
 | |
| 
 | |
| 	Finding a timeslot: 
 | |
| 
 | |
| 	# grep ' 4' /proc/comx/comx*/timeslots
 | |
| 	/proc/comx/comx0/timeslots:1 3 4 5 6
 | |
| 	#
 | |
| 
 | |
| 	The timeslots can be in any order, '1 2 3' is the same as '1 3 2'.
 | |
| 
 | |
| 	The interface has to be DOWN during the setting ('ifconfig comx0
 | |
| 	down'), but the other interfaces could operate normally.
 | |
| 
 | |
| 	The driver checks if the assigned timeslots are vacant, if not, then
 | |
| 	the setting won't be applied.
 | |
| 
 | |
| 	The timeslot values are treated as decimal numbers, not to misunderstand
 | |
| 	values of 08, 09 form.
 | |
| 
 | |
| -----------------------------------------------------------------
 | |
| 
 | |
| Checking the interface and board status:
 | |
| 
 | |
| - Lines beginning with ' ' (space) belong to the original output, the lines
 | |
| which begin with '//' are the comments.
 | |
| 
 | |
|  papaya:~$ cat /proc/comx/comx1/status
 | |
|  Interface administrative status is UP, modem status is UP, protocol is UP
 | |
|  Modem status changes: 0, Transmitter status is IDLE, tbusy: 0
 | |
|  Interface load (input): 978376 / 947808 / 951024 bits/s (5s/5m/15m)
 | |
|                (output): 978376 / 947848 / 951024 bits/s (5s/5m/15m)
 | |
|  Debug flags: none
 | |
|  RX errors: len: 22, overrun: 1, crc: 0, aborts: 0
 | |
|             buffer overrun: 0, pbuffer overrun: 0
 | |
|  TX errors: underrun: 0
 | |
|  Line keepalive (value: 10) status UP [0]
 | |
| 
 | |
| // The hardware specific part starts here:
 | |
|  Controller status:
 | |
|          No alarms
 | |
| 
 | |
| // Alarm: 
 | |
| //
 | |
| // No alarms - Everything OK
 | |
| //
 | |
| // LOS  - Loss Of Signal - No signal sensed on the input
 | |
| // AIS  - Alarm Indication Signal - The remote side sends '11111111'-s, 
 | |
| //	it tells, that there's an error condition, or it's not
 | |
| //	initialised.
 | |
| // AUXP - Auxiliary Pattern Indication - 01010101.. received.
 | |
| // LFA  - Loss of Frame Alignment - no frame sync received.
 | |
| // RRA  - Receive Remote Alarm - the remote end's OK, but signals error cond.
 | |
| // LMFA - Loss of CRC4 Multiframe Alignment - no CRC4 multiframe sync.
 | |
| // NMF  - No Multiframe alignment Found after 400 msec - no such alarm using
 | |
| //	no-crc4 or crc4 framing, see below.
 | |
| //
 | |
| // Other possible error messages:
 | |
| //
 | |
| // Transmit Line Short - the board felt, that it's output is short-circuited,
 | |
| // 	so it switched the transmission off. (The board can't definitely tell,
 | |
| //	that it's output is short-circuited.)
 | |
| 
 | |
| // Chained list of the received packets, for debug purposes:
 | |
| 
 | |
|  Rx ring:
 | |
|          rafutott: 0
 | |
|          lastcheck: 50845731, jiffies: 51314281
 | |
|          base: 017b1858
 | |
|          rx_desc_ptr: 0
 | |
|          rx_desc_ptr: 017b1858
 | |
|          hw_curr_ptr: 017b1858
 | |
|          06040000 017b1868 017b1898 c016ff00
 | |
|          06040000 017b1878 017b1e9c c016ff00
 | |
|          46040000 017b1888 017b24a0 c016ff00
 | |
|          06040000 017b1858 017b2aa4 c016ff00
 | |
| 
 | |
| // All the interfaces using the board: comx1, using the 1,2,...16 timeslots,
 | |
| // comx2, using timeslot 17, etc.
 | |
| 
 | |
|  Interfaces using this board: (channel-group, interface, timeslots)
 | |
|           0 comx1: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
 | |
|           1 comx2: 17
 | |
|           2 comx3: 18
 | |
|           3 comx4: 19
 | |
|           4 comx5: 20
 | |
|           5 comx6: 21
 | |
|           6 comx7: 22
 | |
|           7 comx8: 23
 | |
|           8 comx9: 24
 | |
|           9 comx10: 25
 | |
|          10 comx11: 26
 | |
|          11 comx12: 27
 | |
|          12 comx13: 28
 | |
|          13 comx14: 29
 | |
|          14 comx15: 30
 | |
|          15 comx16: 31
 | |
| 
 | |
| // The number of events handled by the driver during an interrupt cycle:
 | |
| 
 | |
|  Interrupt work histogram:
 | |
|  hist[ 0]:        0 hist[ 1]:        2 hist[ 2]:    18574 hist[ 3]:       79
 | |
|  hist[ 4]:       14 hist[ 5]:        1 hist[ 6]:        0 hist[ 7]:        1
 | |
|  hist[ 8]:        0 hist[ 9]:        7
 | |
| 
 | |
| // The number of packets to send in the Tx ring, when a new one arrived:
 | |
| 
 | |
|  Tx ring histogram:
 | |
|  hist[ 0]:     2329 hist[ 1]:        0 hist[ 2]:        0 hist[ 3]:        0
 | |
| 
 | |
| // The error counters of the E1 interface, according to the RFC2495,
 | |
| // (similar to the Cisco "show controllers e1" command's output:
 | |
| // http://www.cisco.com/univercd/cc/td/doc/product/software/ios11/rbook/rinterfc.htm#xtocid25669126)
 | |
| 
 | |
| Data in current interval (91 seconds elapsed):
 | |
|    9516 Line Code Violations, 65 Path Code Violations, 2 E-Bit Errors
 | |
|    0 Slip Secs, 2 Fr Loss Secs, 2 Line Err Secs, 0 Degraded Mins
 | |
|    0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 11 Unavail Secs
 | |
| Data in Interval 1 (15 minutes):
 | |
|    0 Line Code Violations, 0 Path Code Violations, 0 E-Bit Errors
 | |
|    0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
 | |
|    0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
 | |
| Data in last 4 intervals (1 hour):
 | |
|    0 Line Code Violations, 0 Path Code Violations, 0 E-Bit Errors
 | |
|    0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
 | |
|    0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
 | |
| Data in last 96 intervals (24 hours):
 | |
|    0 Line Code Violations, 0 Path Code Violations, 0 E-Bit Errors
 | |
|    0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
 | |
|    0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
 | |
| 
 | |
| -----------------------------------------------------------------
 | |
| 
 | |
| Some unique options, (may get into the driver later):
 | |
| Treat them very carefully, these can cause much trouble!
 | |
| 
 | |
| 	modified CRC-4, for improved interworking of CRC-4 and non-CRC-4
 | |
| 	devices: (see page 107 and g706 Annex B)
 | |
| 		lbireg[ 0x1b ] |= 0x08
 | |
| 		lbireg[ 0x1c ] |= 0xc0
 | |
| 
 | |
| 	- The NMF - 'No Multiframe alignment Found after 400 msec' alarm 
 | |
| 	comes into account.
 | |
| 
 | |
| 	FALC - the line driver chip.
 | |
| 	local loop - I hear my transmission back.
 | |
| 	remote loop - I echo the remote transmission back.
 | |
| 
 | |
| 	Something useful for finding errors:
 | |
| 	
 | |
| 		- local loop for timeslot 1 in the FALC chip:
 | |
| 
 | |
| 	# echo >lbireg 0x1d 0x21
 | |
| 
 | |
| 		- Switching the loop off:
 | |
| 
 | |
| 	# echo >lbireg 0x1d 0x00
 |