VAX 6000 Models 300 and 400 Service Manual Order Number EK–624EA–MG–001 This manual is intended for Digital customer service engineers. It covers the (xyp) and (xrp) CPU options, the (xma2) memory, the (xrv) vector option, and the (xbi_plus) I/O adapter. This manual is to be used with the VAX 6000 Platform Service Manual.
First Printing, December 1990 The information in this document is subject to change without notice and should not be construed as a commitment by Digital Equipment Corporation. Digital Equipment Corporation assumes no responsibility for any errors that may appear in this document. The software, if any, described in this document is furnished under a license and may be used or copied only in accordance with the terms of such license.
Contents xiii Preface Chapter 1 Introduction 1.1 1.2 1.3 1.4 Why Read This Document . . . . . . . System Functional Description . . . Identifying the Platform Remotely . Troubleshooting Flowcharts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–2 1–4 1–6 1–8 Diagnostic Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 3 (xyp) Scalar Processor 3.1 KA62B Physical Description and Specifications . . . . . . . . . . . 3.2 (xyp) Configuration Rules . . . . . . . . . . . . . . . 3.3 KA62B Functional Description . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Boot Processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5 Power-Up Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6 (xyp) Self-Test Results: Console Display . . . 3.
4.10.1 Self-Test — RBD 0 . . . . . . . . . . . . . . . . . . 4.10.2 CPU/Memory Interaction Tests — RBD 1 4.11 VAX/DS Diagnostics . . . . . . . . . . . . . . . . . . . 4.12 Machine Checks . . . . . . . . . . . . . . . . . . . . . . 4.13 Console Commands . . . . . . . . . . . . . . . . . . . 4.14 (XRP) Handling Procedures 4.15 CPU Replacement in Single CPU Systems . . 4.15.1 Using the RESTORE Command . . . . . . . . 4.15.2 Using SET Commands . . . . . . . . . . . . . . . 4.
.5 6.6 6.7 6.8 6.9 6.10 6.11 6.12 6.13 6.14 System Interleaving Requirements . . . . . . . . MS65A Interleaving . . . . . . . . . . . . . . . . . . . . Console Commands for Interleaving . . . . . . . MS65A Addressing . . . . . . . . . . . . . . . . . . . . . Memory Self-Test . . . . . . . . . . . . . . . . . . . . . . Memory Self-Test Errors . . . . . . . . . . . . . . . . Memory RBD . . . . . . . . . . . . . . . . . . . . . . . . . Memory RBD Test Examples . . . . . . . . . . . . .
Appendix D Control Flags for Booting Glossary Index Examples 2–1 2–2 2–3 2–4 2–5 2–6 2–7 2–8 2–9 2–10 2–11 2–12 2–13 2–14 3–1 3–2 3–3 3–4 3–5 3–6 3–7 3–8 3–9 3–10 3–11 3–12 Sample Self-Test Results . . . . . . . . . . . . . . . . . . . . . . . START Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . RBD Test Printout, Passing . . . . . . . . . . . . . . . . . . . . . RBD Test Printout, Failing . . . . . . . . . . . . . . . . . . . . . SUMMARY Command . . . . . . . . . . . . . . . . . . . . .
3–13 4–1 4–2 4–3 4–4 4–5 4–6 4–7 4–8 4–9 4–10 4–11 4–12 4–13 4–14 5–1 5–2 5–3 5–4 6–1 6–2 6–3 6–4 6–5 6–6 7–1 viii Patching the EEPROM with EVUCA — Part 2 . . . . . . . . . . . ROM and EEPROM Version Numbers . . . . . . . . . . . . . . . . . . Self-Test Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XGPR Register After Power-Up Test Failure . . . . . . . . . . . . . Self-Test — RBD 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figures 1–1 1–2 1–3 2–1 3–1 3–2 3–3 3–4 3–5 3–6 3–7 3–8 4–1 4–2 4–3 4–4 4–5 4–6 4–7 4–8 4–9 4–10 (2X) System Architecture . . . . . . . . . . . . . . . Power-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Booting the Operating System . . . . . . . . . . . . . . . . . . . . . . . . Diagnostics Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . (XYP) Module . . . . . . . . . . . . . . . . . . . . . . . .
6–2 6–3 6–4 6–5 7–1 7–2 7–3 7–4 MS65A Configuration . . . . . . . . . . . . . . . . . . . MS65A Block Diagram . . . . . . . . . . . . . . . . . . Examples of Interleaving . . . . . . . . . . . . . . . . Memory Addressing . . . . . . . . . . . . . . . . . . . . (XBIA_TITLE) . . . . . . . . . . . (XBIB_TITLE) . . . . . . . . . . . VAX 6000 Slot Numbers . . . . . . . . . . . . . . . . . (XBI_TITLE) Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4–2 4–3 4–4 4–5 4–6 4–7 4–8 4–9 4–10 4–11 4–12 (XRP) Error LEDs . . . . . . . . . . . . . . . . . . XMI Base Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interpreting XGPR Failing Test Numbers . . . . . . . . . . . . . ROM-Based Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . (XRP) Self-Test — RBD 0 . . . . . . . . . . . . . CPU/Memory Interaction Tests — RBD 1 . . . . . . . . . . . . . (XRP) VAX/DS Diagnostics . . . . . . . . . . .
A–1 A–2 B–1 B–2 C–1 D–1 D–2 xii Model 300 Console Error Messages Indicating Halt . Model 300 Standard Console Error Messages . . . . . Model 400 Console Error Messages Indicating Halt . Model 400 Standard Console Error Messages . . . . . UPDATE Results on EEPROM Mismatches . . . . . . . R5 Bit Functions for VMS . . . . . . . . . . . . . . . . . . . . R5 Bit Functions for ULTRIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Preface The VAX 6000 Family The first product in this midrange multiprocessing VAX family is the (calypso). Second, the (hyperion) offered higher performance, with a faster processor and a more efficient console tape drive (TK70). The third CPU in the series is (rigel), which uses advanced technology for more enhanced performance. All models have two versions — a traditional multiuser timesharing system and a VAXserver for diskless computers and workstations.
This manual has seven chapters and five appendixes: • Chapter 1, Introduction, states why this manual is being written. It also describes how to tell what power and packaging variant you have from the console. • Chapter 2, Diagnostics, describes self-test, general methods for running ROM-based diagnostics, and diagnostics run under the VAX Diagnostic Supervisor. Refer to specific chapters for information on running diagnostics on CPUs, memory, and options.
VAX 6000 Series Documents These documents apply to all VAX 6000 systems. Title Order Number VAX 6000 Series Installation Guide EK–600EA–IN VAX 6000 Series Owner’s Manual EK–600EA–OM VAX 6000 Platform Service Manual EK–600EA–MG VAX 6000 Series Platform Technical User’s Guide EK–600EA–TM VAX 6000 Models 200 and 300 Documents These documents should be used for systems shipped before the VAX 6000 Model 500.
Associated Documents Other documents that you may find useful include: Table 1: Associated Documents Title Order Number System Hardware Options VAXBI Expander Cabinet Installation Guide EK–VBIEA–IN VAXBI Options Handbook EB–32255–46 System I/O Options CIBCA User Guide EK–CIBCA–UG CIXCD Interface User Guide EK–CIXCD–UG DEBNI Installation Guide EK–DEBNI–IN DEClancontroller 400 Installation Guide EK–DEMNA–IN InfoServer 100 Installation and Owner’s Guide EK–DIS1K–IN KDB50 Disk Controller User’s
Table 1 (Cont.
Chapter 1 Introduction With the introduction of the VAX 6000 Model 500 several changes were made to improve the platform in which the various VAX 6000 models reside. This chapter discusses the changes between the XMI-1 and XMI-2 platforms.
1.1 Why Read This Document The VAX 6000 series platform has changed to accommodate features of the VAX 6000 Model 500. Several XMI I/O adapters are also now available and can be installed in any XMI card cage. A new power regulator, capable of providing enough current at +3.3 volts for the VAX Model 500, is inhibited in the H9657 cabinet for Models 300 and 400. A more powerful battery backup unit (BBU) option, capable of providing power to the entire backplane, is available.
Table 1–1 shows the major differences between the two platforms. Although this manual does not cover the differences in detail, it does cover the (2x) systems, the (xma2), and the DWMBB in the XMI-2 cabinet. Other documentation covers upgrades (see preface). Power is distributed differently in the XMI-1 and XMI-2 backplanes. Therefore, power considerations are important when servicing these systems. Care must be exercised when replacing broken modules because of incompatibilities.
1.2 System Functional Description The (2X) systems support multiprocessing with up to six (xyp) or (XRP) processors. The system uses a high-speed (XMI) system bus to connect its processors, its memory modules, and its I/O adapters.
(XMI) has three types of nodes: processor nodes, memory nodes, and I/O adapter nodes. A processor node, consists of a single-board VAX processor. It contains a central processor unit (CPU) chip, a floating-point processor, a primary and secondary cache, a writable EEPROM for system parameters, and a communication path to the XMI bus. The (XRP) has a chip that communicates with an optional vector processor. Processors communicate with main memory over the (XMI).
1.3 Identifying the Platform Remotely Section 1.1 explained how to identify the platform by inspection. However, persons diagnosing systems remotely will want to be able to identify system power. While there is no foolproof method to do this on these systems, the method given below should work in almost all cases. Examples of Power Identification Using Show Configuration 1. 2.
3. >>> SHOW CONFIGURATION Type Rev 1+ (XRP) (8082) 0007 2+ (XRP) (8082) 0007 8+ MS65A (4001) 0084 9+ MS65A (4001) 0084 B+ KDM70 (0C22) 1811 D+ CIXCD (0C05) 1611 E+ DEMNA (0C03) 0600 !Likely an XMI-2 system System configuration provides clues to help identify the power and packaging of (hyperion) and (rigel) systems. The examples show output from a SHOW CONFIGURATION command on three systems. System 1.
1.4 Troubleshooting Flowcharts These flowcharts reference sections in this manual. Figure 1–2: Power-Up POWER ON NO SEE CHAPTER 5 IN CONSOLE PROMPT >>> VAX 600 PLATFORM SERVICE MANUAL. YES CHECK SELF-TEST RESULTS FOR ALL MODULES SEE SECTION 2.
A VECTOR PROCESSORS PASS NO SEE CHAPTER 5 YES MEMORY MODULES PASS NO SEE CHAPTER 6 YES I/O ADAPTERS PASS NO SEE CHAPTER 7 OR SPECIFIC I/O SERVICE MANUAL YES BOOT THE SYSTEM BOOT YES ERROR STATUS CODES SEE APPENDIXES A AND B NO SYSTEM BOOTS msb-0723D-90 Introduction 1–9
Figure 1–3: Booting the Operating System BOOT OPERATING SYSTEM MACHINE CHECK OCCURS LOCATE LENGTH OF FRAME (00000018) ON INTERRUPT STACK LOCATE LENGTH FRAME +4 LOW WORD CONTAINS MACHINE CHECK CODE CODE NOT EQUAL TO 14 YES SEE SECTION 3.8 FOR KA62B AND SECTION 4.10 FOR KA64B NO YES CODE = 14 SEE THESE SECTIONS 3.10 - KA62B 4.12 - KA64A 5.
Chapter 2 Diagnostics This chapter describes diagnostics for the VAX 6000 Model 300 and 400 systems.
2.1 Diagnostic Overview The (6000) systems are tested with two types of diagnostics: ROM-based and loadable. The ROM-based diagnostics (RBD) include self-tests, additional power-up tests, and callable diagnostics (from the RBD monitor). The loadable diagnostics run under the VAX Diagnostic Supervisor (VAX/DS) in standalone mode or in user mode (see Figure 2–1).
Self-Tests Each module on the (XMI) and VAXBI buses has its own self-test resident in ROM, except for the now optional (xbi_ plus) modules. At power-up, initialization, booting, or system reset, each module runs its own self-test. The processor self-test completes within 10 seconds. The memory test completes in less than 60 seconds. Results of self-test are printed on the STF line of the console self-test display.
2.2 Self-Test and Additional Power-Up Tests The self-test diagnostics reside in ROM on the processors and on most modules. These diagnostics check each module at power-up, when the system is reset, and during a boot. Self-test results are written to the console terminal, as shown in Example 2–1. Example 2–1: Sample Self-Test Results #123456789 0123456789 0123456789 01234567# ! Trace for KA64A in slot 1 F . E D C B A 9 8 7 6 5 4 3 2 1 A o . . . A + . . . . . . . . . . . . . M + . . .
Self-test is invoked and results are written to the console under several circumstances: • At power-up • When the control panel Restart button is pressed • During a boot • When the console command INITIALIZE is issued On a (rigel) the first line of the self-test printout is the progress trace. This line indicates how the (XRP) at node 1 is functioning during self-test. If there is no processor in node 1, no trace appears. The remainder of the printout is the self-test display.
ROM = 6.0 2–6 EEPROM = 2.0/6.
2.3 ROM-Based Diagnostic Monitor and Its Control The ROM-Based Diagnostic Monitor program is accessed through the console program. Type T/R at the console prompt to enter RBD mode. RBD mode has three commands with qualifiers and a set of control characters that assist the user when entering commands or running tests.
To enter the RBD monitor, at the console prompt type: >>> T/R RBDn> ! ! ! ! ! This is the abbreviation for TEST/RBD. Early versions of the console only accept T/R. RBD prompt appears signifying entrance into RBD mode, where n is the XMI node number of the processor running the RBD monitor program. The RBD commands are explained here and in Sections 2.3.2 and 2.3.6. Table 2–2 gives the commands, their abbreviations, and functions. Four programs run from the ROM-based diagnostics (RBD) monitor program.
2.3.1 ROM-Based Diagnostic Programs Table 2–4 and Table 2–5 lists the diagnostic programs available for both VAX 6000 Model 300 and Model 400 systems.
Table 2–4 and Table 2–5 show the number of tests available. Column 1 contains the numbers used to invoke the test in RBD mode. RBD2> ST1 !Starts the CPU memory interaction test The second column gives the total number of tests in the RBD. The third column indicates that there may be some tests not run during power up, and the fourth column indicates the number of test run when the RBD is invoked by the START command with no qualifiers. All tests may be run.
To exit RBD mode, type QUIT at the RBD prompt.
2.3.2 START Command The RBD monitor START command invokes a specific RBD program. It takes an argument indicating the RBD program to be run, and can take any of 13 qualifiers. Example 2–2: START Command >>> T/R ! Command to enter RBD monitor program. RBD3> ! RBD monitor prompt, where 3 is the hexa! decimal node number of the processor ! that is currently receiving your input. RBD3> ST2/TR E ! Runs the default XBI tests, testing the ! (xbi_plus) at (XMI) node number E.
2.3.3 START Command Qualifiers The START command is the primary RBD program command. Its qualifiers act as switches, allowing you to control the output of the tests—to run portions of a test, to run nondefault tests, and to loop on tests.
/C enables execution of destructive tests. See Example 2–7 and Section 6.11 for information on the destructive tests. /DS disables printout of the diagnostics test results. The summary report is run, unless it is specifically disabled. /HE halts on hard error and stops execution of tests as soon as the first hard error is encountered. (In this context, a hard error is defined as a recoverable, repeatable error, for example, a ROM checksum error.
with the /T=n:m qualifier, you run a range of tests. To terminate /P=n, enter CTRL/C, CTRL/Z, or CTRL/Y. After entering one of these control characters, a summary reports prints out and the RBD monitor prompt returns. /QV selects the quick verify version of any selected test that supports this mode. /T=n[:m] selects individual tests (/T=n) or a range of tests (/T=n:m) where n and m are decimal numbers. For example, to run tests T0005 through T0008, use /T=5:8.
2.3.4 RBD Test Printout, Passing The RBD printout results are different when the RBD tests pass and when they fail. Example 2–3 shows a passing printout, and Example 2–4 is a sample failure printout. Example 2–3: RBD Test Printout, Passing >>> T/R ! ! ! ! ! RBD3> RBD3> ST2/TR E ! Runs the XBI self-test, testing the (xbi_plus) ! at (XMI) node number E.
3 These T00nn fields appear only with the /TR qualifier; each entry corresponds to a test being run and prints out as the test starts running. In a passing RBD, the final T00nn number corresponds to the last test run. Note that T0002 through T0004 and T0010, T0011, and T0026 are not executed. These tests are not part of the default selection and must be individually invoked by qualifier. For a list of the tests for each RBD and the definition of the tests, see the chapter for each module in this manual.
2.3.5 RBD Test Printout, Failing The RBD printout results are different when the RBD passes and when it fails. Example 2–4 is a sample failure printout, and Example 2–3 shows a passing printout. Example 2–4: RBD Test Printout, Failing >>> T/R ! ! ! ! ! ! RBD2> RBD2> ST0/TR ; XRP/V_ST ; T0001 ; T0011 T0002 T0012 Command to enter RBD monitor program at console prompt. RBD monitor prompt, where 2 is the hexadecimal node number of the processor that is currently receiving your input.
4 This field is the device type of the boot processor. 5 This field displays the total number of passes (in decimal) executed by the RBD. The default number of passes is 1. 6 The class of error is displayed here. HE indicates that the error was a hard error. SE means the error was a soft error, and FE indicates a fatal error. (See Section 2.3.3 for a definition of these errors.
2.3.6 SUMMARY Command The RBD monitor SUMMARY command displays a summary of the last diagnostic run. Example 2–5: SUMMARY Command >>> T/R RBD1> ST0/IE/IS/P=100 ; XRP/V_ST Command to enter RBD monitor program at console prompt. Execute RBD 0 (CPU test), inhibiting error outputs and summary report. 3.00 RBD1> SU ; XRP/V_ST ! ! ! ! ! Request a summary. 3.
The callouts in Example 2–5 are explained below. 1 This field indicates whether the RBD passed or failed; P for passed, F for failed. 2 This field is the XMI node number of the boot processor executing the RBD. It will match the number in your RBD prompt, which also indicates the node number of your boot processor. 3 This field is the device type number of the boot processor executing the RBD. 4 This field displays the total number of passes executed by the RBD.
2.3.7 Sample RBD Session Examples 2–6 and 2–7 show a sample RBD session. Example 2–6: Sample RBD Session, Part 1 of 2 >>> T/R 1 RBD1> ST0/TR 2 ;XRP/V_ST 3.
1 Enter RBD mode from console mode. The RBD prompt appears and indicates you are operating from the boot processor at node 1. 2 Run RBD 0 and trace the tests. successfully. 3 Run RBD 1, trace it and halt on the first error found. All CPU/memory interaction RBD tests run and pass. 4 Run RBD 2, testing the DWMBB at XMI node 5. The value NO_UNIT on the third line of output indicates that the node value of node 5 is not correct; no DWMBB was found at this node.
Example 2–7: Sample RBD Session, Part 2 of 2 RBD1> ST3/TR/T=1 6 RBD1> ST3/TR/T=1 RBD1> ST3/TR/T=1 /C 7 ;XMA_RBD 3.00 ; T0001 ; P 1 8082 1 ;00000000 00000000 00000000 00000000 000000000 00000000 00000000 RBD1> QU 8 [self-test results may be displayed here] >>> SET CPU 2 9 >>> T/R RBD2> ST0/TR 10 ;XRP/V_ST 3.
6 Run RBD 3, trace it, and run only test 1 of this RBD. This test is one of the memory tests that is not part of the default suite of tests. Test 1 corrupts memory. You must add a /C qualifier (Confirm) to the START command, to indicate that you do indeed intend to run this destructive test. The /C qualifier was not given in this example. The command line is echoed, waiting for /C to be typed.
2.3.8 Running ROM-Based Diagnostics on VAXBI Devices Some VAXBI devices can be tested from the console terminal with their on-board ROM-based diagnostics. The Z console command is used to send commands to these VAXBI nodes.
Example 2–8 (Cont.): VAXBI RBD Session ; T01 ; T15 T02 T16 T03 T17 T04 T05 T06 T07 T08 T09 T10 T11 T12 T13 T14 ; P 8 410B 00000001 ;00000000 00000000 00000000 00000000 00000000 00000000 00000000 ; PUDR: 5FF43FDF RBD5> QUIT ^P ?31 Z connection terminated by ^P >>> The callouts in Example 2–8 are explained below.
2.4 VAX Diagnostic Supervisor Programs The VAX Diagnostic Supervisor (VAX/DS) is a monitor that controls operation of a diagnostic program. You can use VAX/DS in one of two modes: standalone mode (exclusive use of the system) or user mode (under the VMS operating system).
The VAX Diagnostic Supervisor (VAX/DS) can be run in interactive mode. You type commands in response to the VAX/DS program prompt: DS> VAX/DS lets you load diagnostic programs into system memory, select devices to be tested, and run the programs. The VAX/DS command language also lets you control the execution of diagnostic programs; you can specify which tests or sections of a program should run, and how many passes it should run.
2.4.1 Booting the Diagnostic Supervisor from a CD Server To boot the Diagnostic Supervisor from a CD server, set an additional control flag in R5 and enter ISL_LVAX at the filename prompt.
Example 2–9 (Cont.): Booting the Diagnostic Supervisor over the Ethernet #2 NSS_SYSDISK ESS_08002B15FCE1 08-00-2B-15-FC-E1 #3 6000_DIAG_A ESS_08002B15FCE1 08-00-2B-15-FC-E1 Enter a number =>3 5 [Diagnostic Supervisor Banner prints] DS> After placing a CDROM cartridge labeled 6000_DIAG_* in a CD server on the network, your system can access and boot the Diagnostic Supervisor from the Ethernet. 1 At the console prompt enter a boot command identifying a path to the CD server.
2.4.2 Running VAX/DS You can use VAX/DS in one of two modes: standalone mode (exclusive use of the system) or user mode (under VMS). There are several methods of booting the VAX/DS in standalone mode any one of which can be used. Section 2.4.1 shows one, Example 2–10 shows another, and Example 2–12 shows a third.
Example 2–11: Running VAX/DS in User Mode $ ! At the operating system prompt, run $ RUN ERSAA ! the VAX/DS program. [VAX/DS banner prints, as in example above] DS> ! VAX/DS prompt appears. ! Run VAX/DS level 2R or 2 programs. DS> EXIT ! Type EXIT to exit VAX/DS $ ! Operating system prompt returns. Table 2–7 describes the levels of VAX/DS programs. Check Table 2–9 for the programs you wish to run, and determine if you will run VAX/DS in standalone or user mode.
2.4.3 Sample VAX/DS Session When you run the VAX/DS programs, run the system autosizer program EVSBA first. This program, which takes several minutes to execute, will save you time as you proceed with other tests. Certain conditions cause the generation of an unexpected trap or interrupt. Use the method shown to avoid these conditions.
1 The SET BOOT command stores a nickname for a set of parameters to the BOOT command. (The lower key switch on the control panel must be set to Update when this command is issued.) This BOOT command loads VAX/DS from disk. Alternatively, you can use the command BOOT/R5:10 CSA1 if you have a TK70 as a load device, or you can boot over the Ethernet from a CD server. For more information on the BOOT and SET BOOT commands, see any of the VAX 6000 Owner’s Manuals.
Example 2–13: Sample VAX/DS Session, Part 2 of 3 DS> SHOW DEV 3 _DWMBB1 BI Node _DUA _DJA23 _KA0 _KA1 _DWMBB0 BI Node _TXA _ETA0 _DUA2 _DUA61 _DUA _MUA0 DS> DS> DS> DS> DWMBB HUB 61F00000 Number (HEX)=00000001(X) KDB50 _DWMBB1 7C008000 RA60 _DUA 7C500000 (XRP) HUB (XRP) HUB DWMBB HUB 61E80000 Number (HEX)=00000001(X) DMB32 _DWMBB0 7A00A000 DEBNI _DWMBB0 7A00A000 RA82 _DUA 7C500000 RA82 _DUA 7C500000 TBK70 _DWMBB1 7C00C000 TK70 _DUA 7C580000 XMI node # (1,2,3,4,B,C,D,E) =0000000E(X) B
3 The autosizer builds a table of devices for VAX/DS that can be printed by using the SHOW DEVICE/BRIEF command at the DS> prompt. The command lists system devices, similar to the SHOW CONFIGURATION command in console mode. 4 When preparing to run a diagnostic, the SELECT ALL command selects all devices listed in 3 and the SET TRACE command enables printing of test numbers and names when the diagnostic runs.
Example 2–14: Sample VAX/DS Session (Model 400 Only), Part 3 of 3 >>> CLEAR EXCEPTION 6 XBER = 00000041 ! no error bits set XFADR = 61880008 ! no error bits set RCSR = 01240001 ! no error bits set >>> SHOW CONFIGURATION 7 Type Rev 1+ KA64A (8082) 0007 3+ KA64A (8082) 0007 A+ MS65A (4001) 0002 B+ MS65A (4001) 0002 E+ DWMBB/A (2002) 0001 XBI 1+ 2+ 4+ 5+ 6+ 8+ E DWMBB/B CIBCA KDB50 DMB32 TBK70 DEBNI (210F) (0108) (010E) (0109) (410B) (0118) 000A 41C1 0F1C 210B 0307 0100 >>> CLEAR EXCEPTION 8 XBER = 8001B04
6 The CLEAR EXCEPTION command prints the contents of three registers (XBER, XFADR, and RCSR) and then clears their error bits, if set. No error bits have been set at this point. 7 The SHOW CONFIGURATION command attempts to examine unused address space, creating errors. 8 Issuing the CLEAR EXCEPTION command again shows the contents of the three registers with error bits set. These error bits are then cleared by the command.
2.4.4 VAX/DS Diagnostics Table 2–9 lists the VAX Diagnostic Supervisor tests available for both Model 400 and Model 300 systems.
Table 2–9 (Cont.
Table 2–9 (Cont.
Table 2–9 (Cont.
Table 2–9 (Cont.
Table 2–9 (Cont.
Chapter 3 (xyp) Scalar Processor This chapter contains the following sections: • KA62B Physical Description and Specifications • Configuration Rules • Functional Description • Boot Processor • Power-Up Sequence • (xyp) Self-Test Results: Console Display • (xyp) Self-Test Results: Module LEDs • ROM-Based Diagnostics (xyp) Self-Test RBD CPU/Memory Test RBD Second-Level Cache RBD • VAX/DS Diagnostics • Machine Checks • Console Commands • CPU R
3.1 KA62B Physical Description and Specifications The (xyp) is a single-module VAX processor based on a single CPU chip and a floating-point accelerator chip. The module designation is T2011-YA. Features of the module are shown in Figure 3–1.
Table 3–1: KA62B Specifications Parameter Description Module Number: T2011-YA Dimensions: 23.3 cm (9.2") H x 0.6 cm (0.25") W x 28.0 cm (11.0") D Temperature: Storage Range Operating Range -40o C to 66o C (-40o F to 151o F) 5o C to 50o C (41o F to 122o F) Relative Humidity: Storage 10 to 95% noncondensing Operating 10 to 95% noncondensing Altitude: Storage Up to 4.8 km (16,000 ft) Operating Up to 2.4 km (8000 ft) Current: 8.
3.2 (xyp) Configuration Rules The (xyp) module will operate in any slot. Processors usually go on the right, beginning with slot 1. The maximum number of (xyp)s in a (hyperion) is six.
By convention, processors are placed in the right (XMI) slots, beginning with slot 1. Memories are placed in the middle slots, from slot A to slot 5 and then slots B and C. A VAXBI adapter, if installed, occupies slot E. If a processor is failing intermittently and you are working on a system remotely, you may want to leave the module in the system temporarily and prevent the operating system from using that processor. To disable a CPU: 1. Enter console mode. 2.
3.3 KA62B Functional Description The (xyp) processor has four functional sections (see Figure 3–3): the CPU section, the second-level cache, the XMI interface, and the console and diagnostics sections.
The CPU section includes: • The CVAX processor chip, which supports the VAX Base Instruction Group and data types. It has full VAX memory management including demand paging and 4 Gbytes of virtual memory. The CPU chip includes the first-level cache, for I-stream (instruction) storage only. First-level cache is 1 Kbyte, organized with 128 tags. Cache is write-through, two-way associative, and is filled eight bytes at a time.
Example 3–1: ROM and EEPROM Version Numbers F . E D C B A 9 8 7 6 5 4 3 2 1 A o . . . . . . . . A + . . . . . . . . M + . . . M + . . . M + . . . M + . . . . . . . . . . . . . P + E + E P + E + E P + E + E P + B + B . . . . . . . . + . + . + + . . . . . . . . A4 64 A3 64 A2 64 A1 64 . . . . . . . . . . . . ROM = 6.0 1 3–8 EEPROM = 2.0/6.1 2 3 SN = SGO1234567 VAX 6000 Models 300 and 400 Service Manual 0 NODE # TYP STF BPD ETF BPD .
The console and diagnostics sections include: • A console read-only memory (ROM). This ROM contains code to initialize and boot the system and execute console commands. The last line of the self-test display shows the ROM version. In this example, the callout 1 indicates that the console ROM is version 6.0. • A diagnostic ROM, which contains the power-up self-test and extended diagnostics. The diagnostic ROM has the same version number as the console ROM 1 .
3.4 Boot Processor The (hyperion) system is designed so that all processors share system resources equally. Because only one processor can boot the system or use the console at any given time, this processor is designated the primary or boot processor. The others are called secondary processors. The boot processor is selected during the power-up sequence.
Using boot code stored in its EEPROM, the boot processor reads the boot block from a specified device. Booting may be triggered by a command issued to the boot processor from the console, or by a system reset with the bottom key switch in the Auto Start position. The boot processor also communicates with the system console, using the common console lines on the backplane.
3.5 Power-Up Sequence Figure 3–5 shows the power-up sequence for (xyp) processors. All processors execute two phases of self-test, and a boot processor is selected. The boot processor tests VAXBI adapters, if present, and prints the self-test display. Figure 3–5: (xyp) Power-Up Sequence, Part 1 of 2 Power-up or system reset (cold) 1 2 CPU 1 Self-Test CPU 2 Self-Test Determine Boot Processor CPU n Self-Test ... ... Determine Boot Processor CPU 2 CPU/MEM tests ...
1 All CPUs execute their on-board self-tests at the beginning of the powerup tests. On the STF line of the self-test display, a plus sign (+) is shown for every module whose self-test passes (see Section 3.6). 2 The boot processor is determined as described in Section 3.4. On the first BPD line, the letter B corresponds to the processor selected as boot processor.
Figure 3–6: (XYP) Power-Up Sequence, Part 2 of 2 A 6 Boot Processor prints CPU/MEM test results 7 Boot Processor executes DWMBB tests Boot Processor prints DWMBB test results Boot Processor halts in console mode or boots operating system If Boot Processor is booting operating system, starts all attached CPUs after boot processor has booted CPU 1 running CPU 2 running ...
6 The boot processor prints the ETF line and the second BPD line of the self-test display. If none of the processors is successfully selected as the boot processor, no self-test results are displayed and the console hangs. You can identify this hung state by examining the LEDs on the processor modules (see Section 3.7). All yellow LEDs will be OFF. The group of six red LEDS will flash two alternate patterns, and in one pattern only the bottom light will be ON.
3.6 (xyp) Self-Test Results: Console Display You can check the (xyp) self-test results both in the self-test display and in the lights on the module. Pertinent information in the self-test display is shown in Example 3–2. Example 3–2: Self-Test Results F . E D C B A 9 8 7 6 5 4 3 2 1 A o . . . . . . . . A + . . . A + . . . M + . . . M + . . . M + . . . M + . . . . . . . . . . . . . P + E + E P + E + B P + D + D P + B E . . . . + + . . + . + .
1 The second line in the self-test display indicates the type (TYP) of module at each (XMI) node. Processors are type P. In this example, processors are at nodes 1, 2, 3, and 4. 2 The third line shows self-test fail status (STF), which are the results of on-board self-test. Possible values for processors are: + (pass) – (fail) All processors passed self-test in this example. 3 The BPD line indicates boot processor determination.
3.7 (xyp) Self-Test Results: Module LEDs You can check (XYP) self-test results both in the self-test display and in the lights on the module. As shown in Figure 3–7, if self-test passes, the large yellow LED is on.
Figure 3–7: (xyp) LEDs After Power-Up Self-Test SELF-TEST PASSED SELF-TEST FAILED MOST SIGNIFICANT BIT ALL OFF RED ALL OFF RED OFF ON ON ON YELLOW BOOT CPU SECONDARY CPU TEST NUMBER (BINARY) ON OR OFF OFF msb-0052-88 (xyp) Scalar Processor 3–19
NOTE: The two processors in this book have different LED patterns. Refer to Section 4.7 for interpreting (XRP) LEDs. The large yellow LED at the bottom of the LED array is ON if self-test passes and OFF if self-test fails. (Here self-test means both the on-board power-up test and the extended CPU/memory test.) On the boot processor module, the red LED next to the yellow is OFF. This LED, which is controlled by the SSC chip, is ON on all the secondary processors.
Processor error LEDs can also indicate failures of memories or VAXBI adapters.
If a processor’s yellow LED is OFF and the six red LEDs show an error code in the range 1–22 (hex), the power-up self-test failed and the processor board is bad. On the self-test console display, the processor shows a minus sign (–) on the STF line. After the power-up tests, each processor runs the CPU/memory tests. If a test fails, the processor shows a minus sign (–) on the ETF line of the selftest console display.
3.8 ROM-Based Diagnostics The (xyp) ROM contains five diagnostics, which you run using the boot processor’s RBD monitor program described in Chapter 2. RBD 0, 1, and 4 test the boot processor. RBD 2 tests VAXBI adapters, and RBD 3 tests memories.
RBD 0 is the same as the power-up self-test. It is useful for running several passes when a processor fails self-test intermittently. Section 3.8.1 shows an example and lists the tests. RBD 1 is the same as the extended CPU/memory test. It is useful for running several passes when a processor fails self-test intermittently. Section 3.8.2 shows an example and lists the tests. RBD 2 is the set of tests that the boot processor runs for each DWMBB VAXBI-to-XMI adapter when the system is powered on.
3.8.1 (xyp) Self-Test — RBD 0 RBD 0 is equivalent to the (xyp) power-up self-tests. Example 3–3: (xyp) Self-Test RBD 0 >>> >>> T/R RBD3> RBD3> START 0 /TRACE/HE ;XCPST Console program prompt. Command to enter RBD monitor program. RBD monitor prompt, where 3 is the hexadecimal node number of the boot processor. Runs the KA62B self-test on boot processor Trace prints each test number; halt on error Test results written to the console terminal: 6.
Table 3–4 (Cont.
Table 3–4 (Cont.
3.8.2 CPU/Memory Test — RBD 1 RBD 1 is equivalent to the extended CPU/memory test. Example 3–4: CPU/memory Test RBD 1 >>>Z 3 ! This example uses the Z command ! to connect processor 3 to the console ! Note new console program prompt 3>> T/R ! Command to enter RBD monitor program RBD3> ! RBD monitor prompt, where 3 is the hexa! decimal node number of the processor ! that is currently receiving your input. RBD3> START 1 /TRACE/HE ! Runs the CPU/memory RBD with trace; halt ! on error.
Table 3–5: Extended CPU/Memory Test — RBD 1 Test Function T0001 Cache Disable test T0002 Cache Invalidate test T0003 Cache Read Fill test T0004 Interlock Instruction Cache test T0005 Longword Write WB0 test T0006 Octaword Write WB0 test T0007 WB Switch and Purge test T0008 Octaword Write WB1 test T0009 Write Buffer Read Tests T0010 Hit WB0 test T0011 Hit WB1 test T0012 WB Mask Bit Byte Tests T0013 WB Mask Bit Word Tests T0014 Intlk Read/Unlck Write WB test T0015 I/O Space Writ
3.8.3 Second-Level Cache Test — RBD 4 RBD 4 tests the second-level cache. Note that no tests are run by default. Example 3–5: Second-Level Cache Test RBD 4 >>> T/R ! Command to enter RBD monitor program RBD1> ! RBD monitor prompt, where 1 is the ! hexadecimal node number of the processor ! that is currently receiving your input RBD1> ST4/T=1:2/TR ! Specifically asks for tests 1 and 2 to ! be run with trace enabled ;SLCRBD 6.
1 S denotes status message for individual test. 2 P means that the entire diagnostic ran successfully. 3 One pass was completed.
3.9 VAX/DS Diagnostics The (xyp) software diagnostics that run under the VAX Diagnostic Supervisor (VAX/DS) are listed in Table 3–7. An example follows. See Section 2.4 for instructions on running the supervisor.
1 Run the standalone autosizer; then you do not need to attach devices to the supervisor explicitly. However, if you want to know the Attach command, enter HELP diagnostic_name ATTACH. 2 The instruction and manual tests run on the boot processor. If the boot processor is the CPU with the lowest (XMI) node number (which is usually the case), issue the command to select KA0. The Diagnostic Supervisor numbers the processors consecutively.
3.10 Machine Checks A machine check is an exception that indicates a processordetected internal error. Figure 3–8 shows the parameters that are pushed on the stack in response to a machine check. Table 3–8 lists these parameters.
Table 3–8 (Cont.): Machine Check Parameters Parameter Value Description 8 Process PTE in P1 space during M = 0 flows 9 Undefined INT.
3.11 Console Commands Table 3–9 summarizes the console commands. The VAX 6000 Series Owner’s Manual gives a full description of each command, its qualifiers, and examples. Table 3–9: Console Commands Command Function BOOT Initializes the system, causing a self-test, and begins the boot program. CONTINUE Begins processing at the address where processing was interrupted by a CTRL/P console command. DEPOSIT Stores data in a specified address. EXAMINE Displays the contents of a specified address.
Table 3–9 (Cont.): Console Commands Command Function SET MEMORY Designates the method of interleaving the memory modules; supersedes the console program’s default interleaving. SET TERMINAL Sets console terminal characteristics in the EEPROM. SHOW ALL Displays the current value of parameters set. SHOW BOOT Displays all boot commands and nicknames that have been saved using SET CPU.
3.12 CPU Replacement in Single CPU Systems There are two methods available to customize a processor in a single-processor system. The first uses the RESTORE command; the second sets the EEPROM by console commands. 3.12.1 Using the RESTORE Command Use the RESTORE command to customize a replaced CPU in a single-processor system. Use this method only if the ROM revision of the spare is the same as the ROM revision of the CPU being replaced. Before you begin set the terminal baud rate to 1200.
1. Turn the upper key switch straight up to the Off position (0). 2. Remove the defective CPU module. 3. Insert the new processor module. 4. Turn the lower key switch to Halt. 5. Turn the upper key switch to Enable. 6. Check the self-test display for the processor, indicated by a P on the TYP line (usually in slot 1). See Example 3–7 6 . 7. If the processor shows a plus sign (+) on both the STF and ETF lines, it passed self-test. See Example 3–7 7 . 8.
3.12.2 Using SET Commands When replacing the only processor module in a system that does not have a TK, you must enter console commands that customize the EEPROM. The Site Management Guide should contain this information. Before you begin set the terminal baud rate to 1200. Example 3–8: Replacing a Single Processor F E D C B A 9 8 7 6 5 4 3 2 1 A + . . . A + . . . . . . . . . . . . . M + . . . M + . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1. Turn the upper key switch straight up to the Off position (0). 2. Remove the defective CPU module. 3. Insert the new processor module. 4. The EEPROM on the new module has a default baud rate of 1200. Make sure your terminal is set to 1200. 5. Turn the lower key switch to Halt. 6. Turn the upper key switch to Enable. 7. Check the self-test display for the processor, indicated by a P on the TYP line. See 7 in Example 3–8. 8.
3.13 CPU Replacement in Multiple CPU Systems In a multiprocessing system replacing a processor requires customizing the new processor into the system. If the processor being replaced is the boot processor, then a few extra steps are required. Since different CPUs can have different ROM and EEPROM revisions in the same system, updating the EEPROM of any processor should be done using SET commands and EVUCA. Example 3–9: Retrieving EEPROM Information F E D C B A 9 8 7 6 5 4 3 2 1 A + . . .
1. Turn the upper key switch straight up to the Off position (0). 2. Remove the defective CPU module. 3. Insert the new processor module. 4. If the processor you are replacing is the first processor on the right (usually in slot one), the console will make it the boot processor. If this is the case, make sure that the console terminal baud rate is 1200, the default baud rate of the spare. 5. Turn the lower key switch to Halt. 6. Turn the upper key switch to Enable. 7.
If you collected the necessary information, you are now ready to customize the EEPROM. Example 3–10: Customizing an EEPROM >>> SET CPU 3 >>> ESC (or 14 CTRL/3 ) DEL SET SYSTEM SERIAL 15 ! Follow the prompts to set the serial number.
14. Issue the SET CPU n command to connect the console to the primary or secondary processor you just replaced. 14 15. Issue the SET SYSTEM SERIAL the error message 10 . 15 and follow the prompts to correct 16. Use the SET BOOT command supplying the parameters displayed by the SHOW ALL command to set up the boot alternatives. 16 17. Use the SET LANGUAGE command to set the language desired. 17 18. Use the SET TERMINAL command to set the EEPROM terminal characteristics.
3.14 How to Add a New Processor Add a new processor in a slot to the left of the boot processor so it will be a secondary processor at power-up. This procedure is similar to that described in Section 3.13. Example 3–11: Adding a Processor F E D C B A 9 8 7 6 5 4 3 2 1 A + . . . A + . . . A + . . . . . . . . M + . . . M + . . . M + . . . M + . . . . . . . . . . . . . P + E + E P + E + E P + E + E P + B + B TYP STF BPD ETF BPD . . . . . . . A4 . 128 . . . . . . . . . .
1. Turn the upper key switch straight up to the Off position (0). 2. Insert the new processor module to the left of the boot processor. 3. Turn the lower key switch to Halt. 4. Turn the upper key switch to Enable. 5. Check the self-test display for the processor, indicated by a P on the TYP line. See 5 in Example 3–11. 6. If the processor shows a plus sign (+) on both the STF and ETF lines, it passed self-test. 6 7. Turn the lower key switch to Update. 8. You will see the ?2D and ?59 messages.
3.15 Patching the EEPROM with EVUCA To update the console and diagnostic ROMs on all VAX 6000 systems, use EVUCA under the Diagnostic Supervisor in standalone mode. Example 3–12: Patching the EEPROM with EVUCA — Part 1 >>> BOOT /XMI:A /R5:110 EX0 3 [self-test display prints] Filename: ISL_LVAX Follow Prompts [Diagnostic Supervisor banner] DS> LOAD EVUCA 4 DS> ATTACH KA62B HUB KA0 1 5 DS> ATTACH KA62B HUB KA1 2 DS> ATTACH KA62B HUB KA2 5 DS> ATTACH KA62B HUB KA3 6 DS> SELECT ALL 6 DS> SET TRACE DS> START ..
1. Turn the lower key switch to Update. 2. Load the latest diagnostic CD in the CD drive. The CD is labeled 6000_ DIAG_x where x is a letter revision. 3. Boot the VAX Diagnostic Supervisor from the CD server using a command similar to that shown in Example 3–12 (see 3 ). Alternatively, you could boot the supervisor from some other disk, perform the appropriate ATTACH commands, and then use the VAX/DS command SET LOAD to load EVUCA from the CD server.
Example 3–13: Patching the EEPROM with EVUCA — Part 2 13 Test 4: Update EEPROM data Getting selectable boot primitives for CPU 05, ROM 04.10 [I/O device types in system identified] [Boot primitives available identified] Available boot primitive space is 27F4 Please enter what boot primitive to delete by number. [1-3(D)] 2 Boot primitives fit into allotted EEPROM area. Secondary CPUs are being updated, please wait a maximum of 20 seconds.
Example 3–13 (Cont.): Patching the EEPROM with EVUCA — Part 2 The primary CPU was not updated. Secondary CPU 05, was successfully updated. Current ROM and EEPROM revisions for each CPU are: [ROM revisions and EEPROM revisions summarized for each CPU] 18 .. End of run, 0 errors detected, pass count is 1, time is 1-JAN-1991 17:06:57.88 DS> 13. Test 4 creates a new updated EEPROM image in memory (see 13 ). Several boot primitives are available.
3.16 (XYP) Registers The (xyp) registers consist of the processor status longword, internal processor registers, (xyp) registers in (XMI) private space, (XMI) required registers, and 16 general purpose registers.
Table 3–10 (Cont.
Table 3–10 (Cont.
Table 3–11: (XMI) Registers for the the (xyp) Register Mnemonic Address XMI Device XDEV BB + 00 XMI Bus Error XBER BB + 04 XMI Failing Address XFADR BB + 08 XMI XGPR XGPR BB + 0C KA62B Control/Status #2 CSR2 BB + 10 Note: "BB" = base address of a node, which is the address of the first location in nodespace.
Table 3–12: (xyp) Registers in (XMI) Private Space Register Mnemonic Address KA62B Control/Status #1 CSR1 2000 0000 KA62B ROM ROM 2004 0000 to 2007 FFFF KA62B EEPROM EEPROM 2008 0000 to 2008 7FFF SSC Base Address SSCBR 2014 0000 SSC Configuration SSCCR 2014 0010 CDAL Bus Timeout CBTCR 2014 0020 Console Select CONSEL 2014 0030 Timer Control Register 0 TCR0 2014 0100 Timer Interval Register 0 TIR0 2014 0104 Timer Next Interval Register 0 TNIR0 2014 0108 T
Chapter 4 (XRP) Scalar Processor This chapter contains the following sections: • (XRP) Physical Description and Specifications • (XRP) Configuration Rules • (XRP) Functional Description • Boot Processor • Power-Up Sequence • (XRP) Self-Test Results: Console Display • (XRP) Self-Test Results: Module LEDs • (XRP) Self-Test Results: XGPR Register • ROM-Based Diagnostics (XRP) Self-Test — RBD 0 CPU/Memory I
4.1 (XRP) Physical Description and Specifications The (XRP) is a single-module VAX processor. The module designation is T2015. (rigel) systems can include up to six (XRP) processors, which use the 100 Mbyte/second (XMI) system bus to communicate with memory. Features of the module are shown in Figure 4–1.
Table 4–1: (XRP) Specifications Parameter Description Module Number: T2015 Dimensions: 23.3 cm (9.2") H x 0.6 cm (0.25") W x 28.0 cm (11.0") D Temperature: Storage Range Operating Range -40o C to 66o C (-40o F to 151o F) 5o C to 50o C (41o F to 122o F) Relative Humidity: Storage 10% to 95% noncondensing Operating 10% to 95% noncondensing Altitude: Storage Up to 4.8 km (16,000 ft) Operating Up to 2.4 km (8000 ft) Current: 8.
4.2 (XRP) Configuration Rules (XRP) modules will operate in any slot of the XMI card cage; however, processors usually go on the right, beginning with slot 1. Special rules apply if the KA64A has an attached vector processor; see Section 5.3.
By convention, processors are placed in the right (XMI) slots, beginning with slot 1 and extending to slot 6. Memories are placed in the middle slots, from slot A to slot 5 and then slots B and C, and VAXBI adapters are installed in the left side of the card cage, beginning with slot E. An attached vector processor must be in the slot to the left of the (XRP) module. The slot to the left of the vector processor can be used only for a memory module.
4.3 KA64A Functional Description The (XRP) processor has four functional sections (see Figure 4–3): the CPU section, the backup cache, the XMI interface, and the console and diagnostics sections.
The CPU section includes: • The processor chip, which supports the VAX Base Instruction Group and data types. It contains a 64-entry, fully associative translation buffer for both process and system-space mappings. The processor chip includes a 2-Kbyte, direct-mapped, write-through instruction and data cache with a quadword block and fill size. • A floating-point accelerator chip that enhances the computation phase of floating-point and some integer instructions.
Example 4–1: ROM and EEPROM Version Numbers #123456789 0123456789 0123456789 01234567# F . E D C B A 9 8 7 6 5 4 3 2 1 A o . . . A + . . . . . . . . . . . . . M + . . . M + . . . M + . . . M + . . . . . . . . . . . . . P + E + E P + E + E P + E + E P + B + B . . . . . + + . + . + . + + . . . . . . . . A4 64 A3 64 A2 64 A1 64 . . . . . . . . . . . . ROM0 = V3.00 1 4–8 ROM1 = V3.00 2 EEPROM = 2.03/3.
The console and diagnostics sections include: • A console read-only memory (ROM), which contains the code for initialization, executing console commands, and bootstrapping the system. The last line of the self-test display shows the ROM version. In this example callout 1 indicates that the console ROM, ROM0, is version V3.00. • A diagnostic ROM, ROM1, which contains the power-up self-test and extended diagnostics. The diagnostic ROM has the same version number as the console ROM.
4.4 Boot Processor All (XRP) processors share system resources equally. The processor controlling the console at any given time is designated as the primary or boot processor. The others are called secondary processors. The boot processor is selected during the power-up sequence.
Using boot code stored in its EEPROM, the boot processor reads the boot block from a specified device. Booting may be triggered by a command issued to the boot processor from the console, or by a system reset with the bottom key switch in the Auto Start position. The boot processor also communicates with the system console, using the common console lines on the backplane.
4.5 Power-Up Sequence Figure 4–5 shows the power-up sequence for (XRP) processors. All processors execute two phases of self-test, and a boot processor is selected. The boot processor tests the VAXBI adapters, if present, and prints the self-test display.
Figure 4–5: (XRP) Power-Up Sequence, Part 1 of 2 Power-up or system reset (cold) 1 2 CPU 1 Self-Test CPU 2 Self-Test Determine Boot Processor CPU n Self-Test ... ... Determine Boot Processor CPU 2 CPU/MEM tests ... CPU n CPU/MEM tests Determine Boot Processor ...
1 All CPUs execute their on-board self-tests at the beginning of the powerup tests. On the STF line of the self-test display, a plus sign (+) is shown for every module whose self-test passes (see Section 4.6). 2 The boot processor is determined as described in Section 4.4. On the first BPD line, the letter B corresponds to the processor selected as boot processor.
Figure 4–6: (XRP) Power-Up Sequence, Part 2 of 2 A 6 Boot Processor prints CPU/MEM test results 7 Boot Processor executes DWMBB tests Boot Processor prints DWMBB test results Boot Processor halts in console mode or boots operating system If Boot Processor is booting operating system, starts all attached CPUs after boot processor has booted CPU 1 running CPU 2 running ...
6 The boot processor prints the ETF line and the second BPD line of the self-test display. If none of the processors is successfully selected as the boot processor, no self-test results are displayed and the console hangs. You can identify this hung state by examining the LEDs on the processor modules (see Section 4.7). All yellow LEDs will be OFF. The group of seven red LEDS indicate the failing test number in binarycoded decimal.
4.6 (XRP) Self-Test Results: Console Display You can check (XRP) self-test results in three ways: the self-test display, the lights on the module, and the contents of the XGPR register. Pertinent information in the self-test display is shown in Example 4–2. See Chapter 6 for information on vector processors. Example 4–2: Self-Test Results #123456789 0123456789 0123456789 01234567# 1 F . E D C B A 9 8 7 6 5 4 3 2 1 A o . . . A + . . . . . . . . . . . . . M + . . .
2 This line indicates the type (TYP) of module at each (XMI) node. Processors are type P found at nodes 1, 2, 3, and 4 in this example. 3 This line shows self-test fail status (STF), which are the results of onboard self-test. Possible values for processors are: + (pass) – (fail) All processors passed self-test in this example. 4 The BPD line indicates boot processor designation.
4.7 (XRP) Self-Test Results: Module LEDs You can check (XRP) self-test results in the self-test display, in the lights on the module, or in the XGPR register. If self-test passes, the large yellow LED is on.
If self-test passes, the large yellow LED at the top of the LEDs is ON. (Here self-test means both the on-board power-up tests, RBD 0, and the CPU/ memory interaction tests, RBD 1.) The top red LED (next to the yellow one) is also ON, and the next five red LEDs are OFF. The bottom LED is OFF if the processor is the boot processor, and ON if it is a secondary processor. If self-test fails, the yellow LED is OFF, and the red LEDs contain an error code that corresponds to the number of the failing test.
Processor error LEDs can also indicate failures of memories or VAXBI adapters. Table 4–2: (XRP) Error LEDs Yellow LED Red LEDs (Binarycoded Diagnostic and decimal) Test Number Device Failing OFF 1–37 Power-up self-test (RBD 0) T0001–T0037 See Table 4–6. (XRP)STF OFF 50–62 CPU/memory test - Memory 1 (RBD 1) T0001–T0013 See Table 4–7.
If a processor’s yellow LED is OFF and the red LEDs show an error code in the range 1–37, the power-up self-test failed and the processor board is bad. On the self-test console display, the processor shows a minus sign (–) on the STF line. After the power-up tests, each processor runs the CPU/memory interaction tests. If a test fails, the processor shows a minus sign (–) on the ETF line of the self-test console display.
4.8 (XRP) Self-Test Results: XGPR Register When a (XRP) failure occurs during powerup and the failing test number cannot be found in the module LEDs and RBDs cannot be run, you can examine the XGPR register. The failing test number is left in the upper byte of the XGPR register of the failing (XRP) processor or of the boot processor if a memory or DWMBB module fails.
The failing test number is derived from the upper byte (bits <31:24>) of the longword returned. For self-test, the upper byte contains the failing test number. If CPU/memory interaction test fails, this byte contains the failing test number plus 49. If DWMBB test fails, bit <31> is set (making the first digit 8 through A), and bits <30:24> contain the failing test number. All numbers are expressed in binary-coded decimal (BCD). See Table 4–4.
Table 4–4: Interpreting XGPR Failing Test Numbers Failing Diagnostic Self-test 1 CPU/memory interaction test Additional memory DWMBB test 1 See Table Table 3 See Table 4 See Table 2 See 4–26 4 4–6, 4–7, 4–2, 7–5, 3 2 XGPR <31> XGPR <30:24> (BCD) Test Numbers Clear 1–49 1–49 Clear 50–66 1–17 Clear 67–73 3 Set 1–26 1–26 KA64A Self-Test — RBD 0. CPU/Memory Interaction Tests — RBD 1. (XRP) Error LEDs. (xbi_plus_title) RBD Tests.
4.9 ROM-Based Diagnostics The (XRP) ROMs contain diagnostics, which you run using the boot processor’s RBD monitor program described in Chapter 2. RBD 0 and RBD 1 test the CPU, memory, and their interaction. RBD 2 tests the DWMBB/A and DWMBB/B adapters, and RBD 3 tests XMI memories.
RBD 0 is the same as the (XRP) self-test. It is useful for running several passes when a processor fails self-test intermittently. Section 4.10.1 shows examples of running RBD 0 on both the boot processor and a secondary processor, and lists the tests in RBD 0. RBD 1 is the same as the CPU/memory interaction tests. It is useful for running several passes when a processor fails CPU/memory interaction tests intermittently. Section 4.10.2 shows an example and lists the tests.
4.10 (XRP) ROM-Based Diagnostics 4.10.1 Self-Test — RBD 0 RBD 0 is equivalent to the (XRP) self-tests. The first 37 tests test scalar CPU modules; tests 38–49 test vector modules. Example 4–4: Self-Test — RBD 0 >>> T/R ! ! ! ! ! ! ! RBD1> RBD1> ST0/TR/HE ;XRP/V_ST ; T0001 ; T0011 T0002 T0012 Command to enter RBD monitor program. Short for TEST/RBD. RBD monitor prompt, where 1 is the hexadecimal node number of the boot processor.
Example 4–5: Running (XRP) Self-Test (RBD 0) on a Secondary Processor >>> SET CPU 2 1 >>> T/R RBD2> ST0/TR 2 ! Note that only 37 tests ran. If a vector ! processor was present 49 tests would run ;XRP/V_ST 1.
Table 4–6: (XRP) Self-Test — RBD 0 Test Function KA64A Tests T0001 (XRP) ROM Checksum Test T0002 IPL Step-Down Test T0003 RSSC Configuration Register Test T0004 RSSC RAM Test T0005 RSSC Output Port Test T0006 RSSC Address Decode Register Access Test T0007 RSSC Console UART External Loopback and Baud Rate Test T0008 RSSC Console UART Internal Loopback and Interrupt Test T0009 (XRP) EEPROM Test T0010 RSSC Input Port Test T0011 RSSC Bus Timeout Test T001
Table 4–6 (Cont.
4.10.2 CPU/Memory Interaction Tests — RBD 1 RBD 1 is equivalent to the CPU/memory interaction tests. The first 13 tests test scalar CPU modules; tests 14–17 test vector modules. Example 4–6: CPU/Memory Interaction Tests — RBD 1 >>> T/R ! Command to enter RBD monitor program RBD3> ! RBD monitor prompt, where 3 is the hexa! decimal node number of the processor ! that is currently receiving your input. RBD3> ST1/TR/HE ! Runs the CPU/memory interaction RBD with ! trace; halt on error.
Table 4–7: CPU/Memory Interaction Tests — RBD 1 Test Function KA64A/Memory Interaction Tests T0001 Parity Error CNAK Read/Write Test T0002 Miss When Invalid Test T0003 Cache Read Fill Test T0004 Interlock Instruction Cache Test T0005 Octaword Write Buffer Test T0006 Quadword-Boundary Byte Write Buffer Test T0007 Two-Byte Write in Different Quadword Write Buffer Test T0008 Write Buffer Switch and Purge Test T0009 Statistical Write Buffer Test T0010 Hit Write Buffer Test T0011 Write Buf
4.11 VAX/DS Diagnostics The (XRP) software diagnostics that run under the VAX Diagnostic Supervisor (VAX/DS) are listed in Table 4–8. An example follows. See Section 2.4 for instructions on running the supervisor. See Section 5.8 for vector-specific tests.
The callouts in Example 4–7 are explained below: 1 Run the standalone autosizer; then you do not need to attach devices to the supervisor explicitly. However, if you want to know how to use the Attach command for a specific diagnostic, enter: DS> HELP diagnostic_name ATTACH 2 The instruction and manual tests run on the boot processor. If the boot processor is the CPU with the lowest (XMI) node number (which is usually the case), issue the command to select KA0.
4.12 Machine Checks Figure 4–8 and Table 4–9 show parameters for machine checks. The machine check frame is pushed onto the interrupt stack.
Table 4–9 (Cont.): Machine Check Parameters Parameter Value (hex) or Bit Description 08 Translation buffer miss in ACV/TNV microflow 09 Translation buffer hit in ACV/TNV microflow 0A Undefined INT.
4.13 Console Commands Table 4–10 summarizes the console commands. The VAX 6000 Series Owner’s Manual gives a full description of each command, its qualifiers, and examples. Table 4–10: Console Commands Command Function BOOT Initializes the system, causing a self-test, and begins the boot program. CLEAR EXCEPTION Cleans up error state in XBER and RCSR registers. CONTINUE Begins processing at the address where processing was interrupted by a CTRL/P console command.
Table 4–10 (Cont.): Console Commands Command Function SET LANGUAGE Changes the output of the console error messages between numeric code only (international mode) and code plus explanation (English mode). SET MEMORY Designates the method of interleaving the memory modules; supersedes the console program’s default interleaving. SET TERMINAL Sets console terminal characteristics. SHOW ALL Displays the current value of parameters set.
4.14 (XRP) Handling Procedures The (XRP) module is static sensitive and fragile. The CMOS2 technology used on this module is more vulnerable to static than past technology. The 25 mil leads used to attach chips to the module are very small, close together, and easily bent. Be careful with the module.
The (XRP) module must be handled carefully. Figure 4–9 shows the proper way to hold the module. Be sure your hands do not touch any components, leads, or XMI fingers. When inserting it in or removing it from the XMI card cage, grasp the module only at the spot shown in Figure 4–10, avoiding any contact with the 25 mil leads. Do not use any component as a handle. To avoid damaging the (XRP) module, follow these handling procedures: 1. Always wear an antistatic wrist strap. 2.
Figure 4–10: Inserting the (XRP) Module in an XMI Card Cage msb-0219-90 4–44 VAX 6000 Models 300 and 400 Service Manual
You must take special precautions when inserting the (XRP) module in or removing it from the XMI card cage. 1. Be sure, when inserting the module in or removing it from the XMI card cage, that no part of the module comes in contact with another module or a cable. 2. When swapping out a module, place it in an unused XMI slot, if one is available, or set the module on an ESD mat while you install the new module.
4.15 CPU Replacement in Single CPU Systems There are two methods available to customize a processor in a single-processor system. The first uses the RESTORE command; the second sets the EEPROM by console command. 4.15.1 Using the RESTORE Command Use the RESTORE command to customize a replaced CPU in a single-processor system. Use this method only if the ROM revision of the spare is the same as the ROM revision of the CPU being replaced. Before you begin set the terminal baud rate to 1200.
1. Turn the upper key switch straight up to the Off position (0). 2. Remove the defective CPU module. 3. Insert the new processor module. 4. Turn the lower key switch to Halt. 5. Turn the upper key switch to Enable. 6. Check the self-test display for the processor, indicated by a P on the TYP line (usually in slot 1). See 6 . 7. If the processor shows a plus sign (+) on both the STF and ETF lines, it passed self-test. See 7 . 8.
4.15.2 Using SET Commands When replacing the only processor module in a system that does not have a TK, you must enter console commands that customize the EEPROM. The Site Management Guide should contain this information. Before you begin set the terminal baud rate to 1200. Example 4–9: Replacing a Single Processor #123456789 0123456789 0123456789 01234567# F E D C B A 9 8 7 6 5 4 3 2 1 A + . . . A + . . . . . . . . . . . . . M + . . . M + . . . . . . . . . . . . . . . . . . . . . .
1. Turn the upper key switch straight up to the Off position (0). 2. Remove the defective CPU module. 3. Insert the new processor module. 4. The EEPROM on the new module has a default baud rate of 1200. Make sure your terminal is set to 1200. 5. Turn the lower key switch to Halt. 6. Turn the upper key switch to Enable. 7. Check the self-test display for the processor, indicated by a P on the TYP line. See 7 in Example 4–9. 8.
4.16 CPU Replacement in Multiple CPU Systems In a multiprocessing system replacing a processor requires customizing the new processor into the system. If the processor being replaced is the boot processor, then a few extra steps are required. Since different CPUs can have different ROM and EEPROM revisions in the same system, updating the EEPROM of any processor should be done using SET commands and EVUCA.
1. Turn the upper key switch straight up to the Off position (0). 2. Remove the defective CPU module. 3. Insert the new processor module. 4. If the processor you are replacing is the first processor on the right (usually in slot one), the console will make it the boot processor. If this is the case, make sure that the console terminal baud rate is 1200, the default baud rate of the spare. 5. Turn the lower key switch to Halt. 6. Turn the upper key switch to Enable. 7.
If you collected the necessary information, you are now ready to customize the EEPROM. Example 4–11: Customizing an EEPROM >>> SET CPU 3 >>> ESC (or 14 CTRL/3 ) DEL SET SYSTEM SERIAL 15 ! Follow the prompts to set the serial number.
14. Issue the SET CPU n command to connect the console to the primary or secondary processor you just replaced. 14 15. Issue the SET SYSTEM SERIAL command prompts to correct the error message 10 . 15 and follow the command 16. Use the SET BOOT command supplying the parameters displayed by the SHOW ALL command to set up the boot alternatives. 16 17. Use the SET LANGUAGE command to set the language desired. 17 18. Use the SET TERMINAL command to set the EEPROM terminal characteristics.
4.17 How to Add a New Processor Add a new processor in a slot to the left of the boot processor so it will be a secondary processor at power-up. This procedure is similar to that described in Section 4.16. Example 4–12: Adding a Processor #123456789 0123456789 0123456789 01234567# F E D C B A 9 8 7 6 5 4 3 2 1 A + . . . A + . . . A + . . . . . . . . M + . . . M + . . . M + . . . M + . . . . . . . . . . . . . P + E + E P + E + E P + E + E P + B + B TYP STF BPD ETF BPD . . . .
1. Turn the upper key switch straight up to the Off position (0). 2. Insert the new processor module to the left of the boot processor. 3. Turn the lower key switch to Halt. 4. Turn the upper key switch to Enable. 5. Check the self-test display for the processor, indicated by a P on the TYP line. See 5 in Example 4–12. 6. If the processor shows a plus sign (+) on both the STF and ETF lines, it passed self-test. 6 7. Turn the lower key switch to Update. 8. You will see the ?2D and ?5A messages.
4.18 Patching the EEPROM with EVUCA To update the console and diagnostic ROMs on all VAX 6000 systems, use EVUCA under the Diagnostic Supervisor in standalone mode. Example 4–13: Patching the EEPROM with EVUCA — Part 1 >>> BOOT /XMI:A /R5:110 EX0 3 [Self-test display prints] Filename: ISL_LVAX Follow Prompts [Diagnostic Supervisor Banner] DS> LOAD EVUCA 4 DS> ATTACH KA64A HUB KA0 1 5 DS> ATTACH KA64A HUB KA1 2 DS> ATTACH KA64A HUB KA2 5 DS> ATTACH KA64A HUB KA3 6 DS> SELECT ALL 6 DS> SET TRACE DS> START ..
1. Turn the lower key switch to Update. 2. Load the latest diagnostic CD in the CD drive. The CD is labeled 6000_ DIAG_x where x is a letter revision. 3. Boot the VAX Diagnostic Supervisor from a CD server using a command similar to that shown in Example 4–13 (see 3 ). Alternatively, you could boot the supervisor from some other disk, perform the appropriate ATTACH commands, and then use the VAX/DS command SET LOAD to load EVUCA from the CD server.
Example 4–14: Patching the EEPROM with EVUCA — Part 2 13 Test 4: Update EEPROM data Getting selectable boot primitives for CPU 05, ROM 02.00 [I/O device types in system identified] [Boot primitives available identified] Available boot primitive space is 27F4 Please enter what boot primitive to delete by number. [1-3(D)] 2 Boot primitives fit into allotted EEPROM area. Secondary cpus are being updated, please wait a maximum of 20 seconds.
Example 4–14 (Cont.): Patching the EEPROM with EVUCA — Part 2 Current ROM and EEPROM revisions for each CPU are: [ROM revisions and EEPROM revisions summarized for each CPU] 18 .. End of run, 0 errors detected, pass count is 1, time is 24-SEP-1990 17:06:57.88 DS> 13. Test 4 creates a new updated EEPROM image in memory (see 13 ). Several boot primitives are available. Those that are permanent reside in ROM; those that are selectable or are patched reside in the EEPROM.
4.19 (XRP) Registers The (XRP) registers consist of the processor status longword, internal processor registers, (XRP) registers in (XMI) private space, (XMI) required registers, and 16 general purpose registers.
Table 4–11 (Cont.
Table 4–11 (Cont.
Table 4–11 (Cont.
Table 4–12: (XMI) Registers for the (XRP) Register Mnemonic Address XMI Device XDEV BB + 00 XMI Bus Error XBER BB + 04 XMI Failing Address XFADR BB + 08 XMI GPR XGPR BB + 0C RCSR BB + 10 (XRP) and Status Control Note: "BB" = base address of an XMI node, which is the address of the first location in nodespace.
Table 4–13: (XRP) Registers in (XMI) Private Space Register Mnemonic Address Control Register Write Enable CREGWE 2000 0000 Console ROM (halt protected) 2004 0000 to 2007 FFFF Console EEPROM (halt protected) 2008 0000 to 2008 7FFF Console ROM (not halt protected) 200C 0000 to 200F FFFF Console EEPROM (not halt protected) 2010 0000 to 2010 7FFF RSSC Base Address SSCBAR 2014 0000 RSSC Configuration SSCCNR 2014 0010 RSSC Bus Timeout Control SSCBTR 2014 0020 RSSC Out
Chapter 5 (XRV) Vector Processor Of the two CPUs discussed in this book only the (rigel) system supports the vector processor.
5.1 (xrv) Physical Description and Specifications The (XRV) is a vector processor used with the (XRP) scalar processor. The module designation is T2017. The two processor modules are connected with a VIB cable. Figure 5–1 shows side 1 of the module, and Figure 5–2 shows side 2.
Because the vector module has components on side 2, only memory modules can be installed next to side 2 (see Figure 5–2).
5.2 KA64A/FV64A Coprocessors The (rigel) uses a high-speed system bus, called the (XMI) bus, to interconnect its processors and its memory modules. In Figure 5–3 all I/O devices connect to the VAXBI bus. The (rigel) supports multiprocessing with up to six scalar processors or one or two scalar/vector pairs.
Table 5–1: (XRV) Specifications Parameter Description Module Number: T2017 Dimensions: 23.3 cm (9.2") H x 2.4 cm (0.94") W x 28.0 cm (11.0") D Temperature: Storage Range Operating Range -40o C to 66o C (-40o F to 151o F) 5o C to 50o C (41o F to 122o F) Relative Humidity: Storage 10% to 95% noncondensing Operating 10% to 95% noncondensing Altitude: Storage Up to 4.8 km (16,000 ft) Operating Up to 2.4 km (8000 ft) Current: 14.
5.3 (xrv) Configuration Rules A vector processor must be installed to the left of its companion scalar processor. An intermodule cable connects the two modules. A memory module or an empty slot must be to the left of the vector processor. Any other configuration may damage the vector module.
Table 5–2 shows the maximum number of scalar and vector processors supported in a VAX 6000 Model 400 system. Table 5–2: Processor Module Combinations Maximum CPUs Maximum Vectors Configuration (Slot 1 at Right) 6 0 P P P P P P 4 1 M V P P P P 2 2 M V P M V P Figure 5–4 shows system configurations for a VAX 6000 Model 400 system with one or two vector processors.
5.4 Functional Description Figure 5–5 shows the three main functional units of the (XRV) processor: the vector control unit, the arithmetic unit, and the load/store unit, which includes the XMI interface and cache control.
The (xrv) is an integrated vector processor, tightly coupled to the (XRP) scalar processor. The vector instructions are issued from the scalar processor, and the vector processor then dispatches them internally. All communication between the scalar and vector modules takes place across the intermodule VIB cable. All communication with memory is over the XMI bus. The vector processor has 16 vector data registers, each 64 quadwords long.
5.5 Self-Test Results: Console Display and Self-Test LED You can check the vector processor self-test results in three ways: the self-test display if the vector is attached to the processor in node 1, the yellow self-test LED on the (xrv) module, and the contents of the XGPR register of the attached (XRP) module. If self-test passes, the large yellow LED on the vector module lights. If the vector module fails self-test, the light remains unlit.
2 This line indicates the type (TYP) of module at each (XMI) node. Scalar processors are type P, and vector processors are type V. The dashes indicate that the scalar processors are attached to the adjacent vector processors. 3 This line shows self-test fail status (STF), which are the results of onboard self-test. Possible values for processors are: + (pass) – (fail) All processors passed self-test in this example.
5.6 Self-Test Results: Scalar XGPR Register You can check self-test results in the self-test display or in the XGPR register. The failing test number is left in the upper byte of the XGPR register of the failing (XRP) processor.
Figure 5–6 shows the XGPR register of the scalar processor. Bit <23>, when set, indicates that there is a vector processor attached to this processor. Bits <22:16> give status on an attached vector processor. The failing test number is derived from the upper byte (bits <31:24>) of the longword returned. For self-test, the upper byte contains the failing test number. If CPU/memory interaction test fails, this byte contains the failing test number plus 49.
5.7 Vector Processor Tests — RBD 0 and RBD 1 T0038 through T0049 of RBD 0 test the vector processor during self-test. Tests 14–17 of RBD 1 test the vector processor during CPU/memory testing. Example 5–3: Running RBD 0 on a Secondary Processor with an Attached Vector Processor >>> SET CPU 4 1 >>> T/R RBD4> ST0/TR 2 ;XRP/V_ST ; ; ; ; ; T0001 T0011 T0021 T0031 T0041 2.
Table 5–4: Vector Processor Tests in Self-Test — RBD 0 Test Function T0038 VECTL Registers Test T0039 Verse Registers Test T0040 Load/Store Registers Test T0041 VIB Error Logic Test T0042 Other VECTL Chip Logic Test T0043 Verse and Favor Test T0044 Load/Store Translation Buffer and CAM Test T0045 Load/Store Cache Test T0046 Load/Store Instruction Test T0047 Load/Store Tag and Duplicate Tag Test T0048 Load/Store Error Cases Test T0049 Module Critical Path Test Table 5–5: Vector Test
5.8 VAX/DS Diagnostics The (xrv) software diagnostics that run under the VAX Diagnostic Supervisor (VAX/DS) are listed in Table 5–6. Example 5–4 lists VAX/DS commands used in testing vector processors. See Section 2.4 for instructions on running the supervisor.
5.9 Machine Checks A machine check is an exception that indicates a processordetected internal error. Figure 5–7 and Table 5–7 show these parameters. Figure 5–7: The Stack in Response to a Machine Check Table 5–7: (xrv) Machine Check Parameters Parameter Machine check code (SP+4) Value (hex) Description 14 Vector module error Machine checks are taken regardless of the current IPL.
5.10 Vector Console Commands Table 4–10 gives the console commands specific to the vector processor. Table 5–8: Vector Console Commands Command Function DEPOSIT Stores data in a specified address. Additional addresses can be VMR, VCR, and VLR (for Vector Mask Register, Vector Count Register, and Vector Length Register). /M Defines the address space as a vector indirect register; accesses addresses 400 and higher. /Q Quadword is the default data size for vector registers (except for VCR and VLR).
DEPOSIT Examples 1. >>> DEPOSIT/VE V12 0 2. >>> DEPOSIT V6:2C/n:2 3. >>> DEPOSIT VLR 1 4. >>> DEPOSIT/Q/P 200 FFFFFFFF45370201 ! Deposits FFFFFFFF45370201, a quadword ! of data into physical memory at address ! 200. 5. >>> DEPOSIT/M 440 0 0 ! ! Deposits zero into all 64 elements of vector register V12. ! ! ! Deposits zero into V6 beginning at element 2C (hex) and also in the next two elements. ! ! Deposits one in the Vector Length Register.
EXAMINE Examples 1. >>> EXAMINE VLR ! ! Examines the Vector Length Register. M 00000001 0E 2. >>> EXAMINE/Q/P 200 ! ! Examines the quadword in physical memory at address 200. 3. >>> EXAMINE/VE V12:2E ! ! ! Examines element 2E (hex) (which is 41 decimal) of vector data register V12. 4. >>> EXAMINE/M ! ! ! ! Examines the vector indirect register at hex address 440. /M is used to access vector indirect registers.
5.
5.11 (xrv) Handling Procedures Handle the processor modules with care. The technology used on the later 6000 series modules is more vulnerable to static than earlier technology. Also, these modules have 25 mil leads to the chips; these leads are small, close together, and easily bent.
The later 6000 series modules require careful handling. Prepare yourself and the work area before handling these modules. Roll up your sleeves and remove any jewelry. Figure 5–8 shows the proper way to hold these modules. Follow these handling procedures to avoid damaging the processor modules: 1. Always wear an antistatic wrist strap. 2. Before removing the module from its ESD box, place the box on a clean, stable surface. Be sure the box will not slide or fall. Never place the box on the floor.
Figure 5–9: Inserting the (xrv) Module in an XMI Card Cage msb-0372-90 5–24 VAX 6000 Models 300 and 400 Service Manual
You must take special precautions when moving the processor modules in or out of the XMI card cage. 1. Be sure, when inserting the module in or removing it from the XMI card cage, that no part of the module comes in contact with another module or a cable. The leads on the components are fragile and can be damaged by contact with fingers or any surface. 2. When you swap out a module, place it in the correct ESD box before you install the new module. 3.
5.12 How to Replace a Vector Module If a vector module is defective, you can replace it with a new one. If you install an additional one, see the complete installation instructions in the VAX 6000 Series Upgrade Manual.
CAUTION: Special care must be taken when handling processor modules. See Section 5.11 before replacing this module. Also review the configuration rules in Section 5.3. While removing or inserting a module in the XMI card cage, you must hold the XMI card cage lever. Failure to do so may result in damage to the module. 1. Turn the upper key switch straight up to the Off position (0). 2. Open the cabinet door and remove the plastic door in front of the XMI card cage.
5.13 Vector Processor Registers The (XRV) internal processor registers are listed in Table 5–9. See Chapter 4 for the complete list of IPR registers. The console program allows you to access the vector registers. Software accesses the vector registers with MTPR/MFPR and MTVP/MFVP instructions.
The IPRs listed in Table 5–9 are explicitly accessible to software only by the Move To Processor Register (MTPR) and Move From Processor Register (MFPR) instructions, which require kernel mode privileges. (The vector indirect registers are also accessed with MTPR and MFPR instructions. These registers are described in the System Technical User’s Guide.) From the console, EXAMINE/I and DEPOSIT/I commands read and write the IPRs.
Chapter 6 MS65A Memory This chapter discusses the (xma2) memory module.
6.1 MS65A Physical Description The (xma2) memory module is a metal-oxide semiconductor (MOS), dynamic random access memory (DRAM), which provides up to 128 Mbytes of data storage. The memory module is designed for use with the (6000) system through the XMI bus.
The (xma2) memory module has the following features: • The memory module contains MOS dynamic RAM (DRAM) arrays; a CMOS memory control gate array that contains error correction code (ECC) logic and control logic; an EEPROM storage element and an XMI interface known as the XMI Corner. • Storage arrays are made up of two or four banks, either 155 or 299 DRAMs. • ECC logic detects single-bit and double-bit errors and corrects single-bit errors on 64-bit words.
6.2 MS65A Configuration Rules Figure 6–2 shows the order of placement of MS65A modules in the XMI backplane. Figure 6–2: MS65A Configuration XMI CARD CAGE E D C B A 9 2 8 7 6 5 4 3 Memory Slots 1 2 1 msb-0133E-90 Memory modules are configured after I/O adapter and processor modules. Install memory modules next to vector processors first, then install additional memories as follows: 1 Install the first memory module in slot A. Fill all available slots left to right from slot A to slot 1.
6.3 MS65A Specifications Table 6–1 gives the (xma2) module specifications. Table 6–1: (xma2_title) Specifications Parameter Description Module Number: T2053 Dimensions: 23.3 cm (9.2") H and 28.0 cm (11.
6.4 MS65A Functional Description The (xma2) consists of an XMI Corner, a memory control gate array, address and control drivers, block state DRAMs, DRAM arrays, and an EEPROM.
The XMI Corner is located on the (xma2) module and contains interface logic. The memory control gate array transfers data between the XMI Corner and the DRAMs. The memory control gate array also controls address multiplexing, command decoding, arbitration, and CSR logic functions. Address and control logic modifies address bits received from the XMI Corner. These modified address bits are used to control the selection of the DRAMs during reading and writing.
6.5 System Interleaving Requirements System performance is affected by the speed with which memory responds to requests made of its resources. For this reason, (HYPERION) and (rigel) systems have memory interleaving requirements. Those requirements are given in Table 6–2.
The interleave configuration requirements shown in Table 6–2 are necessary for system performance. Differences between the two systems are primarily due to cache differences on the two CPUs. Note that memory size is not the issue. However, to achieve 4-way interleaving the minimum memory capacity is 128 Mbytes (4 x 32-Mbyte arrays).
6.6 MS65A Interleaving Interleaving optimizes memory access time and increases the effective memory transfer rate by operating memory modules in parallel.
Memory supports 2-, 4-, 8-way or no interleaving. Up to eight memory modules of the same size can be interleaved. Memory modules of different sizes can also be interleaved. Figure 6–4 shows three examples of interleaving. • A 2-way interleave set is made from two, same sized, arrays. • A 2-way interleave set is made from three memory arrays of different sizes. • The final example shows how the console builds a 4-way interleave set from several different array sizes.
6.7 Console Commands for Interleaving The SET MEMORY command is used to set memory interleaving in a configuration other than the default. This is not usually advisable, but occasional customer use will warrant overriding the original console setting of the interleave. The INITIALIZE command causes both (6000) systems to execute (xma2) self-tests and the SET MEMORY commands to take effect.
The callouts in Example 6–1 are explained below. 1 Shows the SET MEMORY command that configures interleaving with the console program. This command invokes the default interleaving configuration. It is recommended that this default be used, rather than trying to interleave memory manually. 2 The SHOW MEMORY command displays the node number (node #), interleave (ILV), and total usable memory (xxMb) lines from the selftest results.
6.8 MS65A Addressing Memory addressing is set on hexword boundaries and depends on the interleaving sets organized by the console. Starting and ending addresses are determined by the console regardless of how interleaving is done (by the user or by the console).
Figure 6–5 shows the starting address (STADR), ending address (ENADR), and interleave (INTLV) registers of a sample interleave set. The contents of these registers are set by the console. The memory shown in Figure 6–5 is divided into two interleaving sets and totals 256 Mbytes. Set 0 consists of two 32-Mbyte arrays and one 64-Mbyte array. Set 1 consists of one 128-Mbyte array. The starting address of the first array is 0.
6.9 Memory Self-Test The (xma2) performs an initialization and self-test sequence on power-up or when the sequence is requested by a console command. During self-test the array chip is initialized, all memory locations are tested, and the control and status registers are initialized. Example 6–2: MS65A Memory Module Results in Self-Test #123456789 0123456789 0123456789 01234567# F E A + . . . D A + . . . C . . . . . B . . . . . A M . . . 9 M + . . . 8 M + . . . 7 M + . . . 6 . . . . .
The callouts in Example 6–2 are explained below. 1 The TYP line shows that memory modules are installed in XMI slots 7 through A as indicated by the M in this row. 2 The STF line shows if memory modules pass self-test, as indicated by the + in this row. If a module fails self-test, a – is indicated, but the console still tests all pages within the module. The failing module is included in the configuration, and the addresses that fail self-test are not used by the system.
6.10 Memory Self-Test Errors If an (xma2) node fails self-test, an explicit memory test is run on the failing module and console error messages are displayed. The failing module is still included in the memory configuration. Example 6–3: MS65A Memory Module Node Exclusion >>> >>> >>> F SET MEMORY /INTERLEAVE:(8+9, A) INITIALIZE SHOW MEMORY E D C B A 9 . . . . B1 A2 . . . . 64 64 /INTERLEAVE:(8+9, A) 8 A1 64 7 . 6 . . 5 . . 4 . . 3 . . 2 . . 1 . .
that is valid will be configured uninterleaved; any memory array that is not included in the set will not be interleaved. ?46 ?47 Insufficient working memory for normal operation. ((xyp) msg.) Insufficient working memory for normal operation. ((XRP) msg.) This means that less than 256 Kbytes per processor of working memory were found. There may be insufficient memory for the console to function or for the operating system to boot.
6.11 Memory RBD RBD 3 of the ROM-based diagnostics sizes memory, runs extended memory tests, and indicates any failing tests.
Tests T0002 through T0008 are run by default. Tests T0001 and T0009 through T0012 must be selected by the user. Tests are performed on all (XMA2)s unless the user specifies a single (XMA2). Parameters specified in the command line (refer to Table 6–4) allow one or all memory modules to be tested. These parameters also allow RBD tests to be run from main memory or ROM for RBD tests T0011 and T0012.
6.12 Memory RBD Test Examples RBD 3 sizes memory, runs extended memory tests, and indicates any failing tests. Example 6–4 through Example 6–6 show the use of various qualifiers. Example 6–4: RBD 3 — Test on All Modules with Halt on Error >>> T/R ! Command to enter RBD monitor program RBD3> ! RBD monitor prompt, where 3 is the hexa! decimal node number of the processor ! that is currently receiving your input RBD3> ST3/TR/HE ! ! ! ! ;XMA_RBD ; T0002 ; ; 3.
Example 6–6: RBD 3 — Parameter RBD3> ST3/TR/T=11:12/C 0A ;XMA_RBD ; T0011 ! ! ! ! ! Runs (XMA2) RBD tests T0011 and T0012 from RAM on the the memory module in slot A. Confirm destructive memory test switch (/C) is required on these tests. 3.00 T0012 [RBD status messages are printed every two minutes; use the /DS qualifier in the command string to inhibit these messages.
6.13 MS65A Control and Status Registers The memory contains 19 control and status registers (CSRs) to control the memory and log errors. All CSRs are 32 bits long and respond only to longword read and write transactions. Only full writes are performed to the CSRs. If a parity error occurs during a write operation, the operation is aborted and the contents of the CSRs are unchanged. The CSRs start at an address dependent upon the node ID.
Table 6–5 (Cont.
6.14 Mixing MS65A and MS62A Memory Modules This section discusses the interleaving of MS62A and (xma2) memory modules in Model 300 and Model 400 systems. For completeness the VAX 6000 Model 200 and the VAX 6000 Model 500 are included. Table 6–6: Memory Module Configurations System Type MS65A MS62A Mixed Model 2001 Yes Yes Yes Model 3002 Yes Yes Yes Model 4003 Yes Yes Yes Yes No No Model 500 1 The minimum CPU ROM revision required is 5.00.
There is no difference between MS62A memory modules and (xma2)s as far as interleaving is concerned. The console software that does the interleaving only recognizes the size difference (number of Mbytes) of the memory module. Memory ROM-based diagnostics function with both types of memory modules. However, since the (xma2) has an EEPROM and the MS62A memory module does not, the RBD does not test the EEPROM on the (xma2).
Chapter 7 DWMBB I/O Adapter This chapter discusses the DWMBB adapter, the interface to an optional VAXBI I/O channel.
7.1 DWMBB Physical Description 7.1.1 Physical Layout The (xbia) is an XMI module (T2018) with the standard XMI Corner, an XMI self-test OK LED indicator, IBUS drivers/receivers and transceivers, timeout logic, and a gate array that controls the (xbia). Most of the components on the (xbia) are surfacemounted.
The (XBIB) is a standard VAXBI (T1043) module with a VAXBI Corner, including a BIIC interface chip, the primary interface between the VAXBI bus and the (XBIB) node logic, a clock driver, and a clock receiver. The (XBIB) gate array is used mostly for data path logic. The VAXBI self-test OK LED is on the VAXBI Corner, and the module self-test OK LED is at the module edge opposite the connector edge.
7.1.2 Specifications The following specifications apply to the DWMBB modules. Table 7–1: DWMBB/A Specifications Parameter Description Module Number: T2018 Dimensions: 23.3 cm (9.2") H x 0.23 cm (0.093") W x 28.0 cm (11.0") D Temperature: Storage Range -40o C to 66o C (-40o F to 151o F) Operating Range 5o C to 50o C (41o F to 122o F) Relative Humidity: Storage and operating 10% to 95% noncondensing Altitude: Storage Up to 4.8 km (16,000 ft) Operating Up to 2.
Table 7–2: DWMBB/B Specifications Parameter Description Module Number: T1043 Dimensions: 20.3 cm (8") H x 0.23 cm (0.093") W x 23.3 cm (9.2") D Temperature: Storage Range -40o C to 66o C (-40o F to 151o F) Operating Range 5o C to 50o C (41o F to 122o F) Relative Humidity: Storage and operating 10% to 95% noncondensing Altitude: Storage Up to 4.8 km (16,000 ft) Operating Up to 2.
7.2 (xbi_plus) Configuration Rules This section describes the configuration rules for the DWMBB/A module in the XMI card cage and for the DWMBB/B module in the VAXBI card cage.
(XBIA) modules are placed in the order shown in Table 7–4. Table 7–4: (xbi_plus) Configuration (XMI) Node No. VAXBI Channel Location E 1 System cabinet 1 2 Expander cabinet 2 3 Expander cabinet 3 4 Expander cabinet 4 5 Expander cabinet Configuration rules are as follows: • The first VAXBI channel is the 12-slot channel in the system cabinet.
7.3 DWMBB Functional Description The (xbi_plus) adapter provides an information path between the (XMI) bus and I/O devices on the VAXBI bus. The (xbi_plus) consists of two modules: the (XBIA) and the (XBIB). The (XBIA) resides on the (XMI) bus, and the (XBIB) resides on the VAXBI bus. Four 30-pin cables, which make up the IBUS, connect the two modules.
The (XBIA) contains the (XMI) Corner, the register files, (XMI) required registers, (XBIA)specific registers, page map registers, and the control sequencers for the (XMI) interface.
7.4 (xbi_plus) Tests — RBD 2 The (xbi_plus) ROM-based diagnostic, RBD 2, checks functions of both (xbi_plus) modules. RBD 2 tests the (xbi_plus) modules and can trace the subtests, pinpointing errors. Example 7–1: (xbi_plus) Tests — RBD 2 >>> T/R ! Command to enter RBD monitor program RBD1> ! ! ! ! RBD1> ST2/TR E 1 ! Runs the DWMBB RBD, testing ! the DWMBB at XMI node number E.
The (xbi_plus) has no on-board self-test. The boot processor ROM code tests (xbi_plus)s during additional power-up tests. At power-up, the boot processor first sizes all (xbi_plus)s and then serially tests each one. 1 When invoking RBD 2 from the monitor, the START command requires a parameter. This parameter is the XMI node number (hexadecimal) of the (xbia_plus) module of the (xbi_ plus) to be tested. 2 This diagnostic ran successfully.
7.5 DWMBB Tests — RBD 2 Subtests RBD 2 consists of 26 tests, as shown in Table 7–5.
Table 7–5 (Cont.
7.6 (xbi_plus) Registers Two sets of registers are used by the (xbi_ plus) adapter: VAXBI registers (residing in the BIIC) and (xbi_plus) registers (residing on both modules of the (xbi_plus)). The (xbi_ plus) registers include the (XMI) required registers and (xbi_plus)-specific registers addressed in (xbi_plus) private space.
Table 7–6 lists the VAXBI registers. The VAXBI registers are described in Chapter 5 of the VAXBI Options Handbook. Table 7–7 lists the (xbi_plus) registers.
Table 7–7 (Cont.): (xbi_plus) XMI Registers Name Mnemonic1 Address2 Page Map Register (first location) PMR BB+200 PMR BB+401FC . . .
Appendix A Console Error Messages for Model 300 Table A–1 lists messages ?02 through ?1F which appear when the processor halts and the console gains control. Each message is followed by a "PC = xxxxxxxx" message giving the address where the processor was executing when it halted; these messages designate the reasons for the halt. Table A–2 lists the standard console error messages ?20 through ?7C. Table A–1: Model 300 Console Error Messages Indicating Halt Error Message Meaning ?02 External halt.
Table A–1 (Cont.): Model 300 Console Error Messages Indicating Halt Error Message Meaning ?11 ACV or TNV during KSP not valid. An access violation or translation-notvalid error occurred while handling another error condition. ?12 Machine check during machine check. A machine check occurred while handling another error condition. ?13 Machine check during KSP not valid. A machine check occurred while handling another error condition. ?19 PSL <26:24>= 101 during interrupt or exception.
Table A–2: Model 300 Standard Console Error Messages Error Message Meaning ?20 Illegal memory reference. An attempt was made to reference a virtual address (/V) that is either unmapped or is protected against access under the current PSL. ?21 Illegal command. The command was not recognized, contained the wrong number of parameters, or contained unrecognized or inappropriate qualifiers. ?22 Illegal address.
Table A–2 (Cont.): Model 300 Standard Console Error Messages Error Message Meaning ?2D For Secondary Processor n This message is a preface to second message describing some error related to a secondary processor. This message indicates which secondary processor is involved. ?2E Specified node is not an I/O adapter. The referenced node is incapable of performing I/O or did not pass its selftest. ?30 Write to Z command target has timed out. The target node of the Z command is not responding.
Table A–2 (Cont.): Model 300 Standard Console Error Messages Error Message Meaning ?3C Secondary processor not in console mode. The primary processor console needed to communicate with a secondary processor, but the secondary processor was not in console mode. STOP the node or reset the system to clear this condition. ?3D Error initializing I/O device. A console boot primitive needed to perform I/O, but could not initialize the I/O adapter. ?3E Timeout while sending message to secondary.
Table A–2 (Cont.): Model 300 Standard Console Error Messages Error Message Meaning ?46 Insufficient working memory for normal operation. Less than 256 Kbytes per processor of working memory were found. There is insufficient memory for the console to function normally or for the operating system to boot. ?47 Uncorrectable memory errors—long memory test must be performed. A memory array contains an unrecoverable error. The console must perform a slow test to locate all the failing locations.
Table A–2 (Cont.): Model 300 Standard Console Error Messages Error Message Meaning ?52 EEPROM header is corrupted. The EEPROM header has been corrupted. The EEPROM must be restored from the TK tape drive. ?53 EEPROM revision mismatch. Secondary processor has revision x.y/x.y. A secondary processor has a different revision of EEPROM or has a different set of EEPROM patches installed. ?54 Failed to locate EEPROM area. The EEPROM did not contain a set of data required by the console.
Table A–2 (Cont.): Model 300 Standard Console Error Messages Error Message Meaning ?5E EEPROM header version mismatch. The primary and a secondary processor have different versions of the EEPROM. The requested operation cannot be performed. ?5F Bad transfer length. The primary processor attempted to send EEPROM data to a secondary processor using an invalid length. ?60 EEPROM header or area has bad format. All or part of the EEPROM contains inconsistent data and is probably corrupted.
Table A–2 (Cont.): Model 300 Standard Console Error Messages Error Message Meaning ?6A Error changing EEPROM. An error occurred in writing to the EEPROM. The EEPROM contents may be corrupted. ?6B EEPROM saved to tape successfully. The EEPROM contents were successfully written to the TK tape. ?6C EEPROM not saved to tape. The EEPROM contents were not completely written to the TK tape. ?6D EEPROM Revision = x.x/y.y. The EEPROM contents are at revision x.x with revision y.y patches.
Table A–2 (Cont.): Model 300 Standard Console Error Messages Error Message Meaning Loading system software. The console is attempting to load the operating system in response to a BOOT command, power-up, or restart failure. Shows as ?83 in SET LANGUAGE INTERNATIONAL mode. Node: n ?xx Error message ?xx was generated on secondary processor n and was passed to the primary processor to be displayed. Restarting system software.
Appendix B Console Error Messages for Model 400 Table B–1 lists Model 400 messages that appear when the processor halts and the console gains control.
Table B–1 (Cont.): Model 400 Console Error Messages Indicating Halt Error Message Meaning ?08 SCB vector bits <1:0> = 10. An interrupt or exception vector in the System Control Block contained an invalid address. ?0A CHMx executed while on interrupt stack. A change-mode instruction was issued while executing on the interrupt stack. ?10 ACV/TNV occurred during machine check processing. An access violation or translation-notvalid error occurred while handling another error condition.
Table B–2: Model 400 Standard Console Error Messages Error Message Meaning ?20 Illegal memory reference. An attempt was made to reference a virtual address (/V) that is either unmapped or is protected against access under the current PSL. ?21 Illegal command. The command was not recognized, contained the wrong number of parameters, or contained unrecognized or inappropriate qualifiers. ?22 Illegal address.
Table B–2 (Cont.): Model 400 Standard Console Error Messages Error Message Meaning ?2D For Secondary Processor n. This message is a preface to second message describing some error related to a secondary processor. This message indicates which secondary processor is involved. ?2E Specified node is not an I/O adapter. The referenced node is incapable of performing I/O or did not pass its selftest. ?30 Write to Z command target has timed out. The target node of the Z command is not responding.
Table B–2 (Cont.): Model 400 Standard Console Error Messages Error Message Meaning ?3C Secondary processor not in console mode. The primary processor console needed to communicate with a secondary processor, but the secondary processor was not in console mode. STOP the node or reset the system to clear this condition. ?3D Error initializing I/O device. A console boot primitive needed to perform I/O, but could not initialize the I/O adapter. ?3E Timeout while sending message to secondary processor.
Table B–2 (Cont.): Model 400 Standard Console Error Messages Error Message Meaning ?47 Insufficient working memory for normal operation. Less than 256 Kbytes per processor of working memory were found. There is insufficient memory for the console to function normally or for the operating system to boot. ?48 Uncorrectable memory errors—long memory test must be performed. A Model 400 memory array contains an unrecoverable error. The console must perform a slow test to locate all the failing locations.
Table B–2 (Cont.): Model 400 Standard Console Error Messages Error Message Meaning ?52 ROM revision mismatch. Secondary processor has revision x.xx. The revision of console ROM of a secondary processor does not match that of the primary. ?53 EEPROM header is corrupted. The EEPROM header has been corrupted. The EEPROM must be restored from the TK tape drive. ?54 EEPROM revision mismatch. Secondary processor has revision x.xx/y.yy.
Table B–2 (Cont.): Model 400 Standard Console Error Messages Error Message Meaning ?5F EEPROM header version mismatch. Processors have different versions of EEPROMs. ?61 EEPROM header or area has bad format. All or part of the EEPROM contains inconsistent data and is probably corrupted. Reload the EEPROM from the TK tape. ?62 Illegal node number. The specified node number is invalid. ?63 Unable to locate console tape device. The console could not locate the I/O adapter that controls the TK tape.
Table B–2 (Cont.): Model 400 Standard Console Error Messages Error Message Meaning ?6E EEPROM Revision = x.xx/y.yy. The EEPROM contents are at revision x.xx with revision y.yy patches. ?6F Major revision mismatch between tape image and EEPROM. The major revision of tape and EEPROM do not match. The requested operation cannot be performed. ?70 Tape image Revision = x.xx/y.yy. The EEPROM image on the TK tape is at revision x.xx with revision y.yy patches. ?73 System serial number updated.
Table B–2 (Cont.): Model 400 Standard Console Error Messages Error Message Meaning ?7C I/O adapter configuration error at node n The I/O adapter at node n is configured improperly. ?7D Vector module is disabled—check KA64A revision at XMI node n The vector module is attached to a KA64A module that is not at the revision level required. ?83 Loading system software.1 The console is attempting to load the operating system in response to a BOOT command, power-up, or restart failure. ?84 Failure.
Table B–2 (Cont.
Appendix C EEPROM Mismatches and the UPDATE Command Table C–1 shows the results of trying to update processor modules from primary processors that have different ROM revisions from the secondary being updated. Table C–1: UPDATE Results on EEPROM Mismatches Primary ROM Revision Secondary ROM Revision Results after UPDATE issued (xrp) ROM Revisions 1.0 2.0 Processor EEPROM corrupted, but still powers up. 1.0 3.0 Processor EEPROM corrupted, but still powers up. 2.0 1.
Table C–1 (Cont.): UPDATE Results on EEPROM Mismatches Primary ROM Revision Secondary ROM Revision Results after UPDATE issued KA62A ROM Revisions 3.0 5.0 Processor updated. Power-up tests broken. Processor will not be recognized. 5.0 3.0 Use EVUCA for updates to secondary EEPROM. Update not allowed.
Appendix D Control Flags for Booting With the console BOOT command, you can control various phases of booting by setting bits in General Purpose Register R5: BOOT /R5:n where n is in hexadecimal notation. For example, to set bit 4 in R5 when booting, you would enter: BOOT /R5:10 The R5 bit functions are defined by VMB and by the operating system. The value –1 in R5 is reserved for Digital. Table D–1: R5 Bit Functions for VMS Bit Function 0 Conversational boot.
Table D–1 (Cont.): R5 Bit Functions for VMS Bit Function 6 Image header. The transfer address of the secondary loader image comes from the image header for that file. If this flag is not set, control shifts to the first byte of the secondary loader. 8 File name. VMB prompts for the name of a secondary loader. 9 Halt before transfer. VMB executes a HALT instruction before transferring control to the secondary loader. 13 No effect, since console program tests memory.
Glossary Adapter A node that interfaces other buses, communication lines, or peripheral devices to the (XMI) bus or the VAXBI bus. Address space The 1 terabyte of physical address space that the XMI bus is capable of supporting; currently the XMI bus supports 1 gigabyte of physical memory. Asymmetric multiprocessing A multiprocessing configuration in which the processors are not equal in their ability to execute operating system code.
Bootblock Block zero on the system disk; it contains the block number where the virtual memory boot (VMB) program is located on the system disk and contains a program that, with the boot primitive, reads VMB from the system load device into memory. CIBCA VAXBI CI port interface; connects a system to a Star Coupler. CIXCD XMI CI port interface; connects a system to a Star Coupler. Cold start An attempt by the primary processor to boot a new copy of the operating system.
DSB32 VAXBI adapter communication device; provides two synchronous lines. DWMBB The XMI-to-VAXBI adapter; a 2-module adapter that allows data transfer from the XMI to the VAXBI; DWMBB/A is the module in the XMI card cage, and DWMBB/B is the VAXBI module. Every VAXBI on a VAX 6000 series system must have a (XBI) adapter. Ethernet-based compact disk server The RRD40 compact disk drive, a console load device, functions as a server on the Ethernet.
(XMA2) XMI memory array; a memory subsystem of the XMI. Memory is a global resource equally accessible by all processors on the (XMI). A memory module can have 32, 64, or 128 Mbytes of memory, consisting of MOS 1–Mbit or MOS 4–Mbit dynamic RAMs, ECC logic, and control logic. Node An (XMI) node is a single module that occupies one of the 14 logical and physical slots on the (XMI) bus.
Shadow set Two disks functioning as one disk, each shadowing the information contained on the other, controlled by an HSC controller under the VMS operating system. Symmetric multiprocessing A multiprocessing system configuration in which all processors have equal access to operating system code residing in shared memory and can perform all, or almost all, system tasks. System root In a BOOT commmand, the argument to the /R5 qualifier. TBK70 VAXBI adapter connecting the TK tape drive to the system.
(XMI) Corner The portion of an (XMI) module that connects to the backplane and provides an electrically identical interface for every XMI node.
Index A Architecture, 1–4 with vector processors, 5–4 B Backup cache KA64A processor, 4–7 Booting control flags for, D–1 to D–2 Boot processor how to replace, 3–44 how to replace KA64A, 4–50 KA62B processor, 3–10 KA64A processor, 4–10 BPD in self-test display, 3–17, 4–19, 5–11 C Configuration rules KA62B processor, 3–4 KA64A processor, 4–4 memory, 6–4 processor, 5–6 (xbi_plus) adapter, 7–6 to 7–7 Console commands KA62B processor, 3–38 KA64A processor, 4–40 SET MEMORY command, 6–13, 6–15 SHOW ME
ETF in self-test display, 3–17, 4–19, 5–11 EVUCA session on KA62B, 3–50 to 3–53 on KA64A, 4–56 to 4–59 Extended test KA62B processor, 3–13 KA64A processor, 4–14 F FV64A processor inserting in XMI card cage, 5–25 I I/O nodes, 1–5 Interleaving, 6–10 console commands, 6–12 default, 6–11 K KA62B processor configuration rules, 3–4 console commands, 3–38 CPU replacement multiprocessor system, 3–44 to 3–47 single processor system, 3–40 to 3–43 functional description, 3–6 how to add new, 3–48 how to replace boot
KA64A processor (Cont.
Registers (Cont.
Troubleshooting flowcharts, 1–8 to 1–10 TYP in self-test display, 3–17, 4–19, 5–11 U ULTRIX booting, D–2 V VAX/DS, 2–30 to 2–47 booting from Ethernet, 2–32 to 2–33 description, 2–31 diagnostics, 5–16 documentation, 2–30 exerciser tests, 2–31 explanation of levels, 2–30 function tests, 2–31 HELP in, 2–31 interrupt, 2–39, 2–41 KA62B diagnostics, 3–34 KA64A diagnostics, 4–36 list of diagnostics, 2–42 to 2–47 logic tests, 2–31 running in user mode, 2–34 to 2–35 running standalone, 2–34 to 2–35 sample session,