Return to DOC CVS log

Up to [Power 6/32 Unix Tahoe 4.2BSD] / cci / d / ether

Power 6/32 Unix version 1.2b

.nf

			TABLE OF CONTENTS




	1.  INTRODUCTION

	1.1. Supported Hardware

	1.2. Addresses Setting

	1.3. Pre-caution

	2.  LOADING AND EXECUTING

	3.  TEST DESCRIPTION

	3.1. Phase 1: Reset and Initialization

	3.2. Phase 2: Register Validation Test

	3.3. Phase 3: Loop 2 Mode Test

	3.4. Phase 4: Loop 3 Mode Test

	3.5. Phase 5: Loop 3 Mode, ODD NUMBER OF BITS Error Test

	3.6. Phase 6: Loop 3 Mode, CRC Error Test

	3.7. Phase 7: Loop 3 Mode, OVERRUN Error Test

	3.8. Phase 8: Loop 3 Mode, UNDERRUN Error Test

	4.  ERROR MESSAGES

	5.  APPENDICES
.fi
.bp
.nf
			APPENDICES






	A.  V/EIU Functional Block Diagram

	B.  I/O Programming Registers

	C.  A Sample Test

.fi
.bp
.nf
		V/EIU CONTROLLER DIAGNOSTIC TEST
.fi




1.  INTRODUCTION:
.sp 1
.RS
The purpose of this test is to validate the Ethernet controller board
logic during initialization and operation.  The test consists of seven (7) steps
in which every functionality is thoroughly tested and every error
detection capability of the
controller is verified.
.RE

1.1. Supported Hardware:
.sp 1
.RS
This diagnostic program can support up to two (2) Ethernet
controller boards.
.RE

1.2. Addresses Setting:
.sp 1
.RS
The following addresses must be set as intructed below before any testing
can be initiated:
.RE

.nf
	First controller's addresses setting:
	   
	   - I/O port address: 0xFF0000
	   - DPM address: 0xF80000

	Second controller's addresses setting (if any):
	   
	   - I/O port address: 0xFF0100
	   - DPM address: 0xF90000

.fi
.RS
Besides, Interrupt Priority Level (JP2), Intruction Request (JP6),
and Boundary Select (JP1) jumpers should also be properly set before testing.
Fragment Discard jumper (JP5) should be shorted for testing purpose and
opened as the test is done.
.RE

.RS
The settings of the following jumpers are standard:
.RE

.nf
	   - IPL: 4
	   - IRQ: 4
	   - Boundary select: 8

.fi
.RS
Refer to V/EIU HARDWARE REFERENCE MANUAL for locations of the
above jumpers on controller board.
.RE

1.3. Pre-Caution:
.sp 1
.RS
At the present, the controller is not capable to transmit
messages of which length is greater
than 64 characters in loop 3 mode.
This mode is temporarily tested with messages
less than 64 characters.  Therefore,
Jumper 5 (JP5) must be shorted in order to allow messages of such
length to be processed.
.RE

.RS
All tests performed on the Ethernet controller board are in loop-back
mode.  Therefore, actual connection to ethernet is not neccessary.
.RE

.RS
The csr word, as seen in figure 1, is receiver's status word which is
coded to record the status of the received message.  Each receive buffer has 
its own csr word which is the first word of every receive buffer.  For
more information on receive buffer and transmit buffer, please refer
to V/EIU Hardware Reference Manual (Doc. V/EIU.HR.V001), Chapter 4.
.RE
	  
.RS
For some unknown reasons, the crc error bit of the csr word of the receive
buffer (see figure 1)
is always set by the receiver when the controller operates
in loop-back mode.  Therefore, the detection capability of this 
type of error could not be
tested and verified in this test program.  As a result,
the number of messages
with crc error reported to the console after every test phase should not be
concerned.
.RE

2.  LOADING AND EXECUTING:
.sp 1
.RS
The Ethernet controller test can be loaded from one of two
storage media, magnetic tape or disk.  To load the test,
perform the following steps:
.RE

.RS
When the system is powered up, it attemps to start bootstrap
procedure from the disk.  Type '#' within 10 seconds when
asked to do so, then enter the following CP commands:
.RE

.nf
		#>h.
		#>y.
		#>fd cyp(0,0)	/* Specify tape is load device */
	Or
		#>fd Xsd(Y,0)	/* Specify disk is load device */
				/* where X: f for fsd type.    */
				/*          x for xfsd type.   */
				/*       Y: drive no; 0,1..    */
		#>fu /wcs	/* Load WCS                    */
		#>fl /d/io.se	/* load test program           */
.fi

