2.1 Sun Multimedia Codec Test (audbri)

This test checks the functionality of several different Sun Multimedia Codec 16-bit audio options. Depending on the system under test, different subtests will be available for testing.

For a system with a dual rate ISDN (DBRI) chip and a Sun SpeakerBox^(TM) attached, the following subtests are available:

• Crystal test
• Loopback test
• Calibration function
• Controls test
• Audio test

For a SPARCstation LX system (with an on-board DBRI/Codec audio chip without a SpeakerBox attached) the following subtests are available:

• Crystal test
• Audio test

For a SPARCstation 5 system (with an on-board Codec audio chip) the following subtests are available:

• Loopback test
• Audio test

Upon start-up, the SunDiag probe determines which audio devices are present, and it will limit the audbri Option Menu accordingly.

2.1.1 audbri Test Descriptions

Crystal Test The crystal subtest measures the accuracy of the crystal that generates the sample rate clock. It does this by playing a 1 second signal and then measuring the actual time it takes for that signal to be played. This measurement is performed for each of the 8 standard sample rates.

Loopback Tests Loopback subtests verify the performance of these audio ports: the headphone port, microphone port, line-in port, and line-out port. This subtest plays and records a known signal, calculates play and record gain, and analyzes the S/N plus distortion at various sample frequencies. It also measures the channel separation at each of the sample frequencies. Both the line-out/line-in and headphone/line-in loopback subtests require a stereo loopback cable.

---

Note - The speaker/microphone loopback subtest requires special hardware, and is used by manufacturing centers and special test facilities. Do not invoke the Speaker/Microphone loopback test unless you have the special hardware.

---

Controls Test This is an interactive subtest which tests the three control buttons on the Sun SpeakerBox. This subtest plays music and you are asked to press the Volume Down, Volume Up, and Mute buttons in a specified order. If there is no input from while this subtest, the music will play for about 30 seconds, stop, and return an error.

Audio Test You decide if this subtest passes or fails. A short selection of music is played. If you decide the music sounds adequate, then the subtest passes. If you do not hear the music, or it is badly distorted, then you know there is a problem.

2.1.2 audbri Option Menus

Upon start-up, the SunDiag probe determines which audio devices are present, and it will limit the audbri option Menu accordingly. The three possible option menus are shown below.

2.1.2.1 audbri Option Menu with a SpeakerBox

Figure 2-1 audbri

2.1.2.2 audbri Option Menu for SPARCstation 5

Figure 2-2 audbri

2.1.2.3 audbri Option Menu for a SPARCstation LX without a

SpeakerBox

Figure 2-3 audbri

2.1.2.4 audbri Option Descriptions

---

Note - The Calibration and Reference File options can only be selected through the command line.

---

Type Press MENU to select the type of test to run. The choices are Line-in/Line-out and Line-in/Headphone.

Loopback This exclusive setting enables you to toggle the Loopback subtest on and off.

Calibration Used with the SpeakerBox to Microphone Loopback subtest. This exclusive setting enables you to toggle the Calibration function on and off. When enabled, this function creates calibration files for the Loopback subtest to use as a baseline in future testing. The default reference file names are listed below.

Crystal Test Click SELECT to enable or disable the Crystal subtest.

Controls Test Click SELECT to enable or disable the Controls subtest.

Audio Test Click SELECT to enable or disable the Audio test. This is the only subtest enabled by default.

Reference File Used with the SpeakerBox to Microphone Loopback subtest. If the SpeakerBox to Microphone Loopback subtest and Calibration function are enabled, a new calibration file will be created.

If the SpeakerBox to Microphone Loopback subtest is enabled and the Calibration function is disabled, the Loopback checks this text field for the calibration file to test against. The default reference file created in /opt/SUNWdiag/bin is:

audbri_sbmic.data

2.1.3 audbri Command Line Syntax

/opt/SUNWdiag/bin/audbri B C D=/dev/sound/<unit_no> F=reference_file_path
I=/dev/ioctl_device M L S T=loopback_test_type X standard_arguments

Arguments
B	Brief test. This is the same as specifying q for quick test.
C	Loopback Calibration for SpeakerBox to Microphone
D=/dev/audio_device	Specifies the audio device to be tested. The default is D=/dev/sound/<unit_no>
F=reference_file_path	The default files created are: /opt/SUNWdiag/bin/audbri_sbmic.data If you use others, specify that path and filenames with this option. See T=loopback_test_type.

Arguments	(Continued)
I=/dev/ioctl_device	Specifies the audio ioctl device to be tested; the default is /dev/audioct/<unit_no>.
M	Directs this subtest to run the Audio test.
L	Run the Loopback Test.
S	Run the Sun SpeakerBox Controls and Mute Indicator Test.
T=loopback_test_type	Specifies the type of Calibration/Loopback Test. The choices are listed below. The default is 1. 0 Speaker/Microphone Note: this subtest requires special hardware, and is used by manufacturing centers and special test facilities. Do not invoke the Speaker/Microphone loopback test unless you have the special hardware. 1 Line-in/Line-out 2 Line-in/Headphone
X	Run the Audio Crystal Test

2.1.4 audbri Quick Test Description

Running this test in quick mode restricts testing to the Crystal test only.

2.2 ISDN/DBRI Test (isdntest)

This test verifies the functionality of the ISDN portion of the Dual Basic Rate ISDN (DBRI) chip.

2.2.1 isdntest Test Description

isdntest is actually a set of several subtests. Three main channels exist within an ISDN: D, B1 and B2. In each of the following subtests, unless otherwise indicated, the D channels will be in Basic Rate HDLC data mode, the B1 channels in 56 kbps HDLC data mode, and the B2 channels in 64 kbps HDLC data mode. D channel packet size is 256 bytes, and B channel packet size is 1024 bytes. The packet count will be 10 packets. Each channel runs as an independent child process.

The first subtest is the local loopback test. It first checks the initial activation state of the Network Termination (NT) and Terminal Equipment (TE) interfaces to make sure they are deactivated. It then activates each interface using the "force activation" capability of DBRI. Each interface is then put into local loopback mode (See Figure 2-4). Data residing in host memory is written to each interface, which loops the data back onto itself. The data is then read back into host memory and verified. Each channel, D, B1 and B2 is tested, with the exception of the TE D channel, which cannot be tested in local loopback mode. This test runs internal to the DBRI chip. This subtest does not require an NT to TE external loopback connector.

Figure 2-4 isdntest

The next subtest is the activation/deactivation test. This subtest runs through the activation/deactivation sequence for the NT and then the activation sequence for the TE. The T101 and T103 timers are set to 5 seconds. This subtest requires an NT to TE external loopback connector.

The remote loopback capability is tested next. The TE interface is put into remote loopback mode, and the NT transmits data to the TE on all three channels, D, B1 and B2 (See Figure 2-5). The TE loops all data back to the NT and reads a copy of it. Data is then verified. The whole process is then repeated with the TE transmitting to the NT, which is placed in remote loopback mode. This subtest requires an NT to TE external loopback connector.

Figure 2-5 isdntest

Next, a read/write test is performed on all 6 of the ISDN channels: TE D, TE B1, TE B2, NT D, NT B1 and NT B2. The external loopback connector connects each channel on the TE interface to its corresponding channel on the NT (See Figure 2-6). Six unique data patterns are used, one for each path. Packets read are compared against packets written. The test is repeated with the B1 channels placed in 64 kbps HDLC data mode and the B2 channels in 56 kbps HDLC data mode. This subtest requires an NT to TE external loopback connector.

Figure 2-6 isdntest

The next subtest is a packet size test. A read/write test, similar to the previous one, is performed with a packet count of 100. Each packet transmitted and received is a unique size, computed randomly. This subtest requires an NT to TE external loopback connector.

The last subtest is a data path test. Using the ISDN_SET_CHANNEL ioctl, data is routed through a series of short pipe interconnects within DBRI (See Figure 2-7). This subtest requires an NT to TE external loopback connector.

Figure 2-7 isdntest

2.2.2 isdntest Options

Figure 2-8 isdntest

Packet Size Packet Size indicates the size, in bytes, of the B channel packets. The default size is 1024 bytes for the B channels and 256 for the D channels. The maximum packet size is 8186 bytes for the B channels, and the minimum size is 1 byte. The D channel packet size will always be set to 256, except during the packet size test, where it is set to random values between 1 and 256.

Packet Count Packet Count indicates how many packets are to be transmitted and received for all channels. The default packet count is 10 packets. The maximum packet count is 100 packets.

2.2.3 isdntest Command Line Syntax

/opt/SUNWdiag/bin/isdntest S=packet_size C=packet_count standard_arguments

Arguments
S=packet_size	packet_size is the size, in bytes, of the B channel packets. The default size is 1024 bytes for the B channels and 256 for the D channels. The maximum packet size is 8186 packets for the B channels, and the minimum size is 1 packet. The D channel packet size will always be set to 256, except during the packet size test, where it is set to random values between 1 and 256.
C=packet_count	packet_count indicates how many packets are to be transmitted and received for all channels. The default count is 10 packets, and the maximum packet count is 100 packets.

2.2.4 isdntest Quick Test Description

Running this test in quick mode restricts testing to the local loopback subtest only.

2.2.5 isdntest Error Messages

Initial state on /dev/isdn/0/nt/mgt is ISDN_ACTIVATED
  Using the NT management device driver on device 0, the initial activation
  state on the NT interface is ISDN_ACTIVATED, which is incorrect.

Unable to activate with /dev/isdn/1/te/mgt.
TE state = ISDN_DEACTIVATED   NT state = ISDN_DEACTIVATED
  Using the TE management device driver on device 1, the TE and NT
  interfaces did not activate within the allowed period of time. The current
  activation state on both interfaces is ISDN_DEACTIVATED.

Data miscompare for NT B2 channel reader.
Packet 6 offset 58 contains C8, should be A9.

The NT B2 channel was comparing packets read to those written and found a miscompare.

2.3 Graphics Tower (gttest)

SunDiag tests the Sun Graphics Tower with a sequence of subtests that can accurately locate and identify failing FRUs (Filed Replaceable Units). All tests are nondestructive and maintain the system integrity during and after the tests are run.

---

Caution - Do not run any other application that uses the GT accelerator port while running gttest. This combination will cause SunDiag to return incorrect errors.

---

---

Note - gttest requires approximately 1.5M bytes of disk space in the /tmp directory to extract its working files. If this space is not available, the diagnostic will fail and report warning and error messages indicating lack of disk space.

---

By default, SunDiag runs all of the available tests, except the Stereo test. See the Test Descriptions section below.

---

Note - To avoid excessive test cycle times when testing the GT Graphics Subsystem, follow these instructions:

1. Enable Single Pass on the SunDiag Options menu. 2. Enable Verbose on the SunDiag Options menu. 3. Do not select any other diagnostic tests.

Following these procedures ensures that gttest will run once, report its status as each test routine executes, and then exit.

---

---

Note - Disable all screen savers before testing any graphics device. Type xset s off at a UNIX prompt to disable the Solaris screen saver.

---

Figure 2-9 gttest

2.3.1 gttest Test Description

The subtests are run in the order shown in Figure 2-10. The subtests assume that the GT Graphics Subsystem has an active working interface with the SPARCstation CPU. If for any reason SunDiag cannot make the connection, further testing is not possible and SunDiag will report a fatal unrecoverable error.

Figure 2-10 gttest

2.3.1.1 Direct Port Tests

The direct ports tests check the non-accelerated portion of the GT using the following subtests.

Video Memory Array, Tested from Host This subtest checks the frame buffer.

The video memory array subtest selects and tests 64 by 64 pixel regions covering all video memory planes, including the 2 8-bit alpha/overlay planes, 2 24-bit image planes, 24-bit depth (Z buffer) plane, 10-bit WID plane, and two cursor planes. If the subtest detects an error, SunDiag reports the defective plane and location.

