![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to DOC CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [Power 6/32 Unix Tahoe 4.2BSD] / cci / d / ether|
Return to DOC CVS log | Up to [Power 6/32 Unix Tahoe 4.2BSD] / cci / d / ether |
1.1 root 1:
2:
3:
4: .nf
5:
6: TABLE OF CONTENTS
7:
8:
9:
10:
11: 1. INTRODUCTION
12:
13: 1.1. Supported Hardware
14:
15: 1.2. Addresses Setting
16:
17: 1.3. Pre-caution
18:
19: 2. LOADING AND EXECUTING
20:
21: 3. TEST DESCRIPTION
22:
23: 3.1. Phase 1: Reset and Initialization
24:
25: 3.2. Phase 2: Register Validation Test
26:
27: 3.3. Phase 3: Loop 2 Mode Test
28:
29: 3.4. Phase 4: Loop 3 Mode Test
30:
31: 3.5. Phase 5: Loop 3 Mode, ODD NUMBER OF BITS Error Test
32:
33: 3.6. Phase 6: Loop 3 Mode, CRC Error Test
34:
35: 3.7. Phase 7: Loop 3 Mode, OVERRUN Error Test
36:
37: 3.8. Phase 8: Loop 3 Mode, UNDERRUN Error Test
38:
39: 4. ERROR MESSAGES
40:
41: 5. APPENDICES
42: .fi
43: .bp
44: .nf
45: APPENDICES
46:
47:
48:
49:
50:
51:
52: A. V/EIU Functional Block Diagram
53:
54: B. I/O Programming Registers
55:
56: C. A Sample Test
57:
58: .fi
59: .bp
60: .nf
61: V/EIU CONTROLLER DIAGNOSTIC TEST
62: .fi
63:
64:
65:
66:
67: 1. INTRODUCTION:
68: .sp 1
69: .RS
70: The purpose of this test is to validate the Ethernet controller board
71: logic during initialization and operation. The test consists of seven (7) steps
72: in which every functionality is thoroughly tested and every error
73: detection capability of the
74: controller is verified.
75: .RE
76:
77: 1.1. Supported Hardware:
78: .sp 1
79: .RS
80: This diagnostic program can support up to two (2) Ethernet
81: controller boards.
82: .RE
83:
84: 1.2. Addresses Setting:
85: .sp 1
86: .RS
87: The following addresses must be set as intructed below before any testing
88: can be initiated:
89: .RE
90:
91: .nf
92: First controller's addresses setting:
93:
94: - I/O port address: 0xFF0000
95: - DPM address: 0xF80000
96:
97: Second controller's addresses setting (if any):
98:
99: - I/O port address: 0xFF0100
100: - DPM address: 0xF90000
101:
102: .fi
103: .RS
104: Besides, Interrupt Priority Level (JP2), Intruction Request (JP6),
105: and Boundary Select (JP1) jumpers should also be properly set before testing.
106: Fragment Discard jumper (JP5) should be shorted for testing purpose and
107: opened as the test is done.
108: .RE
109:
110: .RS
111: The settings of the following jumpers are standard:
112: .RE
113:
114: .nf
115: - IPL: 4
116: - IRQ: 4
117: - Boundary select: 8
118:
119: .fi
120: .RS
121: Refer to V/EIU HARDWARE REFERENCE MANUAL for locations of the
122: above jumpers on controller board.
123: .RE
124:
125: 1.3. Pre-Caution:
126: .sp 1
127: .RS
128: At the present, the controller is not capable to transmit
129: messages of which length is greater
130: than 64 characters in loop 3 mode.
131: This mode is temporarily tested with messages
132: less than 64 characters. Therefore,
133: Jumper 5 (JP5) must be shorted in order to allow messages of such
134: length to be processed.
135: .RE
136:
137: .RS
138: All tests performed on the Ethernet controller board are in loop-back
139: mode. Therefore, actual connection to ethernet is not neccessary.
140: .RE
141:
142: .RS
143: The csr word, as seen in figure 1, is receiver's status word which is
144: coded to record the status of the received message. Each receive buffer has
145: its own csr word which is the first word of every receive buffer. For
146: more information on receive buffer and transmit buffer, please refer
147: to V/EIU Hardware Reference Manual (Doc. V/EIU.HR.V001), Chapter 4.
148: .RE
149:
150: .RS
151: For some unknown reasons, the crc error bit of the csr word of the receive
152: buffer (see figure 1)
153: is always set by the receiver when the controller operates
154: in loop-back mode. Therefore, the detection capability of this
155: type of error could not be
156: tested and verified in this test program. As a result,
157: the number of messages
158: with crc error reported to the console after every test phase should not be
159: concerned.
160: .RE
161:
162: 2. LOADING AND EXECUTING:
163: .sp 1
164: .RS
165: The Ethernet controller test can be loaded from one of two
166: storage media, magnetic tape or disk. To load the test,
167: perform the following steps:
168: .RE
169:
170: .RS
171: When the system is powered up, it attemps to start bootstrap
172: procedure from the disk. Type '#' within 10 seconds when
173: asked to do so, then enter the following CP commands:
174: .RE
175:
176: .nf
177: #>h.
178: #>y.
179: #>fd cyp(0,0) /* Specify tape is load device */
180: Or
181: #>fd Xsd(Y,0) /* Specify disk is load device */
182: /* where X: f for fsd type. */
183: /* x for xfsd type. */
184: /* Y: drive no; 0,1.. */
185: #>fu /wcs /* Load WCS */
186: #>fl /d/io.se /* load test program */
187: .fi
188:
189: .RS
190: To execute the test, enter:
191: .RE
192: .nf
193:
194: #>y. /* Initialize the system */
195: #>r. /* Run the program */
196:
197: .fi
198:
199: 3. TEST DESCRIPTION:
200: .sp 1
201: .RS
202: As mentioned above, there are seven (7) steps in which the V/EIU controller
203: is thoroughly tested.
204: The Ethernet controller(s)
205: is/are first probed before any test can begin. If there is
206: at least one such board installed, it/they is/are reported at the console and
207: the test begins.
208: Otherwise, no Ethernet controller board is available for testing,
209: the test program will inform
210: the situation at the console and then will terminate.
211: The following messages are typically seen at the console as the test
212: proceeds in this step:
213: .RE
214:
215: .nf
216: Probing for V/EIU...
217: V/EIU no. X1 at address FFFF0000
218: V/EIU no. X2 at address FFFF0100
219: 2 V/EIUs found.
220:
221: where: X1, X2 are logical orderth number assigned by
222: the test program. Used to be 0 and 1.
223:
224: FFFF0000 & FFFF0100 are controllers' versabus
225: addresses
226:
227: .fi
228:
229: 3.1. Phase 1: Reset and Initialization
230: .sp 1
231: .RS
232: After being detected as described above,
233: the controllers are sequentially tested. The first test
234: performed on each controller is the RESET function.
235: If the command is successfully
236: executed by the controller, this message is printed at the console:
237: .RE
238:
239: .nf
240: BEGIN TESTING UNIT NO.: X
241:
242: 1. RESET AND INITIALIZE
243:
244: Initialize V/EIU at YYYYYY
245: Reset V/EIU unit no. X
246:
247: where: X is assigned logical orderth number
248: YYYYYY is controller's physical address
249: .fi
250:
251: .RS
252: If the reset is failed, the test of current controller will
253: be aborted and the next controller, if any, will be tested.
254: The following message is expected if the test fails to bring
255: the controller up.
256: .RE
257:
258: .nf
259: *** Controller would not go active. Test aborted. ***
260:
261: .fi
262:
263: 3.2. Phase 2: Register Validation Test
264: .sp 1
265: .RS
266: In this phase of testing, all I/O registers ,as listed in
267: appendix B except csr, segb, tseg, rseg, ivct, and fcol registers,
268: are validated by a write/read process. The total of errors
269: (failed registers) is reported at the console.
270: Also, the values of segment registers are read and printed
271: for verifying purpose.
272: User expects the following messages:
273: .RE
274:
275: .nf
276: 2. REGISTERS VALIDATION TEST------------------------>
277:
278: RAR registers test: X error(s)
279:
280: Transmit segment reg (rseg): Y1
281: Receive segment reg (tseg): Y2
282: Boundary segment reg (segb): Y3
283:
284: where: X is the no. of registers failed the write/read test.
285: Y2 = 0
286: Y1 = Y3 is the pre-set values of JP1.
287: .fi
288:
289: .RS
290: Note that user should check whether segment registers' values
291: reflect the actual settings.
292: .RE
293:
294: .RS
295: Regardless of any error occured in this test,
296: the next phases
297: will be continued since this type of errors (except segment register
298: errors which the test program has no way to detect)
299: will not effect the
300: operation of next tests.
301: .RE
302:
303: 3.3. Phase 3: LOOP 2 Mode Test
304: .sp 1
305: .RS
306: In this test phase, the controller is set to operate in
307: loop 2 mode. The basic function of the controller's CCU in this mode
308: is to check parallel data paths connected from the
309: transmit buffer to the receive buffer
310: (see appendix A). The data is sequentially transfered from
311: current transmit segment to current receive segment. Therefore,
312: the only thing that is concerned in this test is correctness of
313: the received data (the setting of error
314: detection bits (see figure 1) of receiver's csr word is ignored).
315: Upon receiving a transmited message,
316: receive handler compares the received message with the transmitted
317: message
318: for a match. A no-match situation means failure to the concerned data paths.
319: .RE
320:
321: .nf
322: 15 14 13 12 11 10 ... 0
323: ___________________________..._________
324: | | | | | | |
325: |___|___|___|___|___|______...________|
326: ^ ^ ^ ^ ^ ^
327: | | | | | |
328: | | | | | |______ Message length (11 bits)
329: | | | | |________________ Odd number of bits error
330: | | | |____________________ Underrun error
331: | | |________________________ CRC error
332: | |____________________________ Overrun error
333: |________________________________ Buffer Full/Empty bit
334:
335:
336: Figure 1. CSR word of receive buffer.
337:
338: .fi
339:
340: .RS
341: User expects the following messages at the console as the test program
342: proceeds in this phase:
343: .RE
344:
345: .nf
346: 3. MODE 2 TEST---------------------------------->
347:
348: Transmit: X1 messages
349: Receive: X2 messages
350: Discard: X3 message(s)
351: Done with: Y mismatched message(s)
352:
353: where: X1 is the number of messages transmitted,
354: in this case, X1 = 25.
355: X2 is the number of messages received re-
356: gardless of the status (error or not).
357: X3 is the number of discarded messages,i.e.,
358: dropped by the transmitter after 15 retries.
359: Y is the number of received messages that
360: is mismatched with the original message.
361: .fi
362:
363: .RS
364: Y should be 0(zero) in order to quarantee the mentioned data paths is
365: OK.
366: .RE
367:
368: 3.4. Phase 4: LOOP 3 Mode Test
369: .sp 1
370: .RS
371: The controller is set to operate in loop 3 mode in this test phase.
372: In this mode, all the controller's logics are examined except the external
373: drivers to the Ethernet interface. All error code bits as seen in
374: figure 1 are properly set (except crc). Appendix A shows how data flows as the
375: controller operates in this mode.
376: .RE
377:
378: .RS
379: There are 11 messages being transmited in this mode for testing purpose.
380: Every message is checked for errors as it is received. There is no error
381: report for every message; instead, the sum of the errors is reported at the end
382: of this test phase in statistical form as seen below.
383: .RE
384:
385: .RS
386: The following items are checked and reported as a message received:
387: .RE
388:
389: .nf
390: - CRC error bit of receiver csr word
391: - Odd number of bits error.
392: - Overrun error bit.
393: - Underrun error bit.
394: - Count of message length.
395: - and the message itself is compared with the transmited
396: message.
397: .fi
398:
399: .RS
400: As mentioned earlier, the messages transmited in this mode have
401: the length less than 64 characters. Therefore, the underrun bit
402: will always be on. This should not be concerned as a controller's failure.
403: The same fact applied to CRC error report. For some unknown reason,
404: the CRC error bit is always set as the controller operates in loop-back
405: mode. Therefore, we, again, ignor the CRC error report until this
406: problem can be fixed.
407: .RE
408:
409: .nf
410: 4. MODE 3 TEST---------------------------------->
411:
412: Transmit: X1 messages
413: Receive: X2 message(s)
414: Discarded: X3 message(s)
415:
416: Number of Messages With
417:
418: Overrun Underrun CRC Odd # of bits
419: 0 Y1 Y2 0
420:
421: Done with: Z1 mismatched message(s)
422: Z2 received message(s) w/ incorrect byte count
423:
424: where: X1 = 11
425: X2 + X3 = X1, X2 must be much greater than X3
426: ideally, X3 = 0 and X2 = X1.
427: Y1 = 10; Y2 = X2
428: Z1 = Z2 = 0 to be sure that the controller operates
429: properly.
430: .fi
431:
432: .fi
433:
434:
435: 3.5. Phase 5: LOOP 3 Mode, ODD NUMBER OF BITS Error Test
436: .sp 1
437: .RS
438: In this test phase, the transmitter is forced to transmit
439: an odd number of bits per character in order to generate
440: odd number of bits error condition.
441: This is used to test the receiver's capability to detect
442: this type of error during operation.
443: .RE
444:
445: .RS
446: Note that the count of message length in the receiver side
447: will be different with that of in transmitter side as a result of
448: dropping 'odd number of bits' charecter(s) by the receiver.
449: Thus, the received messages are surely not matched with the
450: original transmitted messages. Therefore, the last two counts
451: should be the same with the statistical report under "Odd # of bits".
452: .RE
453:
454:
455: .nf
456: 5. MODE 3, ODD NUMBER OF BITS ERROR TEST -------->
457:
458: Transmit: X1 messages
459: Receive: X2 message(s)
460: Discarded: X3 message(s)
461:
462: Number of Messages With
463:
464: Overrun Underrun CRC Odd # of bits
465: 0 Y1 Y2 Y3
466:
467: Done with: Z1 mismatched message(s)
468: Z2 received message(s) w/ incorrect byte count
469:
470: where: X1 = 11
471: X2 + X3 = X1, X2 must be much greater than X3
472: ideally, X3 = 0 and X2 = X1.
473: Y1 = Y2 = X2
474: Y3 must be close to X2
475: Z1 # Z2 # Y2
476: .fi
477:
478: 3.6. Phase 6: LOOP 3 Mode, CRC Error Test
479: .sp 1
480: .RS
481: In this phase of testing, the messages are transmitted without
482: CRC data in order to generate the CRC error condition for the
483: purpose of verifying the controller's capability in detecting
484: this type of error.
485: However, as mentioned previously, the CRC bit is , somehow, always set,
486: when the controller operates in loop-back mode, regardless of whether
487: the CRC error exists. Therefore, this phase is not released now until
488: the problem can be fixed and the CRC error bit is properly set
489: by the receiver logic.
490: .RE
491:
492: 3.7. Phase 7: LOOP 3 Mode, OVERRUN Error Test
493: .sp 1
494: .RS
495: The purpose of this test phase is to verify the receiver's
496: capability in detecting overrun error.
497: The transmitted messages are arranged so that their length is
498: longer than the maximun allowable length (1514 characters) in order
499: to generate overrun error condition.
500: However, as mentioned earlier, the controller in loop 3
501: mode does not properly operate with messages of length greater than
502: 64 characters. This test can not be performed at the time being.
503: As soon as this problem of the Ethenet controller can be resolved
504: (by the manufacturer, not by us) this test program will be upgraded
505: and this test phase included.
506: .RE
507:
508: 4. ERROR MESSAGES:
509: .sp 1
510: .RS
511: The following error messages reflect fatal errors and will cause the test of
512: the current controller to be aborted.
513: .RE
514:
515: .nf
516: *** Controller would not go active. Test aborted. ***
517:
518: .fi
519: .RS
520: This error message indicates that the controller is not active
521: after the GO bit was set.
522: .RE
523:
524: .RS
525: The following messages, concerning about the segment registers,
526: serve the purpose of warning only. Since the test can be carried out
527: even if these non-fatal errors occur.
528: .RE
529:
530: .nf
531: Warning: rseg register >= segb register
532: .fi
533:
534: .RS
535: rseg register is initialized (by the hardware) to be higher than or
536: equal to segb register. When this happens, either rseg is wrongly
537: initialized to be greater than zero (0) or segb register is preset
538: (by means of JP1) to zero. If the latter is the case, we have to
539: correct segb to desired value by means of JP1.
540: .RE
541:
542: .nf
543: Warning: tseg register <> segb register
544: .fi
545:
546: .RS
547: tseg register's content must be equal to whatever the content of segb register
548: is. If it is not, the hardware that is responsible for initialization
549: of these registers has been defected.
550: .RE
551:
552: .nf
553: Warning: rseg is not indexing to the 1st receive buffer
554: .fi
555:
556: .RS
557: rseg register's content must be 0 at initialization.
558: .RE
559:
560: .RS
561: The following message indicates that the receiver is not triggered
562: after a message being sent by the transmitter. This may be caused
563: by the failure of receiver logic (hardware).
564: .RE
565:
566: .nf
567: Warning: Receiver not responding. X message(s) are lost.
568:
569: where: X is the number of messages sent but not received.
570: .fi
571: .bp
572: APPENDIX C
573:
574:
575: A SAMPLE RUN
576:
577: .nf
578: #>Type '#' to cancel boot
579: #>#
580: #>h.
581: #>y.
582: #>fd fsd(0,0) /* Specify disk is load device */
583: /* fsd type. */
584: #>fu /wcs /* Load WCS */
585: #>fl /d/io.se /* test program load */
586: #>y. /* initialize */
587: #>r. /* execute the test */
588:
589: Probing for V/EIU...
590: V/EIU no. X1 at address FFFF0000
591: V/EIU no. X2 at address FFFF0100
592: 2 V/EIUs found.
593:
594: BEGIN TESTING UNIT NO.: 0
595:
596: 1. RESET AND INITIALIZATION
597:
598: Initialize V/EIU at FF0000
599: Reset V/EIU unit no. 0
600:
601: 2. REGISTERS VALIDATION TEST------------------------>
602:
603: RAR registers test: 0 error(s)
604:
605: Transmit segment reg (tseg): 8
606: Receive segment reg (rseg): 0
607: Boundary segment reg (segb): 8
608:
609: 3. MODE 2 TEST-------------------------------------->
610:
611: Transmit: 20 messages
612: Receive: 20 messages
613: Discarded: 0 message(s)
614:
615: Done with: 0 mismatched message(s)
616:
617: 4. MODE 3 TEST-------------------------------------->
618:
619: Transmit: 11 messages
620: Receive: 11 message(s)
621: Discarded: 0 message(s)
622:
623: Number of Messages With
624:
625: Overrun Underrun CRC Odd # of bits
626: 0 10 11 0
627:
628: Done with: 0 mismatched message(s)
629: 0 received message(s) w/ incorrect byte count
630:
631:
632: 5. MODE 3, ODD NUMBER OF BITS ERROR TEST------------>
633:
634: Transmit: 11 messages
635: Receive: 11 message(s)
636: Discarded: 0 message(s)
637:
638: Number of Messages With
639:
640: Overrun Underrun CRC Odd # of bits
641: 0 11 11 10
642:
643: Done with: 11 mismatched message(s)
644: 11 received message(s) w/ incorrect byte count
645:
646: END TESTING OF UNIT NO.: 0
647:
648: BEGIN TESTING UNIT NO.: 1
649:
650: 1. RESET AND INITIALIZATION
651:
652: Initialize V/EIU at FF0100
653: Reset V/EIU unit no. 1
654:
655: 2. REGISTERS VALIDATION TEST------------------------>
656:
657: RAR registers test: 0 error(s)
658:
659: Transmit segment reg (tseg): 8
660: Receive segment reg (rseg): 0
661: Boundary segment reg (segb): 8
662:
663: 3. MODE 2 TEST-------------------------------------->
664:
665: Transmit: 20 messages
666: Receive: 20 messages
667: Discarded: 0 message(s)
668:
669: Done with: 0 mismatched message(s)
670:
671: 4. MODE 3 TEST-------------------------------------->
672:
673: Transmit: 11 messages
674: Receive: 11 message(s)
675: Discarded: 0 message(s)
676:
677: Number of Messages With
678:
679: Overrun Underrun CRC Odd # of bits
680: 0 10 11 0
681:
682: Done with: 0 mismatched message(s)
683: 0 received message(s) w/ incorrect byte count
684:
685:
686: 5. MODE 3, ODD NUMBER OF BITS TEST------------------>
687:
688: Transmit: 11 messages
689: Receive: 11 message(s)
690: Discarded: 0 message(s)
691:
692: Number of Messages With
693:
694: Overrun Underrun CRC Odd # of bits
695: 0 11 11 10
696:
697: Done with: 11 mismatched message(s)
698: 11 received message(s) w/ incorrect byte count
699:
700: END TESTING UNIT NO.: 1
701: .fi
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.