.RS
To execute the test, enter:
.RE
.nf

		#>y.		/* Initialize the system   */
		#>r.		/* Run the program	   */

.fi

3.  TEST DESCRIPTION:
.sp 1
.RS
As mentioned above, there are seven (7) steps in which the V/EIU controller
is thoroughly tested.
The Ethernet controller(s)
is/are first probed before any test can begin.  If there is
at least one such board installed, it/they is/are reported at the console and
the test begins.  
Otherwise, no Ethernet controller board is available for testing,
the test program will inform
the situation at the console and then will terminate.
The following messages are typically seen at the console as the test
proceeds in this step:
.RE

.nf
	Probing for V/EIU...
	V/EIU no. X1 at address FFFF0000
	V/EIU no. X2 at address FFFF0100
	2 V/EIUs found.

	where: X1, X2 are logical orderth number assigned by
	       the test program. Used to be 0 and 1.

	       FFFF0000 & FFFF0100 are controllers' versabus 
	       addresses

.fi

3.1. Phase 1: Reset and Initialization
.sp 1
.RS
After being detected as described above,
the controllers are sequentially tested.  The first test 
performed on each controller is the RESET function.
If the command is successfully
executed by the controller, this message is printed at the console:
.RE

.nf
	BEGIN TESTING UNIT NO.: X

	1. RESET AND INITIALIZE

	Initialize V/EIU at YYYYYY
	Reset V/EIU unit no. X

	where: X is assigned logical orderth number
	       YYYYYY is controller's physical address
.fi

.RS
If the reset is failed, the test of current controller will
be aborted and the next controller, if any, will be tested.
The following message is expected if the test fails to bring
the controller up.
.RE

.nf
	***  Controller would not go active. Test aborted. ***

.fi

3.2. Phase 2: Register Validation Test
.sp 1
.RS
In this phase of testing, all I/O registers ,as listed in
appendix B except csr, segb, tseg, rseg, ivct, and fcol registers,
are validated by a write/read process.  The total of errors
(failed registers) is reported at the console.
Also, the values of segment registers are read and printed
for verifying purpose.
User expects the following messages:
.RE

.nf
	2. REGISTERS VALIDATION TEST------------------------>

	RAR registers test: X error(s)

	Transmit segment reg (rseg): Y1
	Receive segment  reg (tseg): Y2
	Boundary segment reg (segb): Y3

	where:  X is the no. of registers failed the write/read test.
		Y2 = 0 
		Y1 = Y3 is the pre-set values of JP1.
.fi

.RS
Note that user should check whether segment registers' values
reflect the actual settings.  
.RE

.RS
Regardless of any error occured in this test,
the next phases
will be continued since this type of errors (except segment register
errors which the test program has no way to detect)
will not effect the
operation of next tests.
.RE