CLUTs This subtest checks the frame buffer.

This subtest performs a non-destructive read-write test on the frame buffer color look up tables. If this subtest detects a failure, SunDiag reports the location of the failure.

At the beginning of this subtest, red, green, and blue stripes display for visual verification of the digital-to-analog converters (DACs).

2.3.1.2 Accelerator Port Tests

The accelerator port tests check the accelerated portion of the GT using the following subtests.

Front End Local Data Memory This subtest checks the Graphics Processor Front End Board Local Data Memory.

The Local Data Memory subtest is a nondestructive read-write memory test. This subtest aborts at the first error and reports a memory failure.

Setup Processor Shared Memory Test This subtest checks the graphics processor rendering pipeline.

The Setup Processor shared memory subtest verifies that the i860 microprocessor can write and read the setup processor shared memory without error.

Rendering Pipeline This subtest checks the graphics processor rendering pipeline.

The rendering pipeline subtest checks each of the three rendering pipeline stages: setup processor, edge walker, span interpolator, and Pixel Bus Multiplexer. The Edge Walker and Span Interpolator subtests are a series of small tests that verify the functionality of the edge walker and span interpolator ASICs in vectors, triangles, Gouraud shading, alpha blending, and anti-aliasing rendering. The results of the tests are verified by means of checksum values accumulated from data output by the Rendering Pipeline. SunDiag reports any subtest failures.

Video Memory Array, Tested from Front End This subtest checks the frame buffer.

This test makes sure that the video memory array can be accessed by the i860 microprocessor via the Local Bus. This is a destructive read-write test which verifies that all the Frame Buffer video memory locations are good. If this subtest detects an error, SunDiag reports the defective plane and location.

Frame Buffer Output Section This subtest checks the frame buffer.

The Frame Buffer Output Section contains a diagnostic feedback register in the RAMDACs. The Frame Buffer Output Section subtest creates various windows in the Window ID plane then sets up the look up tables (LUTs) associated with these values. This subtest then writes known values to the video memory of these windows. Next, the frame buffer is switched into trace mode, which reads the video through the diagnostic feedback register and puts the data into the shadow memory. Finally, this subtest compares the contents of the shadow memory with the expected values via checksum and determines if the Output Section is operating properly.

If this subtest detects an error, the test reports the error, and the actual and expected values are displayed on the system Console.

2.3.1.3 Integration Test

The integration test is a sequence of subtests running GT display list programs. These subtests ensure the GT Graphics Subsystem integrity at the system level. The subtests test all features of the hardware at the application level, reading the results from the frame buffer and verifying the results by comparing against known good images.

These tests use a frame buffer region of 1152 by 900 pixels, in the upper left corner of the screen, regardless of the size screen attached to the system. The tests use previously-generated test images for each color plane (red, green, and blue). These test images are stored in a reduced size (1/64th the normal size) to save disk space.

Vector Generation This subtest tests all Graphics Tower boards. The faulty component can be determined by analyzing the errors reported in the Direct Port and Accelerator Port tests.

This subtest renders fairly large vector objects with aliased, anti-aliased, and shaded vectors.

Triangle Generation This subtest tests all Graphics Tower boards. The faulty component can be determined by analyzing the errors reported in the Direct Port and Accelerator Port tests.

This subtest renders objects with aliased, anti-aliased shaded, and shaded triangles.

Spline Curves Generation This subtest tests all Graphics Tower boards. The faulty component can be determined by analyzing the errors reported in the Direct Port and Accelerator Port tests.

This subtest renders an object with both parametric and NURBS¹ curves of different orders.

---

1. Non-Uniform Rational B-Splines.

Viewport Clipping This subtest tests all Graphics Tower boards. The faulty component can be determined by analyzing the errors reported in the Direct Port and Accelerator Port tests.

This subtest renders and clips an object around and in front on the screen.

Hidden Surface Removal This subtest tests all Graphics Tower boards. The faulty component can be determined by analyzing the errors reported in the Direct Port and Accelerator Port tests.

This subtest renders objects with the Z-buffer-compare attribute turned on.

Polygons Edges Highlighting This subtest tests all Graphics Tower boards. The faulty component can be determined by analyzing the errors reported in the Direct Port and Accelerator Port tests.

This subtest renders an object with the edge highlighting attribute turned on.

Transparency This subtest tests all Graphics Tower boards. The faulty component can be determined by analyzing the errors reported in the Direct Port and Accelerator Port tests.

This subtest renders a scene with two transparency modes (standalone and alpha blend) in various degrees. This results in a two-pass transparency of the objects in the scene.

Depth-Cueing This subtest tests all Graphics Tower boards. The faulty component can be determined by analyzing the errors reported in the Direct Port and Accelerator Port tests.

This subtest renders an object with the depth-cueing attribute turned on.

Lighting and Shading This subtest tests all Graphics Tower boards. The faulty component can be determined by analyzing the errors reported in the Direct Port and Accelerator Port tests.

This subtest renders an object with multiple light sources and Gouraud shading for front and back surfaces.

Text Generation This subtest tests all Graphics Tower boards. The faulty component can be determined by analyzing the errors reported in the Direct Port and Accelerator Port tests.

This subtest generates diverse text lines with different attributes for checking.

Picking This subtest tests all Graphics Tower boards. The faulty component can be determined by analyzing the errors reported in the Direct Port and Accelerator Port tests.

This subtest has two parts: a pick detect test and a pick echo test.

Animation and Arbitration This subtest checks the frame buffer.

This subtest renders a moving, double-buffered object into the image plane while a second Solaris process performs a read-write test to the cursor and WID planes from the direct port on the Frame Buffer. This subtest simulates conditions in the real world, where rendering processes and windows operations run concurrently.

Stereo (Interactive) This subtest checks the frame buffer.

This subtest displays an object in stereo mode. You must verify the proper operation by looking at the screen with stereo glasses. To terminate to the test, you must press q.

FB Locking See the "Special Note on Testing Multiple Framebuffers" section in Chapter 1 of the SunDiag User's Guide for details.

2.3.2 gttest Command Line Syntax

/opt/SUNWdiag/bin/gttest D=device_name S=subtest_number F=#_of_subtest_loops B=#_of_test_loops L standard_arguments

Arguments
D=devicename	devicename is the full path name of the device under test. The default is /dev/gt0.
S=subtest_number	subtest_number is the test number of the subtest to be run. Select from the subtests below. You can run multiple subtests by adding the subtest numbers. For example, n=0x3 runs both test 1 and test 2; n=0x180 runs both test 0x080 and test 0x0100. Note that you do not need the leading zeros. To run all tests, type n=0x7FFFF. 0x 000 001 Direct port--video memories 0x 000 002 Direct port--CLUTs and WID LUT 0x 000 004 Accelerator port--front end Local Data Memory 0x 000 008 Accelerator port--setup processor shared memory 0x 000 010 Accelerator port--rendering pipeline 0x 000 020 Accelerator port--video memories 0x 000 040 Accelerator port--Frame buffer output section 0x 000 080 Integration test--vectors 0x 000 100 Integration test--triangles 0x 000 200 Integration test--spline curves 0x 000 400 Integration test--viewport clipping. 0x 000 800 Integration test--hidden surface removal 0x 001 000 Integration test--polygon edges highlighting 0x 002 000 Integration test--transparency 0x 004 000 Integration test--depth cueing 0x 008 000 Integration test--lighting and shading 0x 010 000 Integration test--text 0x 020 000 Integration test--picking 0x 040 000 Integration test--arbitration 0x 080 000 Integration test--stereo (interactive)
F=#_of_subtest_loops	#_of_subtest_loops is the number of loops for each subtest. The default is 1 (one loop)

Arguments	(Continued)
B=#_of_test_loops	#_of_test_loops is the number of loops of each test sequence. The default is 1 (one loop).
L	Disables framebuffer locking. See the "Special Note on Testing Multiple Framebuffers" in Chapter 1 of the SunDiag User's Guide for details.

2.3.3 gttest Quick Test Description

Running this test in quick mode does not change the test procedure.

2.3.4 gttest Command Line Examples

Here are three examples of SunDiag gttest on-line commands. Make sure to change directories to /opt/SUNWdiag/bin before running gttest from the command line. gttest is hard-wired to look for its data file, gttest.data, in /opt/SUNWdiag/bin.

1. A Simple accelerator port test, Frame Buffer output section, single pass:

# cd /opt/SUNWdiag/bin # gttest S=0x40

2. All direct port tests, five loops of sequence:

# cd /opt/SUNWdiag/bin # gttest S=0x3 B=0x5

3. All subtests (except the interactive tests), two loops of each subtest, four loops of each test sequence:

# cd /opt/SUNWdiag/bin # gttest S=0x7FFFF F=2 B=4

2.3.5 gttest Error Messages

The GT SunDiag error messages are described below. The error messages are listed in alphabetical order.

Arbitration Test:        Accelerator port drawing in double
buffer mode, [plane group], [mode] Mode error at x=[x]
y=[y], exp=[expected], obs=[observed], xor=[xor].                   Suspect
daulty HFB.

Failed the Arbitration integration test. [plane group] is one of the following: Red Plane Group A, Overlay Plane Group A or B, Image Plane Group A or B, Cursor Plane Group, Cursor Enable Plane group, Z Buffer Plane Group, Hardware Window ID Plane Group, or Software Window ID Plane Group. [mode] is either byte or stencil access mode. The location of the anomaly as well as the expected and observed values are also given. For pixel access mode, the bank of the memory error is disclosed as well. "HFB" if the GT Frame Buffer board.

Arbitration Test: Accelerator port drawing in double buffer
mode, Direct port simultaneous write to both buffers, read
from buffer [A or B] : [plane_group], Shapes error at
[address]. Suspect faulty HFB.
  Failed the Arbitration integration test. [plane_group] is one of the following:
  Image plane A or B, Depth plane, WID plane, Cursor plane, or Fast Clear
  Plane A or B. [address] is the linear address of the bad memory cell. "HFB"
  is the GT Frame Buffer Board.

Background process wouldn't die. System error.

A software error. You may have to re-boot the SPARCstation.

Byte/Stencil Access Mode error at x=# y=#, exp=0x#,obs=0x#,
xor=0x#. Suspect faulty HFB.

The direct port video memory test has found an error at pixel (x,y) in the current plane group. Byte/Stencil Access Mode applies to all plane groups that access all 32 bits of the frame buffer memory (in other words, the eight bit image and overlay planes). The test expected to find exp but observed obs, yielding xor when the two values are exclusive or'd with each other. There may be a bad bit in the video memory.

Cannot allocate enough memory for testing. Check swap space
size and memory reserved for test.
  Out of memory error. Increase swap space and/or kill other processes.

Cannot create screen raster for device [device]. Check
device for existence and/or permissions.
  The device that you specified (the default is /dev/fbs/gt0) is not available
  to the test. Make sure that you are executing the test on a machine with a
  GT, and that you have permission to access it.

Can't open display list file [filename]. Suspect incomplete
or incorrect hardware installation. Files may also have
been corrupted because file system ran out of space in
/tmp.
  Indicates a software initialization problem. [filename] is the file that
  SunDiag can't open. Also, approximately 1.5 Mbytes of free space is
  required in /tmp.

Can't open [filename] to dump frame buffer.
  The test needed to open a file to dump the contents of the frame buffer. Use
  df to check drive space, and also to check file permissions.

Can't read display list file [filename]. Suspect incomplete
or incorrect hardware installation. Files may also have
been corrupted.
  Indicates a software initialization problem. [filename] is the display list file
  that SunDiag can't read.

CLUT #n, index #, color [color], expected 0x#, received
0x#.

An error was found in one the fifteen color look up tables tested by SunDiag. The error was found in the nth CLUT. The index is out of 256 entries in each CLUT. Each CLUT has eight bits each for red, green, and blue. The color indicates in which set of eight bits the error was found. By using the expected and received values, you can figure out which bit is incorrect.

Communication with Graphics Engine failed. Suspect
incomplete or incorrect software installation. Front-End
Firmware may also be dead.
  SunDiag is unable to communicate with the GT Graphics Subsystem. A
  software error or hardware error with the GT SBus Adapter Board, HAC
  Cable, or Front End Board.

Cursor plane error: Failed with error code [code]:
[failure]. Suspect faulty HFB.
  Failed accelerator port video memory test.   [code] is the error code number.
  [failure] is an explanation of the error indicated by [code]. "HFB" is the GT
  Frame Buffer Board.

Depth cueing: Error(s) found in [RED], [GREEN], [BLUE}
components.
  Failed the depth cueing integration test. Only the failing component (RED,
  GREEN, or BLUE) appears in the message.

Depth plane error: Failed with error code [code]:
[failure]. Suspect faulty HFB.
  Failed accelerator port video memory test.   [code] is the error code number.
  [failure] is an explanation of the error indicated by [code]. "HFB" is the GT
  Front End Board.

Display list file is too big for the remaining VM!
hdl_size=0x#, vm_size=0x#
  Increase swap space or close other running processes.

Failed to allocate unique WID for 24-bit plane. Suspect
incomplete or incorrect software installation.
  A problem with system initialization.

Failed to get monitor mode: [ERROR] Software error.

A software error. May have to re-boot the SPARCstation.

Failed to set diagnostic mode. Software error.

A software error. May have to re-boot the SPARCstation.

Failed to set monitor mode. Software error.
  A software error. May have to re-boot the SPARCstation.

Fast Clear Plane [A or B] error: Failed with error code
[code]: [failure]. Suspect faulty HFB.
  Failed accelerator port video memory test.   [code] is the error code number.
  [failure] is an explanation of the error indicated by [code]. "HFB" is the GT
  Front End Board.

At FE firmware program counter 0x#, expected display list
instruction 0x#, observed 0x#.
  You may have a bad Front End processor board.

Front End (Firmware) not responding. This may indicate that
the Firmware has died. Try to run gtconfig.
  A hardware problem. SunDiag was unable to communicate with the Front
  End Board. Indicates a problem with the SBus Adapter Board, HAC cable,
  or Front End Board.

Got XCPU interrupt, but user_mcb_ptr->trap_instruction =
0x#, expect 0x#. System software error.
  A software error. May have to re-boot the SPARCstation.

Got XCPU interrupt, but it's not a trap instruction, error
code = # : [message]. This may indicate that the Firmware
has died. Try to run gtconfig.
  A software error. [message] further describes the problem. May have to re-
  boot the SPARCstation.

Hidden Surface Removal: *** Error(s) found in [RED],
[GREEN], [BLUE} components.
  Failed the hidden surface removal integration test. Only the failing
  component (RED, GREEN, or BLUE) appears in the message.

hk_disconnect failed. System software error.

A software error. May have to re-boot the SPARCstation.

hk_munmap failed. System software error.
  A software error. May have to re-boot the SPARCstation.

hk_open failed. GT system is either not initialized or not
connected.
  A software error. May have to re-boot the SPARCstation.

Image plane [A or B] error: Failed with error code [code]:
[failure]. Suspect faulty HGPFE.
  Failed accelerator port video memory test.   [code] is the error code number.
  [failure] is an explanation of the error indicated by [code]. "HGPFE" is the
  GT Front End Board.

LDM error: Failed with error code [code]: [failure].
Suspect faulty HGPFE.
  Failed the accelerator port test of the Front End Local Data Memory. [code]
  is the error code number. [failure] is an explanation of the error indicated by
  [code]. "HGPFE" is the GT Frame End Board.

Lighting and Shading: *** Error(s) found in [RED], [GREEN],
[BLUE] components.
  Failed the lighting and shading integration test. Only the failing component
  (RED, GREEN, or BLUE) appears in the message.

Pick Detect misses:%d lines and/or triangles inside the
pickbox and/or %d lines and triangles outside the pickbox.
  Failed the Picking integration test.   Only the failing component (RED,
  GREEN, or BLUE) appears in the message.

Pick Echo failed: *** Error(s) found in [RED], [GREEN],
[BLUE} components.
  Failed the Picking integration test. Only the failing component (RED,
  GREEN, or BLUE) appears in the message.

Picking: *** Error(s) found in [RED], [GREEN], [BLUE}
components.

Failed the picking integration test. Only the failing component (RED, GREEN, or BLUE) appears in the message.

Pixel Access Mode error at x=# y=#, bank=#,
exp=0x#,obs=0x#, xor=0x#. Suspect faulty HFB.

The direct port video memory test has found an error at pixel (x,y) in the current plane group. Pixel Access Mode applies to all plane groups that do not access the frame buffer memory four bytes at a time. (In other words, all planes except eight bit planes). The memory for the pixel resides in the given memory bank. The test expected to find exp but observed obs, yielding xor when the two values are exclusive or'd with each other. There may be a bad bit in the video memory.

Poly Edges Highlighting: *** Error(s) found in [RED],
[GREEN], [BLUE} components.
  Failed the poly edges highlighting integration test. Only the failing
  component (RED, GREEN, or BLUE) appears in the message.

Rendering Pipeline error: Failed with error code [code]:
[failure]. Suspect faulty HGPRP.
  Failed the accelerator port Rendering Pipeline test. [code] is the error code
  number. [failure] is an explanation of the error indicated by [code].
  "HGPRP" is the GT Front End Board.

Spline Curves: *** Error(s) found in [RED], [GREEN], [BLUE}
components.
  Failed the spline curves integration test. Only the failing component (RED,
  GREEN, or BLUE) appears in the message.

SU Shared RAM error: Failed with error code [code]:
[failure]. Suspect faulty HGPRP.

Failed the accelerator port Rendering Pipeline Setup Processor shared RAM test. [code] is the error code number. [failure] is an explanation of the error indicated by [code]. "HGPRP" is the GT Front End Board.

System initialization failed. Suspect incomplete or
incorrect software installation. Front-End Firmware may
also be dead.

System initialization failed. Most likely a hardware problem with the GT Front End Board.

'tar' never finished. System software problem.
  Make sure that the tar program is installed correctly on your system. Also,
  use df to see if you have enough disk space left in your /tmp directory.

tar: [error]
  Make sure that the tar program is installed correctly on your system. Also,
  use df to see if you have enough disk space left in your /tmp directory.

Texts: Error(s) found in [RED], [GREEN], [BLUE} components.
  Failed the texts integration test. Only the failing component (RED, GREEN,
  or BLUE) appears in the message.

This program requires the default setting of 5 HW and 5 SW
WID Planes. Run gtconfig.

Each of the GT's ten WID planes can be allocated as a hardware or software WID plane. Some programs may change the allocation from the default (5 hardware, 5 software) and forget to change it back. Run gtconfig to set the allocation back to the default.

This program requires the default setting of 5 HW and 5 SW
WID Planes. Enter "unsetenv XNEWS_WID_PLANES" and try
again.

Each of the GT's ten WID planes can be allocated as a hardware or software WID plane. Programs that use the Shapes libraries that need to change the allocation from the default (5 hardware WID planes and 5 software WID planes) do so by setting the environment variable XNEWS_WID_PLANES to the desired number of hard WID planes. A program has set this environment variable, and you must unset it in order to run the GT SunDiag tests.

Transparency: *** Error(s) found in [RED], [GREEN], [BLUE}
components.

Failed the transparency integration test. Only the failing component (RED, GREEN, or BLUE) appears in the message.

Triangles: *** Error(s) found in [RED], [GREEN], [BLUE}
components.
  Failed the triangles integration test. Only the failing component (RED,
  GREEN, or BLUE) appears in the message.

Unable to open /dev/fbs/gt0. Check device for existence
and/or permission.
  SunDiag is unable to open the GT device driver. Make sure that there is a
  /dev/fbs/gt0 device driver and that the permissions are correct.

Vectors: *** Error(s) found in [RED], [GREEN], [BLUE}
components.
  Failed the vectors integration test. Only the failing component (RED,
  GREEN, or BLUE) appears in the message.

vfork: [error]
  An error has occurred while trying to fork a child process. Increase swap
  space, or close other running processes.

Viewport Clipping: *** Error(s) found in [RED], [GREEN],
[BLUE} components.
  Failed the viewport clipping integration test. Only the failing component
  (RED, GREEN, or BLUE) appears in the message.

WID plane error: Failed with error code [code]: [failure].
Suspect faulty HFB.

Failed accelerator port video memory test. [code] is the error code number. [failure] is an explanation of the error indicated by [code]. "HFB" is the GT Front End Board.

2.4 cgsix Frame Buffer, GX and GX+ Options Test (cg6test)

cg6test verifies the cgsix frame buffer and the GX options offered with most SPARC^(TM) based workstations and servers.

---

Note - Disable all screen savers before testing any graphics device. Type xset s off at a UNIX prompt to disable the Solaris screen saver.

---

2.4.1 cg6test Test Description.

This test stresses the frame buffer with the subtests described below.

Cursor Test This is a visual test of the overlay registers of the RAMDAC. A pointer is drawn on the screen and moved around to predetermined locations. There is a problem if the pointer disappears. This visual test ensures that the overlay is working properly.

Fast Copy in Double Buffer Test Mode Two full-size screen rasters images are created in double buffer mode. Different patterns are written to each of them. The hidden buffer is copied to the visible buffer, and the data is compared. An error message is returned if there are inconsistencies. Then the buffer is flipped and the process is repeated.

---

Note - This test only applies to Sun Microsystems GX+ graphic accelerators with double-buffering capacity.

---

TEC Test The TEC verifies that the Transformation Engine and Cursor control logic are being accessed. This confirms that further TEC access will be performed correctly.

FBC Test The FBC test verifies that the Frame Buffer Controller logic is being accessed. This confirms that further FBC access will be performed correctly.

Frame Buffer Test This test verifies that the frame buffer memory is working. A walking 1's pattern is written to memory, with a specific color signifying one of eight bits. The screen is divided into eight equally wide vertical stripes. A walking one is written to each stripe, causing eight iterations of these stripes. The value written is read back and checked. If the values do not match, an error is reported.

Screen Test Using Blits This test draws blocks of color and performs blit transfers to other portions of the screen. First, the entire screen is drawn with cyan color, then a black block is put in the upper left corner. This subtest blits this block on the upper right, lower right, and lower left corners, then or's the whole image.

Blit Test A block of data is drawn, and blit into a location at the bottom right rectangle.

Line Test Lines with different data values are drawn on the screen and appear in different colors. The data is read back and compared with the expected values. An error is returned in the case of a mismatch.

Polygon Test Hourglass-shaped polygons are drawn on the screen, using the four vertices. After all the polygons are rendered in the video memory, they are read back and the data compared with expected values. If there is a mismatch, an error is displayed.

Colormap Test All 256 locations in the color map are loaded with a greyscale both backwards and forwards manner. This means decreasing values are loaded to all R, G, and B values.

---

Warning - If the system under test has a monochrome or greyscale monitor, visual color problems are undetectable.

---

Figure 2-11 cg6test

2.4.2 cg6test Options

FB Locking See the "Special Note on Testing Multiple Framebuffers" section in Chapter 1 of the SunDiag User's Guide for details.

2.4.3 cg6test Command Line Syntax

/opt/SUNWdiag/bin/cg6test L standard_arguments

Arguments
L	Disables framebuffer locking. See the "Special Note on Testing Multiple Framebuffers" in Chapter 1 of the SunDiag User's Guide for details.

---

Note - Extra Swap Space Required: 5 MB

---

2.4.4 cg6test Quick Test Description

Running this test in quick mode does not change the test procedure.

2.4.5 cg6test Error Messages

cg6test returns the error messages described below for subtest failures:

CG6 <subtest> failure, x pos = <failure location>, y pos = <failure
location>, exp = <expected value>, actual = <actual value>
  The named subtest could not complete successfully.

CG6plus VRAM(s) to probe: U#

The polygon test prints these messages for a TurboGX framebuffer.

Colormap error - red, loc =<failure location>, exp = <expected
        value>, actual = <actual value>
Colormap error - green, loc =<failure location>, exp = <expected
value>, actual = <actual value>
Colormap error - blue, loc =<failure location>, exp = <expected
        value>, actual = <actual value>

Couldn't create new screen for <device>.
  SunDiag could not open up a memory area for simulating frame buffer
  memory, where: <device> = /dev/fb, /dev/cgsix0, or
  /dev/cgsixn

Could not create child raster
  The color map test and frame buffer tried to create a child raster. If there is
  not enough memory available, this test may fail.

Error in opening device /dev/cgsix

The device could not be opened. A wrong device name was supplied. Rebooting with the -r option is required if new devices are installed in Solaris 2.x systems. See "New Device Drivers" on page 1-2 of this book.

Error: ERROR_MALLOC_FAILED

Not enough memory was available during color map and frame buffer memory testing.

Failed to create raster
  The raster to do a graphics operation could not be opened. There might not
  be enough memory available, or the wrong raster name was supplied.

Failed to get cmap

Not enough memory was available.

Failed to create context

Not enough memory was available.

render_main: can't map lego

cg6test was not able to map the framebuffer board register addresses.

render_main: TEC_EXCEPTION
build_view_matrix: TEC_EXCEPTION
  The TEC section of the frame buffer logic had an exception during the
  named routine.

clear_window: DRAWSTATUS

A DRAWSTATUS error occurred during the clear_window routine.

2.5 cgtwelve Frame Buffer, GS Test (cg12)

The GS is an integrated frame buffer and 3D graphics accelerator for desktop SPARCstations.

---

Note - The user interface is locked out while this test is being run. You can stop this test with the Stop button on the SunDiag window, or temporarily halt the test by pressing Control-C.

---

---

Note - Disable all screen savers before testing any graphics device. Type xset s off at a UNIX prompt to disable the Solaris screen saver.

---

2.5.1 cg12 Test Description

The cg12 test operates on two levels, the host level and the C30 level.

---

Note - The GS accelerator includes a Texas Instruments TMS320C30 DSP chip. Throughout this manual, it is referred to as the C30.

---

The Host Level The host level includes test code based on the SunView window system, the GPSI libraries, and a specially-compiled version of the Pixrect^(TM) libraries. This is the main part of the cg12 test. The test results are verified by reading out the image memory with the Pixrect library, reducing the resolution, and then verifying with the supplied test images. The test images are generated on a control system for each of the color planes (red, blue, and green).

There are two reasons for reducing the size of the test images.

• Large test images occupy too much disk space on the root directory of the system.
• The test images may not match the result of the tests pixel by pixel even when the hardware is functioning perfectly. This is due to the rounding error of different floating point hardware and the eventual displacements produced by different Firmware revisions (C30 GPSI).

The test results are first reduced 64 times by averaging all 8x8 pixel blocks to a single value and then comparing them with the test images. Each compared pixel is allowed to be within a certain tolerance range to compensate for the variations mentioned above. The tolerance range is small enough to sense functional abnormalities and yet big enough to accommodate expected variations. In case of error, the respective 8x8 pixel block turns black and its location is reported.

C30 Level The C30 level with test code is linked to the GPSI code. The host posts an unpublished GPSI SunDiag command with a number of parameters (10). The GPSI command interpreter calls a SunDiag subroutine that examines the parameters passed to it and determines which test to call. The test result is passed back to the host through one of the parameters. The host hangs and waits until it receives the completion flag from the test. If the C30 test code dies, the host will time out after a couple of seconds.

Figure 2-12 shows the tests implemented in the cg12 test. You can select the subtests to be run and the loop counts for each subtest and each board. The default selection for all subtests and loop counts is one.

Figure 2-12 cg12

2.5.2 cg12 Options

DSP Covers all the internal C30 registers (int and float), on-chip RAM, and integer and floating point instruction executions (parallel instructions). The RAM test is a nondestructive read/write test with the patterns 0x5a5a5a5a and 0xa5a5a5a5. During the RAM test, all interrupts are disabled. The registers are tested with the patterns 0x55555555 and 0xaaaaaaaa.

SRAM & DRAM The SRAM test switches on each page of the 4 SRAM pages and executes the DSP test on the selected SRAM page. The DRAM test is the same RAM test run again on the DRAM space, except that it excludes the space where the test code resides. (The test code resides in DRAM.)

Video Memories Selects and tests all 64x64 Pixrect regions covering the entire video memory planes (including overlay, zbuffer, window ID). The image planes are tested both single and double buffered. All regions are tested with random patterns generated each time the test is called.

Look up Tables The look up tables in the RAMDAC are tested with a read/write test and a random table. The random table is generated each time the test is called.

Vectors Generation This test has three parts. First it generates concentric circles with flat shaded vectors in red, green, blue, yellow, and white. If the result is successfully verified (described above), then an object with color shaded vectors is rendered. If the result of this test is also correct, then an object (hexnut) is generated with wide textured lines. The result of each part is then verified as above with test images previously stored.

Polygons Generation Flat shaded polygons are rendered, and the result is verified with previously stored test images.

Transformations An object (the spaceship Enterprise) is rendered and transformed in 3D several times to give the impression of moving in space. It leaves a path when it moves away. The path has to match the expected path in the test images previously stored.

Clipping & Hidden This test has three parts: clipping, hidden surface removal, and picking. In the clipping test, two objects are generated and the view port is clipped so that only parts of them are visible. In the hidden surface removal test, objects ("pacmen") are generated and should overlay each other correctly in the order of the Z component. In the picking test, a pick window is set and triangles and polygons are generated inside and outside. The results of the clipping and hidden surface removal test are verified with test images previously stored. In the picking test, the pick events are counted.

Depth Cueing An object is rendered with the Depth Cue Attribute turned on. The result is verified with test images previously stored.

Lighting & Shading A cylinder composed with polygons and triangles is rendered with multiple light sources and Gouraud shading mode. The zbuffer is on. The result is verified with test images previously stored.

Arbitration Two Solaris processes are running simultaneously. One process renders flat shaded polygons and vectors at random locations on screens into the 24-bit image plane, while the other accesses the overlay plane, the overlay enable plane, and the window ID plane. If the second process has problems with read and write to and from any of the mentioned planes, the test reports the error. Otherwise the test passes. A visual image with three color stripes (RGB) is shown at the end for visual verification of the RAMDAC.

FB Locking See the "Special Note on Testing Multiple Framebuffers" section in Chapter 1 of the SunDiag User's Guide for details.

2.5.3 cg12 Command Line Syntax

/opt/SUNWdiag/bin/cg12 D=device_name s=subtest_number F=#_of_loops B=#_of_loops L standard_arguments

Arguments
D=device_name	The full path name of the device must be specified.
s=subtest_number	subtest_number specifies the number (a binary representation) of the subtest choices to be run. The default is -1 (all subtests run). More than one subtest choice can be selected by ordering their subtest numbers. Example: n = 3 specifies that the DSP and SRAM & DRAM subtests are run. The following subtest choices can be specified: -1 All subtests 1 DSP 2 SRAM and DRAM 4 Video Memories 8 Look Up Tables 16 Vectors Generation 32 Polygons generation 64 Transformations 128 Clipping and Hidden 256 Depth Cueing 512 Lighting and Shading 1024 Arbitration
F=#_of_loops	Number of loops for each subtest
B=#_of_loops	Number of loops for each board
L	Disables framebuffer locking. See the "Special Note on Testing Multiple Framebuffers" in Chapter 1 of the SunDiag User's Guide for details.

---

Note - Extra Swap Space Required: 3 MBytes

---

---

Note - Make sure to change directories to /opt/SUNWdiag/bin before running cg12 from the command line. cg12 is hard-wired to look for its data files, cg12.data and cg12.data.gsxr, in /opt/SUNWdiag/bin.

---

2.5.4 cg12 Quick Test Description

Running this test in quick mode restricts testing to the DSP subtest (subtest flag set to 1).

2.5.5 cg12 Error Messages

The following errors described below are reported in case of hardware failures:

Registers Test failed

  One or more DSP registers failed. The DSP chip is flawed.

On-chip Memory Test failed

DSP chip problem; the on-chip memory failed the memory test.

Integer Instructions Test failed

DSP chip problem; integer instructions were not performed correctly.

Float Instruction Test failed

DSP chip problem; float instructions were not performed correctly.

DRAM error

The DRAM does not pass the memory test. An unbundled software diagnostics package, the SunDiagnostic Executive, can help you locate the failure.

SRAM error in page (0-3)

SRAM page (0-3) does not pass the memory test. An unbundled software diagnostics package, the SunDiagnostic Executive, can help you locate the failure.

<Plane>: Pixrect error at <address>

  The Video Memory indicated failed the memory test.<Plane> can be
  window ID, 8-bit compatibility, 24-bit color, or Overlay and Overlay Enable.

error at index <index>, write <pattern>, read <pattern>

The hardware look-up table is defective at the location index. The written and expected patterns are shown against the actual pattern.

Error(s) found in (RED, GREEN, BLUE) component(s)

The generated patterns do not match the expected patterns in their indicated components.

The vectors generation, polygon generation, transformations, clipping and hidden, depth cueing, and lighting & shading tests have the same error message:

<type> pick test: detected <num> misses <position> of the pick
window out of total <total> picking events
  The Picking test has generated an interrupt error. <type> = triangle or
  polygon, <num> = number of pick events missed, <position> = in, out or
  on, and <total> = number of pick events generated.

Pixrect error in <Plane> at <address>

The access in the indicated plane has error(s) at the indicated address when the drawing engine is drawing graphics at the same time. Possibly a local bus error.

---

Note - The above error messages are for hardware only. Any other error messages reported are software error messages and will indicate any necessary action.

---

2.6 Color Graphics Frame Buffer Test (cg14test)

This test checks the cg14 frame buffer card. cg14test is specific to the VSIMM (Video SIMM)/SX Memory Controller devices in the SPARCstation 10 SX.

Warnings Because of possible conflicts between SunDiag cg14 framebuffer tests and OpenWindows applications that use the cg14 framebuffer, the following restrictions apply when running the cg14test SunDiag test:

• Do not run any graphic applications other than OpenWindows while the SunDiag software is running framebuffer tests
• Do not run any OpenWindows programs that generate video updates outside or on top of the SunDiag window
• Do not close the SunDiag window to an icon while it is running framebuffer tests
• Make sure to enable the framebuffer locking option from the Options window (see "FB Locking" on page 2-54)

2.6.1 cg14test Test Description

cg14test has 9 distinct test groups:

1. MDI and VBC Chip Control Registers

2. Memory Chips

3. MDI Chip Cursor Registers

4. MDI Chip Clut registers

5. DAC Chip Registers

6. MDI Chip XLU Registers

7. CG14 Display (visual only)

8. MDI Chip Testmode Readback in 8-bit mode

9. Driver IOCTRLs

Hardware Test Groups (test groups 1 - 6) Testing is done by opening /dev/fbs/cgfourteenX, mmap'ing (R/W Shared) the MDI Control Address Space, modifying the target test location (using direct writes to the mmap'ed address space), reading from the mmap'ed address space for verification, and closing the device.

Visual Pattern Test Group (test group 7) Testing is done by loading a visual pattern of 256 colors, then rotating the pattern around by adjusting CLUT1. This subtest must be verified visually.