3.3. Phase 3: LOOP 2 Mode Test
.sp 1
.RS
In this test phase, the controller is set to operate in
loop 2 mode.  The basic function of the controller's CCU in this mode
is to check parallel data paths connected from the
transmit buffer to the receive buffer
(see appendix A).  The data is sequentially transfered from
current transmit segment to current receive segment.  Therefore,
the only thing that is concerned in this test is correctness of
the received data (the setting of error
detection bits (see figure 1) of receiver's csr word is ignored).
Upon receiving a transmited message,
receive handler compares the received message with the transmitted 
message
for a match.  A no-match situation means failure to the concerned data paths.
.RE

.nf
	 15  14  13  12  11  10    ...      0
	___________________________..._________
	|   |   |   |   |   |                 |
	|___|___|___|___|___|______...________|
	  ^   ^   ^   ^   ^         ^
	  |   |   |   |   |         |
	  |   |   |   |   |         |______ Message length (11 bits)
	  |   |   |   |   |________________ Odd number of bits error
	  |   |   |   |____________________ Underrun error
          |   |   |________________________ CRC error
	  |   |____________________________ Overrun error
	  |________________________________ Buffer Full/Empty bit


	Figure 1.  CSR word of receive buffer.

.fi

.RS
User expects the following messages at the console as the test program
proceeds in this phase:
.RE

.nf
	3. MODE 2 TEST---------------------------------->

	Transmit:  X1 messages
	Receive:   X2 messages
	Discard:   X3 message(s)
	Done with: Y mismatched message(s)

	where: X1 is the number of messages transmitted,
		  in this case, X1 = 25. 
	       X2 is the number of messages received re-
		  gardless of the status (error or not).
	       X3 is the number of discarded messages,i.e.,
		  dropped by the transmitter after 15 retries.
	       Y  is the number of received messages that
	 	  is mismatched with the original message.
.fi

.RS
Y should be 0(zero) in order to quarantee the mentioned data paths is
OK.
.RE

3.4. Phase 4: LOOP 3 Mode Test
.sp 1
.RS
The controller is set to operate in loop 3 mode in this test phase.
In this mode, all the controller's logics are examined except the external
drivers to the Ethernet interface.  All error code bits as seen in
figure 1 are properly set (except crc).  Appendix A shows how data flows as the
controller operates in this mode.
.RE

.RS
There are 11 messages being transmited in this mode for testing purpose.
Every message is checked for errors as it is received.  There is no error
report for every message; instead, the sum of the errors is reported at the end
of this test phase in statistical form as seen below.
.RE

.RS
The following items are checked and reported as a message received:
.RE

.nf
	- CRC error bit of receiver csr word
	- Odd number of bits error.
	- Overrun error bit.
	- Underrun error bit.
	- Count of message length.
	- and the message itself is compared with the transmited
	  message.
.fi

.RS
As mentioned earlier, the messages transmited in this mode have
the length less than 64 characters.  Therefore, the underrun bit
will always be on.  This should not be concerned as a controller's failure.
The same fact applied to CRC error report.  For some unknown reason,
the CRC error bit is always set as the controller operates in loop-back
mode.  Therefore, we, again, ignor the CRC error report until this
problem can be fixed.
.RE

.nf
	4. MODE 3 TEST---------------------------------->

	Transmit: X1 messages
	Receive:  X2 message(s)
	Discarded: X3 message(s)

		 Number of Messages With

	Overrun	   Underrun    CRC    Odd # of bits
	   0	      Y1        Y2         0

	Done with: Z1 mismatched message(s)
		   Z2 received message(s) w/ incorrect byte count

	where: X1 = 11
	       X2 + X3 = X1, X2 must be much greater than X3
		           ideally, X3 = 0 and X2 = X1.
	       Y1 = 10; Y2 = X2 
	       Z1 = Z2 = 0 to be sure that the controller operates
		           properly.
.fi

.fi


3.5. Phase 5: LOOP 3 Mode, ODD NUMBER OF BITS Error Test 
.sp 1
.RS
In this test phase, the transmitter is forced to transmit
an odd number of bits per character in order to generate
odd number of bits error condition.
This is used to test the receiver's capability to detect
this type of error during operation.
.RE

.RS
Note that the count of message length in the receiver side
will be different with that of in transmitter side as a result of 
dropping 'odd number of bits' charecter(s) by the receiver.
Thus, the received messages are surely not matched with the
original transmitted messages.  Therefore, the last two counts
should be the same with the statistical report under "Odd # of bits".
.RE


.nf
	5. MODE 3, ODD NUMBER OF BITS ERROR TEST -------->

	Transmit: X1 messages
	Receive:  X2 message(s)
	Discarded: X3 message(s)

	         Number of Messages With

	Overrun	   Underrun    CRC    Odd # of bits
	   0	       Y1	Y2	   Y3

	Done with: Z1 mismatched message(s)
		   Z2 received message(s) w/ incorrect byte count

	where: X1 = 11
	       X2 + X3 = X1, X2 must be much greater than X3
		             ideally, X3 = 0 and X2 = X1.
	       Y1 = Y2 = X2
	       Y3 must be close to X2
	       Z1 # Z2 # Y2 
.fi

3.6. Phase 6: LOOP 3 Mode, CRC Error Test
.sp 1
.RS
In this phase of testing, the messages are transmitted without
CRC data in order to generate the CRC error condition for the
purpose of verifying the controller's capability in detecting
this type of error.
However, as mentioned previously, the CRC bit is , somehow, always set, 
when the controller operates in loop-back mode, regardless of whether
the CRC error exists.  Therefore, this phase is not released now until
the problem can be fixed and the CRC error bit is properly set
by the receiver logic.
.RE

3.7. Phase 7: LOOP 3 Mode, OVERRUN Error Test
.sp 1
.RS
The purpose of this test phase is to verify the receiver's
capability in detecting overrun error.
The transmitted messages are arranged so that their length is
longer than the maximun allowable length (1514 characters) in order
to generate overrun error condition.
However, as mentioned earlier, the controller in loop 3
mode does not properly operate with messages of length greater than
64 characters.  This test can not be performed at the time being.
As soon as this problem of the Ethenet controller can be resolved
(by the manufacturer, not by us) this test program will be upgraded
and this test phase included.
.RE

4.  ERROR MESSAGES:
.sp 1
.RS
The following error messages reflect fatal errors and will cause the test of
the current controller to be aborted.
.RE

.nf
	***  Controller would not go active. Test aborted. ***

.fi
.RS
This error message indicates that the controller is not active
after the GO bit was set.
.RE

.RS
The following messages, concerning about the segment registers,
serve the purpose of warning only. Since the test can be carried out
even if these non-fatal errors occur.
.RE

.nf
	Warning: rseg register >= segb register
.fi

.RS
rseg register is initialized (by the hardware) to be higher than or
equal to segb register.  When this happens, either rseg is wrongly
initialized to be greater than zero (0) or segb register is preset
(by means of JP1) to zero.  If the latter is the case, we have to
correct segb to desired value by means of JP1.  
.RE

.nf
	Warning: tseg register <> segb register
.fi

.RS
tseg register's content must be equal to whatever the content of segb register
is.  If it is not, the hardware that is responsible for initialization
of these registers has been defected.
.RE

.nf
	Warning: rseg is not indexing to the 1st receive buffer
.fi

.RS
rseg register's content must be 0 at initialization.
.RE

.RS
The following message indicates that the receiver is not triggered
after a message being sent by the transmitter.  This may be caused
by the failure of receiver logic (hardware).
.RE

.nf
	Warning: Receiver not responding. X message(s) are lost.

	where: X is the number of messages sent but not received.
.fi
.bp
			APPENDIX C


		     A   SAMPLE   RUN

.nf
	#>Type '#' to cancel boot
	#>#
	#>h.
	#>y.
	#>fd fsd(0,0)	/* Specify disk is load device */
			/* fsd type.		       */
	#>fu /wcs	/* Load WCS                    */
	#>fl /d/io.se  	/* test program load */
	#>y.		/* initialize	     */
	#>r.		/* execute the test  */

	Probing for V/EIU...
	V/EIU no. X1 at address FFFF0000
	V/EIU no. X2 at address FFFF0100
	2 V/EIUs found.

	BEGIN TESTING UNIT NO.: 0

	1. RESET AND INITIALIZATION

	Initialize V/EIU at FF0000
	Reset V/EIU unit no. 0 

	2. REGISTERS VALIDATION TEST------------------------>

	RAR registers test: 0 error(s)

	Transmit segment reg (tseg): 8
	Receive segment  reg (rseg): 0
	Boundary segment reg (segb): 8

	3. MODE 2 TEST-------------------------------------->

	Transmit:  20 messages
	Receive:   20 messages
	Discarded:    0 message(s)

	Done with: 0 mismatched message(s)

	4. MODE 3 TEST-------------------------------------->

	Transmit: 11 messages
	Receive:  11 message(s)
	Discarded: 0 message(s)

		 Number of Messages With

	Overrun	   Underrun    CRC    Odd # of bits
	   0	      10	11	   0

	Done with: 0 mismatched message(s)
		   0 received message(s) w/ incorrect byte count


	5. MODE 3, ODD NUMBER OF BITS ERROR TEST------------>

	Transmit: 11 messages
	Receive:  11 message(s)
	Discarded: 0 message(s)

	         Number of Messages With

	Overrun	   Underrun    CRC    Odd # of bits
	   0	       11	11	  10 

	Done with: 11 mismatched message(s)
		   11 received message(s) w/ incorrect byte count

	END TESTING OF UNIT NO.: 0

	BEGIN TESTING UNIT NO.: 1 

	1. RESET AND INITIALIZATION

	Initialize V/EIU at FF0100
	Reset V/EIU unit no. 1 

	2. REGISTERS VALIDATION TEST------------------------>

	RAR registers test: 0 error(s)

	Transmit segment reg (tseg): 8
	Receive segment  reg (rseg): 0
	Boundary segment reg (segb): 8

	3. MODE 2 TEST-------------------------------------->

	Transmit:  20 messages
	Receive:   20 messages
	Discarded:    0 message(s)

	Done with: 0 mismatched message(s)

	4. MODE 3 TEST-------------------------------------->

	Transmit: 11 messages
	Receive:  11 message(s)
	Discarded: 0 message(s)

		 Number of Messages With

	Overrun	   Underrun    CRC    Odd # of bits
	   0	      10	11	   0

	Done with: 0 mismatched message(s)
		   0 received message(s) w/ incorrect byte count


	5. MODE 3, ODD NUMBER OF BITS TEST------------------>

	Transmit: 11 messages
	Receive:  11 message(s)
	Discarded: 0 message(s)

	         Number of Messages With

	Overrun	   Underrun    CRC    Odd # of bits
	   0	       11	11	  10 

	Done with: 11 mismatched message(s)
		   11 received message(s) w/ incorrect byte count

	END TESTING UNIT NO.: 1
.fi

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.