Data Propagation Test Group (test group 8) Testing is done by loading the frame buffer (FB) memory with four neutral data patterns, then setting a target FB pixel with data that will trigger the testmode readback latch. The result is read from the readback register after vertical blanking occurs. Two different trigger patterns used at each FB pixel. All four MDI pixel paths (A - D) are used, and the pixel locations for each trigger are designed to detect gross MDI input data opens or short, VRAM SAM addressing, and VRAM -> SAM transfer addressing.

The screen will show four horizontal bars, which will be either greyscale of colored. These bars will change each time the trigger data is inverted, and as it completes the testing of a raster pattern.

---

Note - This test will test in 8 bits per pixelmode. If the resolution and VRAM size allows, 32 bits per pixelmode will also be tested automatically.

---

Driver Test Group (test group 9) Test all IOCTL calls that have not yet been used to verify proper driver communication to the hardware. Call the driver to perform a hardware update, and then confirm that update was successful by using the complementary driver read, or reading the mmap'ed address space and comparing it against the stimulus.

Notes 1. cg14test performs appropriate steps, from this list, before and after each test (if possible), to maintain context and prevent visual confusion:

a. Save register data before overwriting it.

b. Disable video if possible.

c. Do the specific test. d. Restore the saved register data info.

2. The data used for register testing will be optimized to include all 0's, all 1's, and walking a 1 through each bit under test.

2.6.1.1 MDI and VBC Chip Control Registers (test group 1)

Master Control Register bits 7-0 w/r verify. Packed Pixel Register bits 3-0 w/r verify. Master Status Register bits 7-4 r/o verify 0x00 and 0x30 occur. Horizontal Blank Start Register bits 9-0 w/r verify. Horizontal Blank Clear Register bits 9-0 w/r verify. Horizontal Sync Set Register bits 9-0 w/r verify. Horizontal Sync Clear Register bits 9-0 w/r verify. Composite Sync Clear Register bits 9-0 w/r verify. Vertical Blank Start Register bits 11-0 w/r verify. Vertical Blank Clear Register bits 11-0 w/r verify. Vertical Sync Set Register bits 11-0 w/r verify.

Vertical Sync Clear Register bits 11-0 w/r verify. Transfer Cycle Set Register bits 9-0 w/r verify (MDI revision 0 only). Transfer Cycle Clear Register bits 9-0 w/r verify (MDI revision 0 only). Fault Status Address Register bits 15-0 w/r verify.

Auto-increment Address Space Register bits 7-0 w/r verify. Video Base Register bits 23-12 w/r verify.

2.6.1.2 Memory Chips (test group 2)

VRAM Testing The Data Bus Test will use 18 NTA patterns (Nair, Thatte, and Abraham's testing procedure for RAM) to check for data and address faults. This test will be performed in MDI_CHUNKY_XBGR_MAP access mode only.

The test operates as follows.

• Ascend through the FB memory clearing it to 0s

• NTA pattern test number x reads a location to make sure test data y is there, and then writes new data z to that location. The location ascends through the FB sequentially.

Table 2-1 cg14test

NTA Test Pattern Number = x	Test Data = y	New Data = z
1.0	0x00000000	0x01010101
1.5	0x01010101	0xffffffff
2.1	0xffffffff	0xf1f1f1f1
2.2	0xf1f1f1f1	0x33333333
3.1	0x33333333	0xf0f0f0f0
3.2	0xf0f0f0f0	0x0f0f0f0f
4.1	0x0f0f0f0f	0x55555555
4.2	0x55555555	0xaaaaaaaa
5.1	0xaaaaaaaa	0x05050505 (1x) 0x88888888 (2x)
5.2	0x88888888	0xf5f5f5f5
6.1	0xf5f5f5f5	0x00000000 (1x) 0x5f5f5f5f (2x)
6.2	0x5f5f5f5f	0x11111111
7.1	0x11111111	0x00000000 (1x) 0xcccccccc (2x)
7.2	0xcccccccc	0xdbdbdbdb
8.1	0xdbdbdbdb	0x6d6d6d6d
8.2	0x6d6d6d6d	0x6b6b6b6b
9.1	0x6b6b6b6b	0x0000000
9.2	0x00000000	-

Memory Retention VRAM Data Retention checks for gross problems with the VRAM refresh. Since refresh is active during this test, no retention problems should occur unless the refresh is defective.

This test turns off the video, writes 0's to all the VRAM, waits the specified memory_hold time (the default is 5 Seconds), then reads/compares all VRAM data. This process is repeated with data of f's, then the video is restored and the test is complete.

There are two new command line parameters related to this test, R=number and H=number. R= allows the user to specify the refresh interval from 128-1023. This is the time between refresh cycles and the system default is 123. H= allows the user to specify the retention test hold time in seconds.

Test Write Recovery A write recovery test will be used in all the EMC mapping modes to write data to 0's followed by immediately reading that data location to see if the VRAM can recover from a write correctly. This is done to all sequential ascending locations. Next, a second independent pass of memory is made with the complementary data of 0xffffffff being written to descending locations of the FB memory buffer.

The EMC mapping access modes are:

a. MDI_CHUNKY_XGBR_MAP b. MDI_CHUNKY_BGR_MAP c. MDI_PLANAR_X16_MAP d. MDI_PLANAR_C16_MAP e. MDI_PLANAR_X32_MAP f. MDI_PLANAR_B32_MAP g. MDI_PLANAR_G32_MAP h. MDI_PLANAR_R32_MAP

2.6.1.3 MDI Chip Cursor Registers (test group 3)

Cursor Plane 0 Register bits 31-0 w/r verify. Cursor Plane 1 Register bits 31-0 w/r verify. Cursor Plane 0 Register bits 31-0 w/r verify. (w/auto increment) Cursor Plane 1 Register bits 31-0 w/r verify. (w/auto increment) Cursor Control Register bits 2-0 w/r verify.

Cursor Color Register 1 bits 28-0 w/r verify. Cursor Color Register 2 bits 28-0 w/r verify. X-Cursor Location Register bits 11-0 w/r verify.

Y-Cursor Location Register bits 11-0 w/r verify. Cursor Plane 0 Non-Auto Registers test Cursor Plane 0 Auto Registers test

Cursor Plane 1 Non-Auto Registers test Cursor Plane 1 Auto Registers test Cursor Planes Retry A test

Cursor Planes Retry B test

2.6.1.4 MDI Chip Clut Registers (test group 4)

LUT1 Registers 0-255 bits 31-27 & 23-0 w/r verify. LUT1 Registers 0-255 bits 31-27 & 23-0 w/r verify. (w/auto increment) LUT1D Registers 0-255 bits 31-27 & 23-0 w/r verify.

LUT1D Registers 0-255 bits 31-27 & 23-0 w/r verify.(w/auto increment) LUT2 Registers 0-255 bits 31-27 & 23-0 w/r verify.

LUT2 Registers 0-255 bits 31-27 & 23-0 w/r verify. (w/auto increment) LUT2D Registers 0-255 bits 31-27 & 23-0 w/r verify.

LUT2D Registers 0-255 bits 31-27 & 23-0 w/r verify.(w/auto increment) LUT3 Registers 0-255 bits 31-27 & 23-0 w/r verify.

LUT3 Registers 0-255 bits 31-27 & 23-0 w/r verify. (w/auto increment) LUT3D Registers 0-255 bits 31-27 & 23-0 w/r verify.

LUT3D Registers 0-255 bits 31-27 & 23-0 w/r verify.(w/auto increment)

2.6.1.5 DAC Chip Registers (test group 5)

RAMDAC Registers Address Register bits 7-0 (0x7 maximum) w/r verify. Mode Register bits 7-0 (skip bit 5) bits w/r verify.

Control Registers ID Register bits 7-0 r/o verify data is 0x8C. Pixel-Mask Register bits 7-0 w/r verify. (skipped if dac rev = 2) Command2 Register bits 7-0 w/r verify. (skipped if dac rev = 2) Command3 Register bits 7-0 w/r verify. (skipped if dac rev = 2)

2.6.1.6 MDI Chip Xlut Registers (test group 6)

XLUT Registers 0-255 bits 7-0 w/r verify. XLUT Registers 0-255 bits 7-0 w/r verify. (w/auto increment) XLUTD Registers 0-255 bits 7-0 w/r verify.

XLUTD Registers 0-255 bits 7-0 w/r verify. (w/auto increment)

2.6.1.7 CG14 Display (visual only) (test group 7)

This visual displays 256 boxes on the screen (each in a different color), and then shifts the CLUT1 entries giving the visual impression of the pattern mirroring itself from left to right horizontally. The pattern then rotates up, down, followed by mirroring itself horizontally left to right.

2.6.1.8 MDI Chip Testmode Readback [TMRB] (test group 8)

---

Note - This test always runs in 8 bit mode, but it will also run in 32 bit mode if the Framebuffer size and resolution permit.

---

Test Mode Readback Register bits 23-0 r/o verify.

2.6.1.9 Driver IOCTRLs (test group 9)

• MDI_GET_CFGINFO check # of cluts, pixel height, pixel width, and pixel mode against h/w.
• FBIOGATTR check real_type, fb_height, fb_width, fb_depth, fb_cmsize, and fb_size against cfginfo values.
• FBIOGTYPE check fb_type, fb_height, fb_width, fb_depth,fb_size, and fb_cmsize against driver defines or cfginfo values.
• FBIOGVIDEO check status returned against h/w.
• FBIOSVIDEO set off, off, on, on, off verifying against h/w.
• FBIOVERTICAL (imbedded in FBIOSVIDEO use!)
• MDI_VRT_CNTL turn off, off, on, on, off the video interrupt enable and verify the h/w agrees.
• MDI_SET_PIXELMODE set different modes and verify against the h/w.
• MDI_SET_PPR set the different modes and verify against the h/w.
• MDI_SET_COUNTERS set HSS, HSC, XCC, HBC, XCS, HBS, CSC, VSS, VSC, VBC, VBS, HCT, and VCT then verify against h/w.
• MDI_GET_GAMMALUT check driver gammalut info against ramdac.

• MDI_SET_GAMMALUT write to driver then check against ramdac.
• MDI_SET_DEGAMMALUT set driver degammalut, then read the driver info and compare it to what was set.
• MDI_GET_DEGAMMALUT checked in conjunction with SET_DEGAMMALUT.
• MDI_GAMMA_CORRECT turn off, off, on, on, off the driver gamma correction and check against the diaginfo status.
• MDI_SET_XLUT set xlut and verify against h/w.
• MDI_GET_XLUT get xlut and verify against h/w.
• MDI_SET_CLUT set clut (1-3 as applicable) and verify against h/w.
• MDI_GET_CLUT get clut (1-3 as applicable) and verify against h/w.
• FBIOPUTCMAP set and verify clut1 matches.
• FBIOGETCMAP verify clut1 matches get.
• FBIOSATTR set emu_type to FBTYPE_MDICOLOR and verify with
• FBIOGATTR check.
• FBIOGCURMAX verify x and y size match driver defines.
• FBIOSCURSOR verify set at 3 locations matches h/w.
• FBIOGCURSOR verify driver knows what set(s) just did.
• FBIOSCURPOS verify set at 3 locations matches h/w.
• FBIOGCURPOS verify driver knows what set(s) just did.
• MDI_SET_CURSOR set then check CCR, XCU, and YCU cursor h/w registers.

2.6.2 cg14test Options

Figure 2-13 cg14test

2.6.2.1 FB Locking

See the "Special Note on Testing Multiple Framebuffers" section in Chapter 1 of the SunDiag User's Guide for details.

2.6.2.2 Long Test

If Long test is enable, the "color bar" screen(s), in the MDI Testmode Readback test, will check all SAM transfers in clock=0 mode and clock=1 mode. If Long test is disabled, clock=1 will run checks on the first 8 addresses and first SAM transfer only.

2.6.3 cg14test Command Line Syntax

/opt/SUNWdiag/bin/cg14test D=device L X Passes=x I R=x H=x T
standard_arguments

Arguments
D=device	Specify the path of the cg14 device file to be tested. For example: D=/dev/fbs/device_name
L	Disables window system locking option. See the "Special Note on Testing Multiple Framebuffers" in Chapter 1 of the SunDiag User's Guide for details. Do not use when device is the window system display.
X	Extra long TMRB test. Specify to run longer version of MDI readback. Note: The q option overrides this option.
Passes=x	x is the number of passes to run. The default is 1 pass.
I	Enable optional driver ioctl tests for cursor. Note: Do not the move mouse during the cg14test when this option is run.
R=x	Specify the time between refresh cycles (128-1023). The default is 123.
H=x	Specify the retention test hold time in seconds.
T	Logic analyzer trigger on TMRB/memory errors.

2.6.4 cg14test Quick Test Description

If the q (quick test) option from the standard arguments is specified, cg14test runs 1 minute faster, since the MDI readback test is skipped. All of the other test are run when q is invoked.

2.6.5 cg14test Error Messages

Error messages in cg14test specify the failing test name, including the chip and suspected faulty function. If DEBUG and VERBOSE modes are off, the end of the message contains a prioritized list of user-replaceable FRUs (Field Replaceable Units).

Note that the Visual checker pattern shifting test may not generate any error messages, and must be verified visually.

The following information is appended to the end of any error messages:

; *** suspected FRU(s)

followed by a sorted list containing any of the following FRUs for the specific failure:

• Operator error
• CG14 video board
• CPU board
• Video cable
• Video monitor
• CG14 device file
• SunOS^(TM)
• SunDiag
• Unsupported feature

2.6.5.1 Error Message List

---

Note - In all error messages below, n is a hexadecimal number.

---

MDI Chip Messages

MDI Master Control Register exp=0xnn obs=nn
MDI Packed Pixel Register exp=0xnn obs=nn
MDI H-Blank Start Register exp=0xnnnn obs=nnnn
MDI H-Blank Clear Register exp=0xnnnn obs=nnnn
MDI H-Sync Set Register exp=0xnnnn obs=nnnn
MDI H-Sync Clear Register exp=0xnnnn obs=nnnn
MDI C-Sync Clear Register exp=0xnnnn obs=nnnn
MDI V-Blank Start Register exp=0xnnnn obs=nnnn
MDI V-Blank Clear Register exp=0xnnnn obs=nnnn
MDI V-Blank Set Register exp=0xnnnn obs=nnnn
MDI V-Blank Clear Register exp=0xnnnn obs=nnnn
MDI Xfer-Cycle Set Register exp=0xnnnn obs=nnnn
MDI Xfer-Cycle Clear Register exp=0xnnnn obs=nnnn

MDI Fault Status Address Register exp=0xnnnn obs=nnnn
MDI Cursor Plane 0 Register 0xnn exp=0xnnnnnnnn
obs=nnnnnnnn
MDI Cursor Plane 1 Register 0xnn exp=0xnnnnnnnn
obs=nnnnnnnn
MDI X-Control Location Register exp=0xnnnn obs=nnnn
MDI Y-Control Location Register exp=0xnnnn obs=nnnn
MDI Control Color Register 1 exp=0xnnnnnnnn obs=nnnnnnnn
MDI Control Color Register 2 exp=0xnnnnnnnn obs=nnnnnnnn
MDI Cursor Control Register exp=0xnn obs=nn
MDI Cursor Plane 0 Non-Auto Register 0xnn exp=0xnnnnnnnn
obs=nnnnnnnn
MDI Cursor Plane 0 Auto Register 0xnn exp=0xnnnnnnnn
obs=nnnnnnnn
MDI Cursor Plane 1 Non-Auto Register 0xnn exp=0xnnnnnnnn
obs=nnnnnnnn
MDI Cursor Plane 1 Auto Register 0xnn exp=0xnnnnnnnn
obs=nnnnnnnn
MDI Cursor Planes Retry test maximum retry limit exceeded
MDI Clut1 Register 0xnn exp=0xnnnnnnnn obs=nnnnnnnn
MDI Clut1 Auto Register 0xnn exp=0xnnnnnnnn obs=nnnnnnnn
MDI Clut1 Diag Register 0xnn exp=0xnnnnnnnn obs=nnnnnnnn
MDI Clut1 Diag Auto Register 0xnn exp=0xnnnnnnnn
obs=nnnnnnnn
MDI Clut2 Register 0xnn exp=0xnnnnnnnn obs=nnnnnnnn
MDI Clut2 Auto Register 0xnn exp=0xnnnnnnnn obs=nnnnnnnn
MDI Clut2 Diag Register 0xnn exp=0xnnnnnnnn obs=nnnnnnnn
MDI Clut2 Diag Auto Register 0xnn exp=0xnnnnnnnn
obs=nnnnnnnn
MDI Clut3 Register 0xnn exp=0xnnnnnnnn obs=nnnnnnnn
MDI Clut3 Auto Register 0xnn exp=0xnnnnnnnn obs=nnnnnnnn
MDI Clut3 Diag Register 0xnn exp=0xnnnnnnnn obs=nnnnnnnn
MDI Clut3 Diag Auto Register 0xnn exp=0xnnnnnnnn
obs=nnnnnnnn
MDI Xlut Register 0xnn exp=0xnn obs=nn
MDI Xlut Auto Register 0xnn exp=0xnn obs=nn
MDI Xlut Diag Register 0xnn exp=0xnn obs=nn
MDI Xlut Diag Auto Register 0xnn exp=0xnn obs=nn

PCG Chip Message

MDI Pixel Clock Frequency %d is not supported
  where %d is an integer indicating the unsupported clock frequency.

VBC Chip Messages

VBC Video Base Register exp=0xnnnnnnnn obs=nnnnnnnn
VBC Control Register exp=0xnnnnnnnn obs=nnnnnnnn
VBC VCR Register, RRI value, exp=0xnnnnnnnn obs=nnnnnnnn

RAMDAC Chip Messages

DAC Address Register exp=0xnn obs=nn
DAC Mode Register exp=0xnn obs=nn
DAC Control ID Register exp=0xnn obs=nn
DAC Control Dac-Test Register exp=0xnnn obs=nnn
DAC Control Sync-Test Register exp=0xn obs=n
DAC Control Pixel-Mask Register exp=0xnn obs=nn
DAC Control Command2 Register exp=0xnn obs=nn
DAC Control Command3 Register exp=0xnn obs=nn
DAC CMAP Register red[0xnn] exp=0xnnn obs=nnn
DAC CMAP Register green[0xnn] exp=0xnnn obs=nnn
DAC CMAP Register blue[0xnn] exp=0xnnn obs=nnn

VRAM Chip Messages

MEM (%s), NTA %s offset= 0xnnnnnnnn exp=0xnnnnnnnn
obs=nnnnnnnn
MEM (%s), WRRD %s offset= 0xnnnnnnnn exp=0xnnnnnnnn
obs=nnnnnnnn
MEM (%s), Data Retention offset=0xnnnnnnnn exp=0xnnnnnnnn
obs=nnnnnnnn

where first %s can be one of the following:

CHUNKY_XBGR_MAPPED
CHUNKY_BGR_MAPPED
PLANAR_X16_MAPPED
PLANAR_C16_MAPPED
PLANAR_X32_MAPPED

PLANAR_B32_MAPPED
PLANAR_G32_MAPPED
PLANAR_R32_MAPPED

and second %s will be a pattern number for NTA (see Table 2-1) and indicate the direction (incremental or decremental) of writes for WRRD.

CG14 Driver IOCTL Messages

IOCTL(%r) %s

where:

Table 2-2 cg14test (1 of 3)

%r =	%s =
MDI_CFGINFO
MDI_DIAGINFO	"call failed, errno=%u" ; "number of cluts, exp 0x%x obs 0x%x" ; "pixel height, exp 0x%x obs 0x%x" ; "pixel width, exp 0x%x obs 0x%x" ; "unknown pixel mode, obs 0x%x" ; "pixel mode, exp 0x%x obs 0x%x
MDI_SET_PIXELMODE	"unable to set %d-bit mode" ;
MDI_SET_PPR	"ppr, exp 0x%x obs 0x%x" ;
MDI_SET_COUNTERS	"hss, exp 0x%x obs 0x%x" ; "hsc, exp 0x%x obs 0x%x" ; "hbc, exp 0x%x obs 0x%x" ; "hbs, exp 0x%x obs 0x%x" ; "vss, exp 0x%x obs 0x%x" ; "vsc, exp 0x%x obs 0x%x" ; "vbc, exp 0x%x obs 0x%x" ; "vbs, exp 0x%x obs 0x%x" ; "csc, exp 0x%x obs 0x%x" ; "xcs, exp 0x%x obs 0x%x" ; "xcc, exp 0x%x obs 0x%x" ;
MDI_SET_GAMMALUT MDI_GET_GAMMALUT	"red" ; "green" ; "blue" ;
MDI_GAMMA_CORRECTION	"gamma correction, exp 0x%x obs 0x%x" ;
MDI_SET_CLUT MDI_GET_CLUT MDI_SET_XLUT	"clut, offset 0x%x exp 0x%x obs 0x%x" ;

Table 2-2 cg14test (2 of 3)

%r =	%s =
MDI_GET_XLUT	"driver xbuf, offset 0x%x exp 0x%x obs 0x%x" ; "xlut, offset 0x%x exp 0x%x obs 0x%x" ;
FBIOGATTR FBIOGTYPE FBIOPUTCMAP	"type, exp 0x%x obs 0x%x" ; "height, exp 0x%x obs 0x%x" ; "width, exp 0x%x obs 0x%x" ; "cmap size, exp 0x%x obs 0x%x" ; "fb size, exp 0x%x obs 0x%x" ; "depth, exp 0x%x obs 0x%x" ; "real_type, exp 0x%x obs 0x%x" ;
FBIOGETCMAP FBIOSCURSOR	"red, offset 0x%x exp 0x%x obs 0x%x" ; "green, offset 0x%x exp 0x%x obs 0x%x" ; "blue, offset 0x%x exp 0x%x obs 0x%x" ;
FBIOGCURSOR FBIOSCURPOS FBIOGCURPOS	"set, exp 0x%x obs 0x%x" ; "enable, exp 0x%x obs 0x%x" ; "x hot position, exp 0x%x obs 0x%x" ; "y hot position, exp 0x%x obs 0x%x" ; "cmap index, exp 0x%x obs 0x%x" ; "cmap count, exp 0x%x obs 0x%x" ; "cmap red pointer, exp 0x%x obs 0x%x" ; "cmap green pointer, exp 0x%x obs 0x%x" ; "cmap blue pointer, exp 0x%x obs 0x%x" ; "cursor x size, exp 0x%x obs 0x%x" ; "cursor y size, exp 0x%x obs 0x%x" ; "image pointer, exp 0x%x obs 0x%x" ; "mask pointer, exp 0x%x obs 0x%x" ;
FBIOGCURMAX FBIOVERTICAL FBIOSVIDEO	"x position, exp 0x%x obs 0x%x" ; "y position, exp 0x%x obs 0x%x" ;

Table 2-2 cg14test (3 of 3)

%r =	%s =
FBIOGVIDEO	"video status, exp 0x%x obs 0x%x" ; "unknown video status, obs 0x%x" ;
MDI_VRT_CNTL	"vertical interrupt enable, exp 0x%x obs 0x%x" ;
MDI_GET_DEGAMMALUT MDI_SET_DEGAMMALUT	"degamma index mismatch" ; "degamma count mismatch" ; "degamma lut, offset 0xnn exp 0xnn obs 0xnn" ;
FBIOSATTR	"unable to set emu_type, exp 0x%x obs 0x%x" ;
MDI_SET_CURSOR	"cursor control reg, exp 0xnn obs 0xnn" ; "cursor enable, offset 0xnn exp 0xnnnnnnnn obs 0xnnnnnnnn"

VRAM/MDI Composite Chip Path Message

MDI chip TestMode ReadBack, %d-bit %s mode, offset= 0x%x
pixelpipe=%c clock=%e exp=0x%x obs=0x%x

where: %d is 8 or 32

%c is pipe A, B, C, or D, %x is a hexadecimal number. %e is 0 or 1,

%s is Greyscale, CLUT1, CLUT2, CLUT3, or Direct

2.7 Pixel Processor Test (sxtest)

This test checks models of SPARCstation 10 machines equipped with an on-board Pixel Processor module. sxtest is specific to the VSIMM (Video SIMM)/SX Memory Controller) devices in the SPARCstation 10 SX.

Warnings Because of possible conflicts between cg14 SunDiag framebuffer tests and OpenWindows applications that use the cg14 framebuffer, the following restrictions apply when running the sxtest SunDiag test:

• Do not run any graphic applications other than OpenWindows while the SunDiag software is running framebuffer tests
• Do not run any OpenWindows programs that generate video updates outside or on top of the SunDiag window
• Do not close the SunDiag window to an icon while it is running framebuffer tests
• Make sure to enable the framebuffer locking option from the Options window for the system console cg14 device (see "FB Locking" on page 2-64)
• If sxtest is run with its VRAM enabled, then framebuffer locking must also be enabled

2.7.1 sxtest Description

This test locates load error, store error, ALU error, logic error etc. of the Pixel Processor by reading and verifying data from the control registers of the Pixel Processor, virtual memories, or video memories. This test also verifies the integration function of the CG14 frame buffer and its device driver, video memories, and data memories. sxtest also writes a test pattern to the frame buffer for visual verification.

sxtest is a series of 16 modules, described below.

2.7.2 sxtest Options

Figure 2-14 sxtest

FB Locking See the "Special Note on Testing Multiple Framebuffers" section in Chapter 1 of the SunDiag User's Guide for details. Frame buffer locking is enabled by default on the window server running the OpenWindows software.

CMEM (Contiguous Memory) Choose either Enable or Disable. You must choose Disable if your system has less then 4 MBytes of contiguous memory available.

VRAM (Video Random Access Memory) Choose either to Enable or Disable the video random access memory.

---

Warning - If sxtest is run with its VRAM enabled, then framebuffer locking must be enabled or the SunDiag software will result in errors.

---

2.7.3 sxtest Module Descriptions

2.7.3.1 Display (Module0)

Click enable to display visual patterns.

3 subtests call the SPAM library and display pictures to verify the integrity of a subset of the kernel and the SPAM libraries via the SPARCstation 10 SX video system. These routines are ported from the SPAM demonstration programs. All subtests in this module are skipped if the cg14 frame buffer does not exist, or if the VRAM is disabled.

• rect_test -- The screen is filled with random rectangles. The rectangles are drawn in CHUNKY_XBGR mode if 32-bit mode OpenWindows is running. If not, they are drawn in CHUNKY_C8 mode with the SPAM library routine sl_rect_fill_32.
• shaa -- A picture of shaded lines is drawn in CHUNKY_BGR mode with the SPAM library routines sl_line_shaa_32, sl_span_load_8 and sl_rect_fill_8.

---

Note - The shaa test will be skipped if test is running on an 8 bit window.

---

• lines -- The screen is filled with lines of various colors. These lines are drawn in CHUNKY_XBGR mode if 32-bit mode OpenWindows is running; If not, they are drawn in CHUNKY_C8 mode with SPAM library routine sl_line_fill_8.

2.7.3.2 SMCALL (Module1)

Click enable for a brief test of all sxtest functionalities.

11 subtests are called from spam.smcall to verify the general function of the SMC chip. All subtests have a cg14 version and a non-cg14 version. These subtests will repeat four times, each time with the IQ FIFO programmed to a different number of entries (8, 16, 32, and 64).

• shift_ldst
• instr_mix *
• arith_ldst
• cmp_ldst
• select_ldst
• interlock_all *
• logic_ldst
• mult_ldst
• rop
• scat_ldst
• delt_ldst

---

* These subtests are skipped if the VRAM option is set to disable.

2.7.3.3 SMC (Module2)

Click enable to test sx instructions with VRAM page crossing.

17 subtests are called from spam.smc. The smc_pagex1 sub-tests verify spam_ldla instructions when effect addresses are crossing memory page. The smc_rampx sub-tests verify Ram Page Crossing Error logic with spam_ldla instructions. Both DRAM address space and all VRAM Mode address spaces are covered. All subtests have a cg14 version and a non-cg14 version.

Because 8 Mbyte VRAMs and 4 Mbyte VRAMs are assembled with different RAM chips, you must set the VRAM option correctly.

• smc_pagex1_0 *
• smc_pagex1_1
• smc_pagex1_2
• smc_pagex1_3
• smc_pagex1_4
• smc_pagex1_5
• smc_pagex1_6
• smc_pagex1_7

• smc_pagex1_8
• sp_pagex8_1 *
• sp_pagex9_1 *

---

* These subtests are skipped if the CMEM option is set to disable.

2.7.3.4 REGF (Module3)

Click enable to test the register file pointer logic.

22 subtests are called from spam.regfile to verify the register file's logic with assorted SPAM instructions.

• readpointer1 *
• readpointer2 *
• readpointer3 *
• readpointer4 *
• writepointer1 *
• writepointer2 *
• writepointer3 *
• writepointer4 *
• readpointer5 *
• writepointer5 *
• rdptr0 .
• wrptr0 .
• rdptr1 .
• wrptr1 .
• rdptr2 .
• wrptr2 .
• rdptr3 .
• wrptr3 .
• rdptr4 .
• wrptr4 .
• rdptr5 .
• wrptr5 .

---

* These subtests are skipped if the VRAM option is disabled.

. These subtests are skipped if the CMEM option is disabled.

2.7.3.5 Megacell (Module4)

Click enable to test basic ASIC cell elements.

8 subtests verify the megacell functionalities of SMC chip. Megacell is the basic cell for SMC chip. These subtests are converted with test vectors from LSI. All subtests have a cg14 version and a non-cg14 version.

• 16bitadder -- tests 16-bit adder in comp block.
• alu_adder1 -- tests 32-bit adder in comp block.
• alu_adder2 -- does delta operations.
• alu_comparator1 -- tests 32bit comparator in ADGEN.
• alu_shifter1 -- tests shifter in alu block.
• m16 -- tests 16 bit multiplier.
• registerfile_RR32X32M -- tests registerfile.
• registerfile_RR8X3207M -- tests write buffer. This subtest is skipped if VRAM option is set to disable.

2.7.3.6 MUL (Module5)

Click enable to test the multiplier operations.

8 subtests are called, and each subtest has 2500 randomly generated MUL SPAM macros. Each subtest tests SPAM MUL instruction sets by executing random SPAM MUL macro patterns. For example:

spam_dot(S_0,R42,R45,R31,5)
spam_mulr(L_16,R44,R29,R52,1)
spam_mul(S_15,R115,R114,R58,4)
spam_mul(L_16,R89,R110,R81,8)
spam_mulr(S_8,R21,R76,R53,1)
spam_saxpr(S_8,R54,R46,R98,2)
spam_dotr(L_16,R75,R40,R20,5)
spam_dot(L_16,R44,R45,R84,4)
spam_saxp(L_0,R93,R96,R44,8)
spam_mulr(L_0,R86,R56,R56,5)
spam_dotr(L_0,R14,R62,R40,2
spam_saxpr(S_15,R112,R85,R95,7)

• sp_mul0
• sp_mul1
• sp_mul2
• sp_mul3
• sp_mul4
• sp_mul5
• sp_mul6
• sp_mul7

2.7.3.7 ALU (Module6)

Click enable to test ALU operations.

5 subtests are called, and each subtest has 2500 randomly generated ALU SPAM macros. Each subtest tests SPAM ALU instruction sets by executing random SPAM ALU macro patterns. For example:

spam_subv(R101,R31,R42,1)
spam_subs(R90,R44,R90,14)
spam_subv(R44,R70,R29,14)
spam_sum(R58,R95,R114,9)
spam_adds(R54,R46,R98,10)
spam_addi(R9,51,R68,9)
spam_abs(R76,R28,7)
spam_addv(R80,R59,R93,11)

• sp_alu0
• sp_alu1
• sp_alu2
• sp_alu3
• sp_alu4

2.7.3.8 ROP (Module7)

Click enable to test the ROP operations.

5 subtests are called, and each subtest has 2500 randomly generated ROP SPAM macros. Each subtest tests SPAM ROP instruction sets by executing random SPAM ROP macro patterns. For example:

spam_selb(R101,R31,R42,1)
spam_ropl(R90,R27,R44,14)
spam_sels(R19,R16,R112,15)
spam_ropm(R47,R29,R96,16)
spam_selb(R52,R43,R29,5)
spam_ropb(R115,R114,R58,7)
spam_selv(R57,R75,R16,2)
spam_ropm(R110,R93,R83,13)

• sp_rop0
• sp_rop1
• sp_rop2
• sp_rop3
• sp_rop4

2.7.3.9 LOGIC (Module8)

Click enable to test the logical operations.

5 subtests are called, and each subtest has 2500 randomly generated LOGIC SPAM macros. Each subtest tests SPAM LOGIC instruction sets by executing random SPAM LOGIC macro patterns. For example:

spam_xors(R101,R31,R42,1)
spam_xori(R90,101,R90,14)
spam_xorv(R30,R19,R95,13)
spam_ands(R108,R16,R125,1)
spam_andv(R115,R114,R58,7)
spam_ors(R46,R89,R8,16)
spam_orv(R57,R75,R16,2)
spam_andi(R9,51,R68,9)

• sp_logic0
• sp_logic1
• sp_logic2
• sp_logic3
• sp_logic4

2.7.3.10 SHIFT (Module9)

Click enable to test the shift operations.

5 subtests are called, and each subtest has 2500 randomly generated SHIFT SPAM macros. Each subtest tests SPAM SHIFT instruction sets by executing random SPAM SHIFT macro patterns. For example:

spam_sllv(R101,R31,R42,1)
spam_slli(R90,5,R90,14)
spam_srai(R30,19,R95,13)
spam_srli(R108,16,R125,1)
spam_sllv(R52,R43,R29,5)
spam_slfi(R46,25,R8,16)
spam_slfs(R57,R75,R16,2)
spam_srav(R54,R44,R93,8)
spam_srlv(R58,R60,R96,16)

• sp_shift0
• sp_shift1
• sp_shift2
• sp_shift3
• sp_shift4

2.7.3.11 COMP (Module10)

Click enable to test the compare operations.

5 subtests are called, and each subtest has 2500 randomly generated COMP SPAM macros. Each subtest tests SPAM COMP instruction sets by executing random SPAM COMP macro patterns. For example:

spam_cmpv_gt(R101,R31,R42,1)
spam_cmps_lt(R90,R44,R90,14)
spam_cmps_eq(R95,R112,R19,12)
spam_cmpv_gt(R44,R43,R29,14)
spam_cmpv_lt(R115,R114,R58,7)
spam_cmps_gt(R46,R89,R8,16)
spam_cmps_eq(R57,R75,R16,2)
spam_cmpv_le(R54,R46,R98,10)
spam_cmpv_eq(R9,R51,R68,9)
spam_cmps_gt(R76,R103,R28,7)

spam_cmpv_eq(R52,R37,R50,8)
spam_cmpv_ge(R61,R86,R16,12)

• sp_comp0
• sp_comp1
• sp_comp2
• sp_comp3
• sp_comp4

2.7.3.12 MISC (Module11)

Click enable to test the miscellaneous operations.

5 subtests are called, and each subtest has 2500 randomly generated MISC SPAM macros. Each subtest tests SPAM MISC instruction sets by executing random SPAM MISC macro patterns. For example:

spam_scat(R45,-1,R29,1)
spam_gath(R95,-6,R114,9)
spam_delt(R89,R9,R16,16)
spam_plot(R54,R46,R98,10)
spam_plot(R53,R20,R75,16)
spam_scat(R91,-2,R70,9)
spam_gath(R120,-2,R51,15)
spam_delt(R59,R95,R120,1)

• sp_misc0
• sp_misc1
• sp_misc2
• sp_misc3
• sp_misc4

2.7.3.13 MADR (Module12)

Click enable to test the address lines of sx.

8 subtests are called; each subtests verifies 0x100000 SPAM address with spam_stld and spam_ldld instructions. All address bits and data bits of 4 MBytes of VRAM and 4 MBytes of DRAM will be tested after running through the 8 subtests.

• 0x00000000-0x000fffff
• 0x00100000-0x001fffff
• 0x00200000-0x002fffff
• 0x00300000-0x003fffff
• 0xfc000000-0xfc0fffff *
• 0xfc100000-0xfc1fffff *
• 0xfc200000-0xfc2fffff *
• 0xfc300000-0xfc3fffff *

---

* These subtests are skipped is the CMEM option is disabled.

2.7.3.14 MCNT (Module13)

Click enable to test the load and store functions with different repeat counts.

12 subtests are called; these test the SPAM store functions by varying address offset and item count.

• spsd_stba_cnt
• spsd_stbd_cnt
• spsd_stbds_cnt
• spsd_stcd_cnt
• spsd_stla_cnt
• spsd_stld_cnt
• spsd_stlds_cnt
• spsd_stpd_cnt
• spsd_stqd_cnt
• spsd_stsa_cnt
• spsd_stsd_cnt
• spsd_stsds_cnt

2.7.3.15 GRIF (Module14)

Click enable to test the graphic interface logic.

36 subtests are called; these test the SPAM graphic interface login with load/store instructions. All subtests are skipped if cg14 doesn't exist.

• spsd_stbd_dram
• spsd_stbd_xbgr
• spsd_stbd_bgr
• spsd_stbd_8x
• spsd_stbd_8c
• spsd_stbd_x32
• spsd_stbd_b32
• spsd_stbd_g32
• spsd_stbd_r32
• spsd_stsd_dram
• spsd_stsd_xbgr
• spsd_stsd_bgr
• spsd_stsd_8x
• spsd_stsd_8c
• spsd_stsd_x32
• spsd_stsd_b32
• spsd_stsd_g32
• spsd_stsd_r32
• spsd_ldbd_dram
• spsd_ldbd_xbgr
• spsd_ldbd_bgr
• spsd_ldbd_8x
• spsd_ldbd_8c
• spsd_ldbd_x32
• spsd_ldbd_b32
• spsd_ldbd_g32
• spsd_ldbd_r32
• spsd_ldsd_dram
• spsd_ldsd_xbgr
• spsd_ldsd_bgr
• spsd_ldsd_8x
• spsd_ldsd_8c
• spsd_ldsd_x32
• spsd_ldsd_b32

• spsd_ldsd_g32
• spsd_ldsd_r32

2.7.3.16 MRANDOM (Module15)

Click enable to test the random test store and load functions with different modes.

5 subtests are called; these test the SPM store/load functions by varying address offset and mode field. For example:

spam_stld(X,0x0,R32,32)
spam_ldld(0x60c,R64,32)
spam_stld(MP,0x810,R32,32)
spam_stld(PC,0xa14,R64,32)
spam_stld(SP,0x1020,R64,32)
spam_stld(M,0x1830,R64,32)
spam_stld(C,0x1c38,R64,32)
spam_stld(MC,0x2040,R32,32)
spam_stld(S,0x2244,R64,32)
spam_ldld(0x264c,R64,32)
spam_stld(C,0x2850,R32,32)
spam_stld(MPC,0x2a54,R64,32)

• sp_mem1
• sp_mem2
• sp_mem3
• sp_mem4
• sp_mem5

2.7.4 sxtest Command Line Syntax

/opt/SUNWdiag/bin/sxtest L mm=0xn np=#_of_passes nl=#_of_local_loops
sn=subtest# mn=module# fp=from_pass# tp=to_pass# fm=from_module# tm=to_module#
cmem=n vram=n standard_arguments

Arguments
L	Disables frame buffer locking. See the "Special Note on Testing Multiple Framebuffers" in Chapter 1 of the SunDiag User's Guide for details. Frame buffer locking is enabled by default on the window server running the OpenWindows software.
mm=0xn	Selects which modules will be tested in a pass. 0xn is a 16-bit hexadecimal number, where bit 0 represents module 0, and bit 15 represents module 15. For example, mm=0001 selects module vis, mm=0010 selects module 4, and mm=ffff selects all 16 modules.
np=#_of_passes	Use this option to run sxtest to a particular pass count, starting with zero passes.
nl=#_of_loops	Use this option to run sxtest to a particular loop count, starting with zero loops.
sn=subtest#	A particular subtest number.
mn=module#	Use mn in conjunction with sn to directly re-invoke the failed test at a specific pass and module number.
fp=from_pass#	Specifies a beginning pass number.
tp=to_pass#	Specifies an ending pass number.
fm=from_module#	Specifies a beginning module number.
tm=to_module#	Specifies an ending module number. Use these last four arguments to narrow sxtest to a specific test scope.
cmem=n	Choose either to enable or disable the contiguous memory. The possible values are 1 for enable or 0 to disable. Note: You must choose disable (0) if your system is equipped with less then 4 Mbytes of contiguous memory.
vram=n	Choose either to enable or disable the video random access memory. The possible values are 1 to enable or 0 to disable.

2.7.5 sxtest Quick Test Description

Specifying the q (quick test) option from the standard arguments causes sxtest to test only the Display and SMCALL subtests.

2.7.6 sxtest .usertest Example

The following is an example of sxtest as used in a.usertest file:

sx, sxtest, cmem=0, vram=0, nl=2

In this example, sxtest exercises all 16 modules, each with three different subtests.

2.7.7 sxtest Error Messages

SIGNATURE: lineno: 1917
mem crc16[chunky_xbgr+0x00000000,chunky_xbgr+0x003fffff]:
        o:0x5951 e:0x0356 o^e:0x5a07
mem ccitt[chunky_xbgr+0x00000000,chunky_xbgr+0x003fffff]:
         o:0x5fb9 e:0x1e7b o^e:0x41c2

loop_pass = 1, i_module =      megacell    4

lineno tells which line in the simulation program detected the comparison error. mem and chunky_xbgr indicate the problem in VRAM space.

• o = observed data pattern
• e = expected data pattern
• o^e = exclusive or of the observed data pattern and the expected data pattern

loop_pass indicates the failed loop pass number, and i_module identifies which module failed, including the module number.

If chunky_xbgr is replaced with dram then there is a problem with memory DRAM SIMM.

If mem is replace with reg, then there is a problem with register xx.

REGRD_DBL: lineno: 179 o:0x0000000c0xf3455350
e:0xe488a88d0xf3455350
  Read double registers error.

REGRD: lineno: 96 o:0x00000000 e:0x80000000

Read register error.

RD_BURST32

32 bytes burst read error.

RD_BURST64

64 bytes burst read error.

RD_BURST128

128 bytes burst read error.

2.8 S24 Frame Buffer Test (tcxtest)

Through a series of protocol, memory, acceleration, and colormap tests, tcxtest checks the functionality of the S24 Frame Buffer SBus card.

2.8.1 tcxtest Test Descriptions

tcxtest has four distinct test groups:

1. AFX Protocol Tests (in 8/16/32/64 bit mode)

• WRC

2. Frame Buffer Memory Tests (in 8/16/32/64 bit mode)

• address
• constant
• random

3. Acceleration Tests (both User and Raw modes)

• blit
• stip

4. Colormap and Cursor Tests

• cursor

2.8.1.1 tcxtest Sub-Test Descriptions

WRC By performing multiple writes and reads, and then verifying the results, the WRC test exercises the FIFO inside the S24 chip. The WRC test is composed of these three sub-tests: test_afx_alt_wr, test_memafx, and test_afx_random.

If these tests fail, they will print an error message showing the expected and observed data.

• test_afx_alt_wr

This test performs 16 writes to alternative pages (for example: WR (Page1), WR (Page2), WR (Page1+off), WR (Page2+off), etc.). It then reads back the data and compares it with the expected results.

This test also writes to the frame buffer space 16 times, followed by a write to a different page in the frame buffer space. The test then reads this data back and verifies it with the expected results.

• test_memafx

The CPU in the SWIFT chip has closely coupled interfaces for the DRAM and the AFX bus. This test checks the arbitration between the two accesses.

This test performs a number of alternating writes to the AFX and the CPU memory. After writing to different locations, the test reads and verifies the data. By performing an access across the page boundaries, the test covers both the cached and non-cached accesses.

• test_afx_random

After writing to one page in the DRAM memory, the test performs a few random writes/reads to random locations in the AFX space. The test then writes to a different page in the DRAM space, where it performs random accesses again.

This test does not perform any data verification, it just checks to see if any of these random accesses will cause a time out.

constant
The constant pattern test writes a data pattern to the whole memory. This
pattern is read back and compared with the expected data. Once the memory
fill operation is completed, the test reads the memory back and verifies that the
value read is correct.

address
The address pattern test writes a data pattern (which is same as the value of
the address) to the whole memory. This pattern is then read back and verified
that it is the correct value.

random The random pattern test writes a random data pattern to the whole memory. This pattern is read back and compared with the expected data. After the memory fill operation is completed, the test reads the memory and verifies the values read are correct.

blit The blit test has two parts, the raw blit test and the user blit test.

The raw blit test draws a 64x64x24 pixel image at the top left corner of screen. It then blits the image to the screen. The destination images are read back and compared with the original image to verify the raw blit operation executed correctly.

The user blit test draws a 64x64x24 pixel image at the top left corner of screen. It then blits the image to the screen. The destination images are read back and compared with the original image. The user blit test is the same as the raw blit test, except the user blit test uses the user data space for the blit command.

stip This test performs numerous corner cases for stipple. The test writes to the destination with different data values using a stipple operation. The destination data is read back and verified.

cursor This test performs a data register regression test. It writes a walking 1 pattern to the cursor data registers. The data is then read back and verified with the expected results. The test is repeated using a walking 0 as the data pattern.

2.8.2 tcxtest Options

Figure 2-15 tcxtest

2.8.2.1 FB Locking

Click to enable or disable Frame Buffer locking. See the "Special Note on Testing Multiple Framebuffers" section in Chapter 1 of the SunDiag User's Guide for details.

2.8.3 tcxtest Command Line Syntax

/opt/SUNWdiag/bin/tcxtest D=device_name L X=bit_mode T=test S=[dfb8, dfb24, dfb32] standard_arguments

Arguments
D=device_name	Specify the filename of the device to be tested. For example: D=tcx0
L	Disables frame buffer locking. See the "Special Note on Testing Multiple Framebuffers" in Chapter 1 of the SunDiag User's Guide for details. Frame buffer locking is enabled by default on the window server running the OpenWindows software.
X=bit_mode	Specify the data transfer size. The supported values are: 8..byte 16 short 32 long 64 double word
T=test	Specify a particular test. To specify an individual test, replace test with: a..Address c..Constant r..Random b..Blit s..Stipple h..Cursor w..WRC Note: When you select either the Blit or Stipple tests, both the user and raw mode tests will be executed.
S=[dfb8, dfb24, dfb32]	Specify which framebuffer memory space to use. dfb8 Dumb framebuffer 8 bit space. Memory is accessed only by bytes. dfb24 Dumb framebuffer 24 bit space. Memory is accessed only by 24 bit reads and writes. dfb32 Dumb framebuffer 32 bit space. Memory is accessed by 32 bit reads and writes.