arti/irix-657m-src
1
0
Fork 0
Code Activity
Files
8fc8fa80899c66937979cd5b807766a40b74cd13
irix-657m-src/stand/arcs/IP27prom/doc/html/ip27prom.html
calmsacibis995 8fc8fa8089 Source code upload
2022-09-29 17:59:04 +03:00

2779 lines
174 KiB
HTML
Raw Blame History

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<HTML VERSION="2.0">
<HEAD>
<!-- WEBMAGIC VERSION NUMBER="2.0.1" -->
<!-- WEBMAGIC TRANSLATION NAME="ServerRoot" SRC="/var/www/htdocs/" DST="/" -->
<!-- WEBMAGIC TRANSLATION NAME="ProjectRoot" SRC="./" DST="" -->
<TITLE>Silicon Graphics Origin2000 IP27prom Technical Reference Manual</TITLE>
</HEAD>
<BODY VLINK="#014c02" LINK="#000396" BACKGROUND="background.gif" BGCOLOR="#ffffff" TEXT="#000000">
<HR>
<CENTER><P ALIGN="CENTER"><B><FONT SIZE="5">Silicon Graphics Origin200/2000</FONT></B></P>
</CENTER><CENTER><P ALIGN="CENTER"><IMG SRC="3dlogo.gif" WIDTH="361" HEIGHT="64" SGI_SETWIDTH SGI_SETHEIGHT SGI_FULLPATH="/tmp_mnt/hosts/ddt/b/csm/ficus/stand/arcs/IP27prom/doc/html/3dlogo.gif"></P>
</CENTER><CENTER><P ALIGN="CENTER"><B><FONT SIZE="5">Technical Reference Manual</FONT></B></P>
</CENTER><CENTER><P ALIGN="CENTER"><I>Last Revised: December 30, 1996</I><BR>
<I>by Curt McDowell, <A HREF="mailto:csm@sgi.com">csm@sgi.com</I></A></P>
</CENTER><HR>
<H2>Table of Contents</H2>
<UL>
<LI><A HREF="#DocumentOverview">Document Overview</A>
<UL>
<LI><A HREF="#AboutThisDocument">About this Document </A>
<LI><A HREF="#IntendedAudience">Intended Audience </A>
<LI><A HREF="#RelatedDocuments">Related Documents</A>
</UL>
<LI><A HREF="#Origin2000SystemOverview">Origin2000/200 System Overview </A>
<UL>
<LI><A HREF="#SlotNumbering">Slot Numbering </A>
<LI><A HREF="#PartNumbers">Part Numbers </A>
<LI><A HREF="#NodeIDsNASIDs">Node IDs (NASIDs) </A>
<LI><A HREF="NumberInACan">NICs (Number In a Can)</A>
<LI><A HREF="#MemoryConfigurations">Memory Configurations</A>
<LI><A HREF="#ModuleNumbers">Module Numbers</A>
</UL>
<LI><A HREF="#ModuleSystemController">Module System Controller </A>
<UL>
<LI><A HREF="#AlternateConsolePort">Alternate Console (Diagnostic) Port </A>
<LI><A HREF="#MSCSecurity">Security</A>
<LI><A HREF="#MSCCommands">Commands </A>
</UL>
<LI><A HREF="#MultiModuleSystemController">Multi-Module System Controller</A>
<UL>
<LI><A HREF="#FunctionsOfTheMMSC">Functions of the MMSC</A>
<LI><A HREF="#MMSCConnectivity">MMSC Connectivity</A>
</UL>
<LI><A HREF="#IP27prom">IP27prom </A>
<UL>
<LI><A HREF="#PROMCompatibility">PROM Compatibility</A>
<LI><A HREF="#SystemBootProcess">System Boot Process </A>
<LI><A HREF="#DebugSwitchUse">Using the System Controller Debug Switches </A>
<LI><A HREF="#DebugSwitchAssignments">System Controller Debug Switch Assignments </A>
<LI><A HREF="#PROMImages">PROM Images</A>
</UL>
<LI><A HREF="#PowerOnDiags">Power-On Diagnostics </A>
<UL>
<LI><A HREF="#BootStatusLEDs">Boot Status LEDs </A>
<LI><A HREF="#ReadingTheLEDs">Reading the LEDs </A>
<LI><A HREF="#PODMode">POD Mode (PROM Command Interpreter) </A>
<LI><A HREF="#PODConsoles">POD Consoles </A>
<LI><A HREF="#PODConstants">Constants</A>
<LI><A HREF="#PODExpressions">Expressions</A>
<LI><A HREF="#PODStatements">Statements</A>
<LI><A HREF="#PODAddressModifiers">Address Modifiers </A>
<LI><A HREF="#PODHardwareRegisters">Hardware Registers </A>
<UL>
<LI><A HREF="#HubPIRegs">Hub PI Registers </A>
<LI><A HREF="#HubMDRegs">Hub MD Registers </A>
<LI><A HREF="#HubIIRegs">Hub II Registers </A>
<LI><A HREF="#HubNIRegs">Hub NI Registers </A>
<LI><A HREF="#HubCoreRegs">Hub Core Registers </A>
<LI><A HREF="#CrossbowRegs">Crossbow Registers (midplane) </A>
<LI><A HREF="#RouterRegs">Router Registers </A>
<LI><A HREF="#Cop0Regs">R10000 Coprocessor 0 Registers </A>
</UL>
<LI><A HREF="#PODSymbols">Symbols</A>
</UL>
<LI><A HREF="#PODModeCommands">POD Mode Commands </A>
<UL>
<LI><A HREF="#CommandConventions">Conventions</A>
<LI><A HREF="#CommandSummary">Command Summary </A>
<LI><A HREF="#CommandDescriptions">Command Descriptions </A>
</UL>
<LI><A HREF="#Debugging">Debugging with the IP27prom </A>
<UL>
<LI><A HREF="#DebugReset">Reset </A>
<LI><A HREF="#DebugNMI">Non-Maskable Interrupt (NMI) </A>
<LI><A HREF="#KernelDebugging">Kernel Debugging</A>
<LI><A HREF="#DebugMSC">Use of the MSC </A>
<LI><A HREF="#DebugFastLoops">Fast Loops </A>
<LI><A HREF="#DebugMemoryTests">Memory Tests </A>
<UL>
<LI><A HREF="#BankOrganization">Bank Organization</A>
<LI><A HREF="#RunningTheTests">Running the Tests </A>
</UL>
<LI><A HREF="#DebugProblemReporting">Problem Reporting </A>
<LI><A HREF="#FlashingPROMs">Flashing PROMs</A>
</UL>
<LI><A HREF="#PROMLogOverview">PROM Log Overview </A>
<UL>
<LI><A HREF="#ReservedPROMLogVariables">Reserved PROM Log Variables </A>
<LI><A HREF="#ErrorLogKeys">Error Log Keys </A>
<LI><A HREF="#ListKeys">List Keys </A>
</UL>
<LI><A HREF="#Origin2000Routers">Origin2000 Routers </A>
<UL>
<LI><A HREF="#ReadingTheRouterLEDs">Reading the Router LEDs </A>
<LI><A HREF="#VectorAddressing">Vector Addressing </A>
<LI><A HREF="#SystemConfigurations">System Configurations </A>
<UL>
<LI><A HREF="#FullRouterConfiguration">Full Router Configuration </A>
<LI><A HREF="#FirstStarRouterConfiguration">Star Router Configuration (First Possibility)</A>
<LI><A HREF="#SecondStarRouterConfiguration">Star Router Configuration (Second Possibility)</A>
<LI><A HREF="#NullRouterConfiguration">Null Router Configuration </A>
</UL>
</UL>
</UL>
<HR>
<H2><A NAME="DocumentOverview">Document Overview</A></H2>
<H3><A NAME="AboutThisDocument">About This Document</A></H3>
<P>This manual contains information needed to use the IP27prom to boot or debug
an Origin2000 system. Coverage includes the following, but does not extend
into the IO6prom or IRIX Kernel:</P>
<UL>
<LI>Module System Controller
<LI>Multi-Module System Controller
<LI>CrayLink Interconnect Topology Primer
<LI>IP27prom Operation
<LI>IP27prom Command Set
<LI>Debugging with the IP27prom
</UL>
<P>A lot of basic information about the Origin2000 is included to minimize
the number of other documents required to use the IP27prom. Information
is presented in a reference format.</P>
<H3><A NAME="IntendedAudience">Intended Audience</A></H3>
<UL>
<LI>Kernel developers
<LI>IP27prom and IO6prom engineers
<LI>Origin2000/200 hardware developers
<LI>Manufacturing engineers
<LI>Field engineers with need to know
</UL>
<P><IMG SRC="mad_hacker.gif" ALIGN="RIGHT" WIDTH="48" HEIGHT="48" SGI_SETWIDTH SGI_SETHEIGHT SGI_FULLPATH="/tmp_mnt/hosts/ddt/b/csm/ficus/stand/arcs/IP27prom/doc/html/mad_hacker.gif">This document contains no proprietary information and is suitable for use
by SGI Power Customers.</P>
<H3><A NAME="RelatedDocuments">Related Documents (SGI Access Only)</A></H3>
<UL>
<LI><A HREF="http://b7/doc/index.html">ASD Doc Depot</A> (Engineering Access Only)
<UL>
<LI><A HREF="http://b7/doc/arch/lego/sys_spec.book.doc.html">Lego System Specification</A>
<LI><A HREF="http://b7/doc/chips/hub_spec/hub.book.doc.html">Hub Specification</A>
<LI><A HREF="http://b7/doc/chips/hub_prog_man/hub.regbook.doc.html">Hub Programming Manual </A>
<LI><A HREF="http://b7/doc/chips/legonet/legonet.overview.doc.html">CrayLink Interconnect Specification</A>
</UL>
<LI><A HREF="http://babylon.engr.sgi.com/lego/firmware.html">Lego Firmware</A>
<LI>Module System Controller (Engineering Access Only)
<UL>
<LI><A HREF="http://babylon.engr.sgi.com/lego/elsc/elsc-hardware.ps">Hardware Manual (PostScript)</A>
<LI><A HREF="http://babylon.engr.sgi.com/lego/elsc/elsc-firmware.ps">Firmware Manual (PostScript)</A>
</UL>
<LI><A HREF="http://uniscan.engr/~rdb/FFSC/index.html">Multi-Module System Controller</A>
<UL>
<LI><A HREF="http://uniscan.engr/~rdb/FFSC/commands.html">Command Language</A>
<LI><A HREF="http://uniscan.engr/FFSC/addressing.html">Network Addressing</A>
</UL>
<LI><A HREF="http://babylon.engr.sgi.com/lego/doc/fru.ps">FRU Analyzer (PostScript)</A>
<LI><A HREF="http://babylon.engr.sgi.com/lego/doc/serial.html">Serial Numbers</A>
<LI><A HREF="http://bits.csd/digest/topics/Lego/">Global Customer Support</A>
</UL>
<HR>
<H2><A NAME="Origin2000SystemOverview">Origin2000/200 System Overview</A></H2>
<H3><A NAME="SlotNumbering">Slot Numbering</A></H3>
<CENTER><P ALIGN="CENTER"><IMG SRC="slot_numbering.gif" WIDTH="603" HEIGHT="289" SGI_SETWIDTH SGI_SETHEIGHT SGI_FULLPATH="/tmp_mnt/hosts/ddt/b/csm/ficus/stand/arcs/IP27prom/doc/html/slot_numbering.gif"></P>
</CENTER><CENTER><P ALIGN="CENTER"><EM>Picture Courtesy of Steve Whitney</EM></P>
</CENTER><P>The two Router card slots in the front right of the machine are numbered
R1 and R2, going left to right. Router cable ports are numbered 1, 2, and
3 from top to bottom. Router ports 4, 5, and 6 are internal to the system.</P>
<P>The four Node card slots in the back of the machine are numbered N1 through
N4, going <I>right to left</I>. Each Node card contains two CPUs called A and B. Therefore, each module
may contain up to 8 CPUs, which are called 1A, 1B, 2A, 2B, 3A, 3B, 4A, and
4B (or sometimes simply CPU 0 through CPU 7).</P>
<P>R1 is connected directly to N1 and N2, while R2 is connected directly to
N3 and N4 (see <A HREF="#VectorAddressing">Vector Addressing</A> for a more thorough treatment of Router port connectivity).</P>
<P>IO1 through IO6 are connected directly to the Crossbows on N1 and N3, while
IO7 through IO12 are connected directly to the Crossbows on N2 and N4. </P>
<H3><A NAME="PartNumbers">Part Numbers</A></H3>
<CENTER><P ALIGN="CENTER"><TABLE BORDER=1>
<CAPTION>Common Part Numbers</CAPTION>
<TR><TH> Number </TH><TH ALIGN=LEFT> Part </TH></TR>
<TR><TD ALIGN=CENTER>013-1547</TD><TD> Origin2000 Midplane (8 CPU + 12 I/O) </TD><TR><TR><TD ALIGN=CENTER>013-1025</TD><TD> Origin200 Motherboard </TD><TR><TD ALIGN=CENTER>030-0841</TD><TD> Origin2000 Router Card </TD><TR><TD ALIGN=CENTER>030-0733</TD><TD> Origin2000 IP27 Node Card </TD></TR>
<TR><TD ALIGN=CENTER>030-1124</TD><TD> Server BaseIO Card </TD></TR>
<TR><TD ALIGN=CENTER>030-0872</TD><TD> MSCSI Card </TD></TR>
<TR><TD ALIGN=CENTER>030-0873</TD><TD> MENET Card </TD></TR>
<TR><TD ALIGN=CENTER>030-0880</TD><TD> MIO Card </TD></TR>
<TR><TD ALIGN=CENTER>030-0927</TD><TD> FibreChannel Card </TD></TR>
<TR><TD ALIGN=CENTER>030-0968</TD><TD> HIPPI_S Card </TD></TR>
<TR><TD ALIGN=CENTER>030-0956</TD><TD> HPCX Card </TD></TR>
</TABLE></P>
</CENTER><H3><A NAME="NodeIDsNASIDs">Node IDs (NASIDs)</A> </H3>
<H4>What is a Node ID?</H4>
<P>During the boot process, the PROM assigns a Node ID to each Hub in the system.
Node IDs are small integer values ranging from 0 to 255. Since there is
one Hub on each node card, each Node card receives its own Node ID and the
ID is shared between the CPUs on the same node card.</P>
<P>Node IDs are more correctly referred to as NASIDs (NUMA Address Space Identifiers).
Hardware folks use the term Node ID, while software folks use the term NASID
to avoid confusion with several other types of node identifiers used internal
to the IRIX kernel.</P>
<H4>What are Node IDs used for?</H4>
<P>Node IDs allow any node to access the full address spaces of any other node.
Addressing a remote node's space is done simply by placing the remote node's
ID in bits 32 through 40 of the desired physical address. This is true whether
talking to the node's memory, I/O devices, Hub chip, PROM, etc. For example,
one could talk to various parts of remote node 7's address space using addresses
as follows:</P>
<UL>
<LI><B>0x9000000700000000</B> - HSPEC (PROMs, back door directory memory)
<LI><B>0x9200000700000000</B> - I/O windows, including Hub and Bridge registers
<LI><B>0x9600000700000000</B> - Base of bank 0 memory, treated as uncached
<LI><B>0xa800000700000000</B> - Base of bank 0 memory, treated as cached
</UL>
<H4>How do node IDs get assigned?</H4>
<P>After a system reset, there is a period of time when no Node IDs are assigned.
In this situation, all Node IDs are zero and it is not possible to access
the address spaces of remote nodes.</P>
<P>A special Hub feature called Vector Routing provides a way to access a small
subset of Hub registers on a remote node. It is through Vector Routing that
the CrayLink Interconnect topology is discovered, a global master is arbitrated,
node IDs are assigned and distributed to all nodes in the system, and the
full address space access becomes defined.</P>
<P>After the Node IDs are assigned, routing tables in each Hub and Router in
the system are programmed with information that allows nodes to find one
another, so that a Node IDs is effectively used as a network address. The
Node ID is used as an index into the routing tables at each network hop
in order to determine to which router output port a request or response
should be forwarded.</P>
<H3><A NAME="NumberInACan">NICs (Number In a Can)</A></H3>
<P>A tiny chip from Dallas Semiconductor called a NIC is used extensively throughout
the Origin2000 system. There is a NIC on each type of board in the system,
including the Node card, Router card, BaseIO card (with two NICs), module
midplane, etc.</P>
<P>The NIC contains a 48-bit number that is permanently laser-burned in at
the time the NIC is manufactured and is guaranteed to be unique from all
other NICs. The Node card NICs help identify Nodes during the boot process
when the system is probing the network. The NIC on the midplane is used
for software licensing.</P>
<P>In addition to the 48-bit number, NICs also contain several <I>pages</I> of non-volatile memory that can be read or written by the system. This
memory is used to store additional information, primarily for purposes of
inventory tracking, such as:</P>
<UL>
<LI>Board type
<LI>Board revision number
<LI>Board serial number (as it appears on the bar code)
<LI>Board-specific information (e.g., on the BaseIO card, the Ethernet MAC address)
</UL>
<P>In general, Origin2000 software never writes to the NIC. Rather, it is programmed
once by an external NIC programming device in the manufacturing plant, and
subsequently reprogrammed by Manufacturing should a board be upgraded to
a new revision level.</P>
<H3><A NAME="MemoryConfigurations">Memory Configurations</A></H3>
<P>The Origin family memory consists of two parts, the <I>system memory</I> and the <I>directory memory</I>. Directory memory is used for storing cache coherence protocol information
and is much smaller than system memory.</P>
<P>The Origin2000 supports from 64 MB to 4 GB of RAM per node card. Two types
of directory memory are available for the Origin2000, referred to as <I>standard</I> and <I>premium</I>. Premium directory memory is required for systems that are not a subset
of a standard 32-processor hypercube. They can also be used in smaller systems
to provide greater process migration accuracy.</P>
<P>System memory must be populated one bank at a time. Each bank consists of
two memory DIMM slots and one directory DIMM slot (be careful, because the
three slots are separated from one another on the node card). The two memory
DIMMs making up one bank must contain the same size DIMMs. Each bank may
contain a different amount of memory. There should be memory in bank zero.</P>
<P>Standard directory memory resides in the same DIMMs in which the system
memory resides, and is automatically populated when the system memory is
populated. The directory DIMM slots are left empty.</P>
<P>Premium directory memory is populated by inserting additional smaller DIMMs
into the directory DIMM slots, adding more precision to the standard directory
memory. </P>
<P>The Origin200 supports from 32 MB to 4 GB of RAM per node card and does
not support premium directory memory. Banks are populated from two outermost
DIMM slots (making up bank 0) to the two innermost DIMM slots (making up
bank 3).</P>
<H3><A NAME="ModuleNumbers">Module Numbers</A></H3>
<P>In an Origin2000 system, each Module (4 node cards, 8 processors) is assigned
a unique number from 1 to 255, called the <I>module number</I>. The module number is the mechanism by which Irix identifies particular
modules. The module number is stored in MSC NVRAM. A backup copy of the
module number is stored in each node card PROM Log, so that in the event
that the MSC NVRAM becomes inaccessible, the module number is voted from
the last value stored in the PROM Logs. A module number of 0 indicates that
a module number has not yet been assigned.</P>
<P>The most important use of module numbers is device naming in the Irix Hardware
Graph. Disks and other devices are referred to by the number of the module
containing them, as well as the slot within that module. For example, the
root disk device might be called</P>
<P><I>/hw/module/1/slot/io1/baseio/pci/0/scsi_ctlr/0/target/1/lun/0/disk/partition/0/block</I></P>
<P>indicating that the disk is in module 1, slot io1, BaseIO card, PCI slot
0, etc.</P>
<P>If a module number is changed, all affected devices in the hardware graph
will change names. This would most likely require the system administrator
to reconfigure filesystem mounts, among other things.</P>
<P>Maintainence of module numbers may be performed using the IP27prom <B>module</B> command, or using the MSC <B>mod</B> command. When module numbers are changed in this manner, the change will
not take place until the next time the system is rebooted.</P>
<P>The IO6prom verifies the consistency of module numbers. To be consistent,
every module must have a number assigned to it, and there must not be any
duplicate numbers.</P>
<P>Modules found to be without numbers will have a number automatically assigned
to them, and then the system will reboot. Therefore, if a new module is
added to an existing system, a module number will be automatically assigned
and any attached devices will show up in the hardware graph.</P>
<P>Duplicate module numbers will prevent the system from booting until the
problem is rectified. A message indicating the problem will display on the
system console.</P>
<H2><A NAME="ModuleSystemController">Module System Controller</A></H2>
<P><B><I>Note </I></B>: The MSC was at one time called the Entry Level System Controller, or ELSC.
They are one and the same.</P>
<P><IMG SRC="elsc_front.gif" ALIGN="RIGHT" WIDTH="206" HEIGHT="295" BORDER="0" SGI_FULLPATH="/tmp_mnt/hosts/ddt/b/csm/ficus/stand/arcs/IP27prom/doc/html/elsc_front.gif">The MSC front panel is shown in the figure and comprises the following elements:</P>
<UL>
<LI>Reset momentary pushbutton switch, with associated LED
<LI><A HREF="#DebugNMI">NMI</A> momentary pushbutton switch, with associated LED
<LI>Eight-character alphanumeric dot matrix LED display
<LI>Three-position rotary keyswitch (Off, On, Diagnostics)
<LI>DIN-type RS-232 serial port connector (diagnostics port)
<LI>A block of eight small DIP switches (called the <A HREF="#DebugSwitchUse">Debug Switches</A>)
</UL>
<H3><BR CLEAR=ALL>
<A NAME="AlternateConsolePort">Alternate (Diagnostic) Console Port</A></H3>
<P>The Origin2000 Module System Controller (MSC) front panel has a DIN-type
RS-232 serial port, labelled the Diagnostic Port, and internally referred
to as the Alternate Console Port (ACP). A second connector for the same
serial port is provided in the back of the module for when it is to be connected
to a Multi-Module System Controller (MMSC). The ACP is always available
and is primarily used for debugging during manufacturing bring-up of a system,
as well as system debugging when for some reason the regular serial port
console is not available.</P>
<P>An RS-232 dumb terminal connected to the ACP can talk to the MSC, and through
the MSC to the individual CPUs. All of the CPUs in a single module must
share this console. For this reason, output from multiple CPUs appears on
the console simultaneously, interleaving on a line by line basis, with CPU
identification at the start of each line in the form of a slot (1 to 4)
and slice (A or B). The MSC can be directed to send ACP keyboard input to
a particular CPU. It can also be directed to show only the output from a
particular CPU.</P>
<P>The MSC itself has a command set. Commands are sent to the MSC by typing
the escape character ^T (Control-T), followed by the text of the command
and <TT>ENTER</TT>. Ordinary ACP output is discarded between the time that the ^T and the <TT>ENTER</TT> are received. If echoing is enabled (default), the prompt <B>MSC&gt;</B> will be displayed upon the reception of the ^T and characters typed will
be visible. If echoing is not enabled (see the <B><A HREF="#MSCCommandEch">ech</B></A> command), nothing will be visible as the command is typed.</P>
<H3><A NAME="MSCSecurity">Security</A></H3>
<P>MSC commands which could potentially be destructive to system operation
may only be executed when the MSC is in supervisor mode. If the MSC is not
in supervisor mode, these commands result in the following error:</P>
<PRE>
err perm
</PRE>
<P>The MSC is automatically in supervisor mode when the front panel keyswitch
is in the <I>Diag</I> position. It may also be placed in supervisor mode by issuing the MSC command <B>pas none</B> to enter the four-character MSC password, where <B>none</B> is the default MSC password. The command <B>pas s abcd</B> would change the MSC password to <B>abcd</B>.</P>
<H3><A NAME="MSCCommands">Commands</A></H3>
<P>Commands are typed to the MSC ACP by prefixing them with a <B>^T</B> (Control-T) character. Commands are visible as they are typed only if echoing
is turned on (which is true after power-on). Each command is three letters
in length. Some of them take parameters. Numeric parameters are <I>always</I> in hexadecimal. All commands return responses consisting of <B>ok</B> and possibly some hexadecimal values, or one of the three error responses:</P>
<P><TABLE BORDER=1>
<CAPTION>MSC Responses</CAPTION>
<TR><TH> Response </TH><TH ALIGN=LEFT> Reason </TH></TR>
<TR><TD ALIGN=CENTER>err perm</TD><TD> Permission denied. Keyswitch must be in diagnostic position, or password
entered via the <B>pas</B> command. </TD> <TR><TD ALIGN=CENTER>err cmd</TD><TD> Unrecognized command mnemonic. </TD> <TR><TD ALIGN=CENTER>err arg</TD><TD> Invalid command argument(s). </TD></TR>
</TABLE> </P>
<P>The supported commands are:</P>
<P><TABLE BORDER=1>
<CAPTION>MSC Commands</CAPTION>
<TR><TH> Command </TH><TH ALIGN=LEFT> Function </TH></TR>
<TR><TD ALIGN=CENTER>aut 1</TD><TD> Turns on automatic power-on mode so the MSC automatically issues a <B>pwr u</B> when the MSC is powered on (Origin200 only). </TD></TR>
<TR><TD ALIGN=CENTER>aut 0</TD><TD> Turns off automatic power-on mode (Origin200 only). </TD></TR>
<TR><TD ALIGN=CENTER>clr</TD><TD> Resets all MSC options to their power-up defaults. This includes echo mode,
no heartbeats, etc. </TD></TR>
<TR><TD ALIGN=CENTER>dbg</TD><TD> Displays the virtual and physical <A HREF="#DebugSwitchUse">Debug Switch</A> bytes.</TD></TR>
<TR><TD ALIGN=CENTER>dbg <I>V</I> <I>P</I></TD><TD> Sets the virtual <A HREF="#DebugSwitchUse">Debug Switch</A> byte to <I>V</I>, and the physical <A HREF="#DebugSwitchUse">Debug Switch</A> byte to <I>P</I>.</TD></TR>
<TR><TD ALIGN=CENTER>dsp <I>M</I></TD><TD> Displays message <I>M</I> on the 8-character alphanumeric display. M may contain up to 8 ASCII characters
other than <TT>NUL</TT>. For example, <B>dsp testing</B> would overwrite the first seven characters with &quot;testing,&quot; while leaving
the eighth character alone. </TD></TR>
<TR><TD ALIGN=CENTER>dsc <I>C</I></TD><TD> Modifies only the Nth character on the alphanumeric display. <I>N</I> is a digit from 0 to 7, and <I>C</I> is any ASCII character other than <TT>NUL</TT>. </TD></TR>
<TR><TD ALIGN=CENTER>ech 0</TD><TD> Turns off echoing as MSC commands are entered. </TD></TR>
<TR><TD ALIGN=CENTER>ech 1</TD><TD> Turns on echoing. </TD></TR>
<TR><TD ALIGN=CENTER><A NAME="MSCCommandEch">ech</A></TD><TD> Toggles the echoing. Echoing is on by default after reset. </TD></TR>
<TR><TD ALIGN=CENTER>fan</TD><TD> If no fan has failed, returns <B>n</B> or <B>h</B>, according to whether the fans are currently operating at Normal or High
speed. If a fan has failed on an Origin200, returns <B>f x</B>, where x is a bit map of the failed fans (fan 1 = 1, fan 2 = 2, fan 3=
4). If a fan has failed on an Origin2000, returns <B>f xyz</B>, where xyz are bit maps of the failed fans by row (fan 1 = 1, fan 2 = 2,
fan 3= 4). When the MSC detects that a fan has failed, it speeds up the remaining fans
to maintain cooling levels. The failed fan should be replaced because the
increased speed reduces the life of the remaining fans. If more than one
fan fails, the system is powered down. </TD></TR>
<TR><TD ALIGN=CENTER>fan n</TD><TD> Sets the fans to normal speed. </TD></TR>
<TR><TD ALIGN=CENTER>fan h</TD><TD> Sets the fans to high speed. </TD></TR>
<TR><TD ALIGN=CENTER>key</TD><TD>Returns the status of the key-switch as <B>off</B>, <B>on</B>, or <B>diag</B>.</TD></TR>
<TR><TD ALIGN=CENTER>mod</TD><TD>Displays the number of the module containing the MSC.</TD></TR>
<TR><TD ALIGN=CENTER>mod <I>xx</I></TD><TD>Sets the number of the module containing the MSC to <I>xx</I>, where <I>xx</I> is a hexadecimal <A HREF="#ModuleNumbers">module number</A> from 01 to ff (a module number of 00 indicates no module number is yet
assigned).</TD></TR>
<TR><TD ALIGN=CENTER>nmi</TD><TD> Sends a hardware <A HREF="#DebugNMI">NMI</A> to all node cards in the MSC's module. </TD></TR>
<TR><TD ALIGN=CENTER>pas <I>xxx</I> </TD><TD>When <I>xxxx</I> is replaced with the correct four-character password, places the MSC into
supervisor mode where various restricted commands may be used. If the MSC
is not in supervisor mode, restricted commands will result in a permission
error (<B>err perm</B>). The MSC is automatically in supervisor mode if the key-switch is in the
diag position. </TD></TR>
<TR><TD ALIGN=CENTER>pas s <I>xxxx</I></TD><TD> Set the password to <I>xxxx</I>. This is a restricted command. The password is stored in NVRAM and defaults
to <B>none</B>. </TD></TR>
<TR><TD ALIGN=CENTER>pwr</TD><TD> Returns <B>u</B> or <B>d</B>, according to whether the system is powered up or down. </TD></TR>
<TR><TD ALIGN=CENTER>pwr u</TD><TD> Powers the system up. </TD></TR>
<TR><TD ALIGN=CENTER>pwr d</TD><TD> Powers the system down. </TD></TR>
<TR><TD ALIGN=CENTER>pwr d <I>N</I></TD><TD> Waits N seconds and then powers the system down. <I>N</I> is a hex value from 5 to 258 (5 to 600 decimal). </TD></TR>
<TR><TD ALIGN=CENTER>pwr c <I>N</I></TD><TD> Powers the system down, waits N seconds, then powers the system back up. <I>N</I> is a hex value from 5 to 258 (5 to 600 decimal). </TD></TR>
<TR><TD ALIGN=CENTER>rst</TD><TD> Sends a hardware <A HREF="#DebugReset">reset</A> to all node cards in the MSC's module. </TD></TR>
<TR><TD ALIGN=CENTER>rsw</TD><TD> Returns the current Debug Switch settings as an inverted hexadecimal byte.
See section on <A HREF="#DebugSwitchUse">Debug Switch Use</A> for bit correspondence. </TD></TR>
<TR><TD ALIGN=CENTER>sel <I>cpu</I></TD><TD> Selects which CPU is to receive input from the ACP. Anything typed on the
ACP which is not an escaped command is sent through to the selected CPU.
CPUs are named by slot and slice as described in Slot and CPU Numbering.
For example, <B>sel 2a</B> would select CPU A in slot N2 for input. </TD></TR>
<TR><TD ALIGN=CENTER>sel</TD><TD> Displays which CPU is currently selected to receive ACP input, or <B>none</B> if no CPU is selected. </TD></TR>
<TR><TD ALIGN=CENTER>sel auto</TD><TD> Causes the last CPU to have output anything to be automatically selected
to receive ACP input (this is the power-up default). </TD></TR>
<TR><TD ALIGN=CENTER>sel none</TD><TD> Causes no CPU to be selected to receive ACP input. </TD></TR>
<TR><TD ALIGN=CENTER>see <I>cpu</I></TD><TD> Causes output from all CPUs other than a specific CPU to be discarded (ordinarily,
the output from all CPUs is displayed intermixed by line). CPUs are named
by slot and slice as described in Slot and CPU Numbering. For example, <B>see 2a</B> would cause only CPU 2A's output to be shown. </TD></TR>
<TR><TD ALIGN=CENTER>see</TD><TD> Displays which CPU is currently being shown, or <B>all</B> if all CPUs are being shown. </TD></TR>
<TR><TD ALIGN=CENTER>see all</TD><TD> Causes output from all CPUs to be displayed (this is the power-up default). </TD></TR>
<TR><TD ALIGN=CENTER>tmp</TD><TD> Returns <B>o</B>, <B>h</B>, or <B>n</B>, indicating whether the system is over-temperature, dangerously high-temperature,
or normal temperature, respectively. </TD></TR>
<TR><TD ALIGN=CENTER>ver</TD><TD> Reports the MSC firmware revision number. </TD></TR>
</TABLE> </P>
<P>The following MSC commands are not documented here: <B>get</B>,<B> hbt</B>,<B> rcf</B>,<B> scf</B>, <B>tas</B>, and <B>vlm.</B> </P>
<HR>
<H2><A NAME="MultiModuleSystemController">Multi-Module System Controller</A></H2>
<P><B><I>Note </I></B>: The MMSC was at one time called the Full-Featured System Controller, or
FFSC. They are one and the same.</P>
<P>The Multi-Module System Controller provides a way to manage Origin2000 systems
consisting of more than one module, and also provides an enhanced graphical
display of system activity. An MMSC is specified in the standard configuration
for Origin2000 systems consisting of more than one module.</P>
<P>Multi-module systems can be operated without an MMSC. However, certain aspects
of system management are less convenient. Moreover, if no MMSC is provided,
the individual modules in the system must be manually powered on one at
a time, with each switch being powered on less than 15 seconds after the
previous one.</P>
<P>For detailed information about MMSC operations and command set, please refer
to the <A HREF="http://uniscan.engr/~rdb/FFSC/index.html">Multi-Module System Controller</A> document.</P>
<H3><A NAME="FunctionsOfTheMMSC">Functions of the MMSC</A></H3>
<P>The Multi-Module System Controller serves the following purposes:</P>
<UL>
<LI>Simplifies partition management
<LI>Manages a system from a single point of control<BR>
(Important for remote modem control of systems)
<UL>
<LI>Access to individual MSC command features
<LI>Access to individual MSC console I/O features
<LI>Powering up or down all modules in a system
<LI>Resetting all modules or one partition
<LI>Sending an NMI to all modules in a partition
</UL>
<LI>Enhanced graphical display of system activity
<UL>
<LI>High resolution color display
</UL>
<LI>Retrieving information about the system while it is powered down
</UL>
<H3><A NAME="MMSCConnectivity">MMSC Connectivity</A></H3>
<P>A typical multi-module installation consists of:</P>
<UL>
<LI>Modules containing from 1 to 4 Node cards each
<LI>One MSC per module, internally connected to each Node card
<LI>One or two modules per rack
<LI>One MMSC per rack, connected via 9600 baud serial port to both MSCs
<LI>One designated master MMSC with a graphical display and input device
<LI>One 115 kbaud serial port from each MMSC to one module's BaseIO console
port
<LI>An ethernet network connecting all MMSCs together
<LI>An optional IRIS Console workstation (usually large systems only)
</UL>
<CENTER><P ALIGN="CENTER"><IMG SRC="syscon_hier.gif" WIDTH="547" HEIGHT="601" SGI_SETWIDTH SGI_SETHEIGHT SGI_FULLPATH="/tmp_mnt/hosts/ddt/b/csm/ficus/stand/arcs/IP27prom/doc/html/syscon_hier.gif"></P>
</CENTER><CENTER><P ALIGN="CENTER"><B><FONT SIZE="4">Origin2000 Hierarchical System Control</FONT></B></P>
</CENTER><H2><A NAME="IP27prom">IP27prom</A></H2>
<P>There is one IP27prom per node card, connected directly to the Hub chip.
The device is physically an AMDF080 containing 1,048,576 bytes. It is possible
to erase individual sectors consisting of 65,536 bytes, a process which
sets all of the bits in the sector to 1. It is then possible to program
any individual 1 bit into a 0 bit, but not vice versa.</P>
<P>The first 14 sectors of the PROM are used for the IP27prom firmware. The
last 2 sectors are used for the <A HREF="#PROMLogOverview">PROM Log</A> which stores environment variables and log messages.</P>
<CENTER><P ALIGN="CENTER"><IMG SRC="prom_in_system.gif" WIDTH="635" HEIGHT="386" SGI_SETWIDTH SGI_SETHEIGHT SGI_FULLPATH="/tmp_mnt/hosts/ddt/b/csm/ficus/stand/arcs/IP27prom/doc/html/prom_in_system.gif"></P>
</CENTER><CENTER><P ALIGN="CENTER"><FONT SIZE="4">How the IP27prom Fits Into the Origin2000 System</FONT></P>
</CENTER><CENTER><P ALIGN="CENTER"><EM>Picture Courtesy of Steve Whitney</EM></P>
</CENTER><H3><A NAME="PROMCompatibility">PROM Compatibility</A></H3>
<P>It is illegal to run different versions of the IP27prom on different nodes
because the details of the boot sequence vary from release to release. Each
node relies on the implicit actions of other nodes in order to maintain
proper synchronization. The IP27prom cross-checks version numbers with other
IP27proms and displays a <I>promrev mismatch</I> warning if there is an incompatibility.</P>
<P>There are also restrictions on which versions of the IP27prom may run with
which versions of the IO6prom, although they do not necessarily need to
be synchronized on every release. Refer to the individual PROM release nodes
for compabitility information.</P>
<H3><A NAME="SystemBootProcess">System Boot Process</A></H3>
<P>When the system is powered on or reset, the following processes take place.</P>
<OL>
<LI>Initialize CPU
<UL>
<LI>Set up R10000 status registers
<LI>Clear register files
</UL>
<LI>Test CPU caches
<UL>
<LI>Instruction cache
<LI>Data cache
</UL>
<LI>Set up Dex mode
<UL>
<LI>Begin treating the CPU data cache as memory
<LI>Initialize the stack
<LI>Execute the boot procedure (written in C)
</UL>
<LI><A HREF="#EnableAndDisableHardware">Disable CPU A and/or CPU B</A>
<UL>
<LI>The DisableA and DisableB environment variables specify which CPUs to disable.
<LI>In emergencies, disabling can be overridden using <A HREF="#DebugSwitchUse">Virtual Debug Switch</A> 10.
<LI>CPUs are completely separated from the Hub by turning off PI_CPU_ENABLE.
</UL>
<LI>Arbitrate local master (one per node card)
<UL>
<LI>Check for presence of other CPU, if any
<LI>Time out if other CPU does not respond
<LI>Disable other CPU if not responding
</UL>
<LI>Read <A HREF="#DebugSwitchUse">Debug Switch</A> settings from the MSC
<LI>Determine the initial console device, and initialize it
<UL>
<LI>The MSC diagnostics serial port is normally used, but
<LI>if there is a Junk UART plugged in, it takes precedence
<LI>At this point, detailed boot status information can be printed
</UL>
<LI>Record error information that may indicate the cause of a prior crash
<UL>
<LI>Save state of Hub error registers in the cache
<LI>Clear state of Hub error registers
<LI>Enable SYSAD error checking
</UL>
<LI>Initialize I/O
<UL>
<LI>II section of the Hub
<LI>Bridge
<LI>PCI bus
</UL>
<LI>Check if there is a BaseIO card with a console port
<UL>
<LI>If so, switch the console to the BaseIO
</UL>
<LI>Display the PROM boot banner on the console
<UL>
<LI>IP27prom version and size
<LI>Chip revisions
<LI>Slot ID and CPUs present
<LI>Other miscellaneous information
</UL>
<LI>Display which <A HREF="#DebugSwitchUse">Debug Switch</A> settings are set to other than the default
<LI>Determine node's serial number and advertise it to other nodes
<LI>Run Hub Chip Self-Test if Heavy or Manufacturing diagnostics are selected
<UL>
<LI>Runs the BIST (built-in self test) procedure, which automatically reboots
the system
<LI>On reboot, if the test failed, stops with a failure LED value
</UL>
<LI>Configure local memory
<UL>
<LI>Initialize SIMM control registers
<LI>Probe <A HREF="#BankOrganization">amount and type</A> (premium or standard) of memory
<LI>Program Hub memory configuration registers
</UL>
<LI>Perform basic <A HREF="#DebugMemoryTests">memory tests</A>
<UL>
<LI>Make sure address 0 of each bank is accessible
<LI>Disables banks that aren't accessible
<LI>If bank 0 is bad, swaps it with a good bank (see SwapBank environment variable)
</UL>
<LI>Download PROM to memory
<UL>
<LI>Perform memory test on small PROM area of memory
<LI>Download a copy of the PROM
<LI>Verify the download checksum
</UL>
<LI>Transfer program counter to uncached RAM
<UL>
<LI>Runs much, much faster than running out of the PROM
<LI>Still does not require the secondary cache
</UL>
<LI>Switch crucial structures from the cache into uncached memory
<LI>Test and invalidate the secondary cache
<LI>Transfer the stack to uncached RAM
<UL>
<LI>Discard the Dex contents of the data cache
</UL>
<LI>Transfer the program counter and stack to cached RAM
<UL>
<LI>Runs at top speed
</UL>
<LI>Initialize the first 32 MB of bank 0 memory for use by the PROM
<LI>Initialize permanent low-memory system data structures
<UL>
<LI>These structures persist across the IRIX kernel
<LI><B>KLDIR</B> - Indirection table for accessing all other low-memory structures
<LI><B>NMI</B> - Non-maskable Interrupt vector area
<LI><B>KLCONFIG</B> - System topology and configuration information
</UL>
<LI>Run diagnostics on the local CrayLink port
<LI>Discover the <A HREF="#SystemConfigurations">CrayLink Interconnect Topology</A>
<UL>
<LI>Depth-first search using Vector Routing operations
<LI>Builds <B>promcfg</B> data structure in PROM memory
</UL>
<LI>Verify all PROMs are running the same firmware version
<LI>Arbitrate global master
<UL>
<LI>Protocol uses Vector Routing operations
<LI>One global master per partition
</UL>
<LI>Global Master configures CrayLink Interconnect
<UL>
<LI>Determines <A HREF="#NodeIDsNASIDs">Node ID</A> for each node (not yet assigned)
<LI>Programs CrayLink routing tables in all Hubs and Routers
<LI>Tells each Node what their ID will be
</UL>
<LI>All nodes switch back to uncached memory
<UL>
<LI>Required for changing <A HREF="#NodeIDsNASIDs">Node ID</A>
<LI>Flush caches
<LI>Closely synchronize all nodes
<LI>Quiesce bus activity with tight loops internal to R10000
</UL>
<LI>Change <A HREF="#NodeIDsNASIDs">Node ID</A>
<UL>
<LI>Update data structures that were assuming Node ID was zero
<LI>Re-initialize coherence directories for first 32 MB of memory
</UL>
<LI>Switch back to cached memory in new Node ID space
<LI><A HREF="#DebugMemoryTests">Test</A> and initialize all of the rest of local memory (above 32 MB)
<LI>Initialize any headless nodes (nodes without functional CPUs)
<UL>
<LI>Disable CPUs
<LI>Read <A HREF="#NumberInACan">NIC</A>
<LI>Probe, configure, and initialize memory
<LI>Initialize low-memory data structures
<LI>Initialize I/O
</UL>
<LI>Display error state information (if not cold power-on)
<UL>
<LI>Hub error registers, decoded in detail
</UL>
<LI>Transfer control to IO6prom
<UL>
<LI>May be inhibited by <A HREF="#DebugSwitchUse">Debug Switch</A> setting
<LI>Decompress IO6prom image into memory from master BaseIO card
<LI>If no master BaseIO, decompress copy internal to IP27prom
<LI>Jump to entry point of IO6prom
</UL>
</OL>
<P>As it boots, the IO6prom displays several messages about booting and probing
devices, then proceeds to the IO6prom menu:</P>
<PRE>
Numbering nodes...
2 node(s) found.
Clocks synchronized.
Modules numbered.
IO6 PROM Monitor SGI Version 2.1 Rev A IP27, Sep 17, 1996 (BE64)
Sizing caches...
Sizing caches...
Initializing exception vectors.
Initializing environment
Initing environment
Initializing software and devices.
Reiniting caches..
Initing saio...
Installing Devices...
Walking SCSI Adapter 0
1- 2- 3- 4- 5- 6- 7- 8- 9- 10- 11- 12- 13- 14- 15- = 0 device(s)
Walking SCSI Adapter 1
1- 2+ 3- 4- 5- 6- 7- 8- 9- 10- 11- 12- 13- 14- 15- = 1 device(s)
Initializing devices...
System Maintenance Menu
1) Start System
2) Install System Software
3) Run Diagnostics
4) Recover System
5) Enter Command Monitor
Option?
</PRE>
<H3><A NAME="DebugSwitchUse">Using the System Controller Debug Switches</A></H3>
<P>There are two sets of Debug Switches maintained in NVRAM by the MSC:</P>
<UL>
<LI>Eight Physical Debug Switches, numbered 1 through 8
<LI>Eight Virtual Debug Switches, numbered 9 through 16
</UL>
<P>These switches are set by the MSC <B>dbg xx yy</B> command, where <B>xx</B> and <B>yy</B> are hexadecimal bytes. The Virtual Debug Switches are set to <B>xx</B> and the Physical Debug Switches are set to <B>yy</B>. The most significant bit of <B>xx</B> corresponds to Debug Switch 16, while the least significant bit of <B>yy</B> corresponds to Debug Switch 1. Using the <B>dbg</B> command without arguments displays what the current settings are. Ordinarily,
both sets of Debug Switches should be set to zero. An equivalent <B>dbg</B> command is also available in IP27prom POD mode (but be careful because
it takes decimal by default).</P>
<P>There are also eight Hardware Debug Switches that directly correspond to
the Physical Debug Switches. The Hardware Debug Switches are exclusive-ORed
with the Physical Debug Switches so debug functions can be controlled via
both MSC serial port commands and MSC Hardware Debug Switches. The exclusive-OR
allows Hardware Debug Switches that are on to be turned off remotely, and
switches that are off to be turned on. The Origin2000 Hardware Debug Switches
are mounted on a blue block below the MSC keyswitch.</P>
<P>The Origin200 also has Hardware Debug Switches which accessible by removing
a small EMI panel cover on the top of the chassis, and are slightly different
than the Origin2000 switches in appearance (however, they are still <TT>OFF</TT> when switched <I>away</I> from the labelled numbers).</P>
<P>Examples:</P>
<UL>
<LI>To turn off all boot diagnostics: <B>dbg 0 1</B><BR>
If Hardware Debug Switch 1 is already on, this will turn <I>on</I> boot diagnostics.
<LI>To stop at Memoryless POD mode on reset: <B>dbg 0 18</B><BR>
The 4th and 5th bits in the hex value 0x18 are one, so this is the same
as turning on Hardware Debug Switches 4 and 5.
<LI>To override CPU disables: <B>dbg 1 0</B><BR>
This turns on Virtual Debug Switch 9 (not available as a Hardware Debug
Switch).
</UL>
<P><IMG SRC="dip_switch.gif" ALIGN="RIGHT" WIDTH="329" HEIGHT="167" SGI_SETWIDTH SGI_SETHEIGHT SGI_FULLPATH="/tmp_mnt/hosts/ddt/b/csm/ficus/stand/arcs/IP27prom/doc/html/dip_switch.gif">All switches should be <TT>OFF</TT> for normal system operation. Changing Hardware Debug Switch settings requires
using a sharp stylus to press the switch in on the top (switch <TT>ON</TT>) or bottom (switch <TT>OFF</TT>). The Debug Switch block shown here has switches 1, 2, and 6 set to <TT>ON</TT> and all others <TT>OFF</TT>.</P>
<P>When reading the raw binary value of the Hardware Debug Switches using the<B> rsw</B> command, a hexadecimal byte value is returned. The most significant bit
is switch 8, and a bit is 1 when its switch is OFF. The bit values are reversed
(1 when off, 0 when on). Reading the Hardware Debug Switch block shown here
would return 0xdc.<BR CLEAR=ALL>
</P>
<H3><A NAME="DebugSwitchAssignments">System Controller Debug Switch Assignments</A></H3>
<UL>
<LI><TABLE BORDER=1>
<TR><TH><IMG SRC="dipsw1.gif" ALIGN="MIDDLE" WIDTH="30" HEIGHT="30" SGI_FULLPATH="/tmp_mnt/hosts/ddt/b/csm/ficus/stand/arcs/IP27prom/doc/html/dipsw1.gif"></TH><TH><IMG SRC="dipsw2.gif" WIDTH="30" HEIGHT="30" SGI_FULLPATH="/tmp_mnt/hosts/ddt/b/csm/ficus/stand/arcs/IP27prom/doc/html/dipsw2.gif"></TH><TH>Diagnostics Level</TH></TR>
<TR><TD ALIGN=CENTER>Off</TD><TD ALIGN=CENTER>Off</TD><TD ALIGN=CENTER>Normal</TD></TR>
<TR><TD ALIGN=CENTER>Off</TD><TD ALIGN=CENTER>On</TD><TD ALIGN=CENTER>Heavy</TD></TR>
<TR><TD ALIGN=CENTER>On</TD><TD ALIGN=CENTER>Off</TD><TD ALIGN=CENTER>None</TD></TR>
<TR><TD ALIGN=CENTER>On</TD><TD ALIGN=CENTER>On</TD><TD ALIGN=CENTER>Manufacturing</TD></TR>
</TABLE>
<P>These switches select the kind of diagnostics that are run after a system
reset, before booting Irix. The switches apply only to the nodes in the
module on which they're set.</P>
<P><B>Normal</B> tests each part of the system for basic functionality, only using relatively
fast tests to expedite system boot while catching any blatantly troubled
hardware.</P>
<P><B>Heavy</B> runs the most thorough diagnostics available on each part of the system.
They may take a very long time to complete, especially the memory tests.
It may be desirable to run them after installing new hardware or if the
system is having problems thought to be hardware-related.</P>
<P><B>Manufacturing</B> runs heavy diagnostics and outputs special FRU (field replacable unit)
information. Console input and output are handled through the system controller
port which must be connected to Silicon Graphics manufacturing equipment.</P>
<P><B>None</B> performs no diagnostics and the system will boot as fast as possible. This
might be used when debugging software such as kernel drivers, when there
is complete confidence in the hardware.</P>
<LI><TABLE BORDER=1>
<TR><TH><IMG SRC="dipsw3.gif" ALIGN="MIDDLE" WIDTH="30" HEIGHT="30" SGI_SETWIDTH SGI_SETHEIGHT SGI_FULLPATH="/tmp_mnt/hosts/ddt/b/csm/ficus/stand/arcs/IP27prom/doc/html/dipsw3.gif"></TH><TH>Information Level </TH></TR>
</TABLE>
<P>If this switch is On, PROM shows very detailed information messages during
boot, interspersed with the normal boot status messages. The switch applies
only to the nodes in the module on which it's set.</P>
<LI><TABLE BORDER=1>
<TR><TH><IMG SRC="dipsw4.gif" ALIGN="MIDDLE" WIDTH="30" HEIGHT="30" SGI_SETWIDTH SGI_SETHEIGHT SGI_FULLPATH="/tmp_mnt/hosts/ddt/b/csm/ficus/stand/arcs/IP27prom/doc/html/dipsw4.gif"></TH><TH><IMG SRC="dipsw5.gif" WIDTH="30" HEIGHT="30" SGI_SETWIDTH SGI_SETHEIGHT SGI_FULLPATH="/tmp_mnt/hosts/ddt/b/csm/ficus/stand/arcs/IP27prom/doc/html/dipsw5.gif"></TH><TH>Boot Stop Point</TH></TR>
<TR><TD ALIGN=CENTER>Off</TD><TD ALIGN=CENTER>Off</TD><TD ALIGN=CENTER>Never</TD></TR>
<TR><TD ALIGN=CENTER>Off</TD><TD ALIGN=CENTER>On</TD><TD ALIGN=CENTER>Local</TD></TR>
<TR><TD ALIGN=CENTER>On</TD><TD ALIGN=CENTER>Off</TD><TD ALIGN=CENTER>Global</TD></TR>
<TR><TD ALIGN=CENTER>On</TD><TD ALIGN=CENTER>On</TD><TD ALIGN=CENTER>Memoryless</TD></TR>
</TABLE>
<P>These switches allow the boot process to be stopped at various stages.</P>
<P><B>Never</B> allows the boot to proceed all the way through to Irix (default).</P>
<P><B>Local</B> allows the boot to proceed up to the point where it would normally load
and jump to the IO6prom. Instead of continuing, all nodes enter cached (Cac)
POD Mode. If this switch is set on any module, it will be propagated to
all modules.</P>
<P><B>Global</B> allows the boot to proceed up to the point where it would normally load
and jump to the IO6prom. Instead of continuing, the master node enters cached
(Cac) POD Mode and all of the slaves enter the Slave Loop. If this switch
is set on any module, it will be propagated to all modules.</P>
<P><B>Memoryless</B> stops as soon as possible after setting up just the bare minimum portion
of the system required to enter POD mode. All nodes enter dirty exclusive
(Dex) POD Mode even if there is no local memory. <I>Warning</I>: If this switch is set on in one module, the system containing the module
will not boot properly.</P>
<LI><TABLE BORDER=1>
<TR><TH><IMG SRC="dipsw6.gif" ALIGN="MIDDLE" WIDTH="30" HEIGHT="30" SGI_SETWIDTH SGI_SETHEIGHT SGI_FULLPATH="/tmp_mnt/hosts/ddt/b/csm/ficus/stand/arcs/IP27prom/doc/html/dipsw6.gif"></TH><TH>Default Environment</TH></TR>
</TABLE>
<P>If this switch is On, the PROM ignores all PROM Log environment variables
and IO6 NVRAM settings, and uses the system defaults. This may be useful
for proceeding if any of the variable storage mechanisms contain data that
is preventing the system from booting. This switch applies only to the module
on which it is set.</P>
<LI><TABLE BORDER=1>
<TR><TH><IMG SRC="dipsw7.gif" ALIGN="MIDDLE" WIDTH="30" HEIGHT="30" SGI_SETWIDTH SGI_SETHEIGHT SGI_FULLPATH="/tmp_mnt/hosts/ddt/b/csm/ficus/stand/arcs/IP27prom/doc/html/dipsw7.gif"></TH><TH>Bypass IO6</TH></TR>
</TABLE>
<P>If this switch is On, the PROM bypasses the first IO6 card that is found
and tries to boot from the second one found. This may help to boot the system
if the first IO6 card is not working, without having to physically remove
the card. This switch applies only to the module on which it is set.</P>
<LI><TABLE BORDER=1>
<TR><TH><IMG SRC="dipsw8.gif" ALIGN="MIDDLE" WIDTH="30" HEIGHT="30" SGI_SETWIDTH SGI_SETHEIGHT SGI_FULLPATH="/tmp_mnt/hosts/ddt/b/csm/ficus/stand/arcs/IP27prom/doc/html/dipsw8.gif"></TH><TH>Bypass Global Master</TH></TR>
</TABLE>
<P>If this switch is On, the node that would ordinarly become the global master
will become a slave, and the next CPU in line will become the global master.
This switch applies only to the module on which it is set.</P>
<LI><TABLE BORDER=1>
<TR><TH><IMG SRC="dipsw9.gif" ALIGN="MIDDLE" WIDTH="30" HEIGHT="30" SGI_SETWIDTH SGI_SETHEIGHT SGI_FULLPATH="/tmp_mnt/hosts/ddt/b/csm/ficus/stand/arcs/IP27prom/doc/html/dipsw9.gif"></TH><TH>Override CPU Disabling</TH></TR>
</TABLE>
<P>If this switch is On, the all CPUs that would otherwise be disabled due
to the DisableA or DisableB environment variables being set (see POD mode
disable command) will no longer be disabled after a reset.</P>
<P>This is useful for getting out of the situation in which all CPUs in the
system have accidentally been disabled simultaneously.</P>
<LI><TABLE BORDER=1>
<TR><TH><IMG SRC="dipsw10.gif" ALIGN="MIDDLE" WIDTH="48" HEIGHT="30" SGI_SETWIDTH SGI_SETHEIGHT SGI_FULLPATH="/tmp_mnt/hosts/ddt/b/csm/ficus/stand/arcs/IP27prom/doc/html/dipsw10.gif"></TH><TH>Override System Partitioning</TH></TR>
</TABLE>
<P>If this switch is On, the all CPUs that would otherwise be disabled due
to the DisableA or DisableB environment variables being set (see POD mode
disable command) will no longer be disabled after a reset.</P>
<P>This is useful for getting out of the situation in which all CPUs in the
system have accidentally been disabled simultaneously.</P>
<LI><TABLE BORDER=1>
<TR><TH><IMG SRC="dipsw11.gif" ALIGN="MIDDLE" WIDTH="48" HEIGHT="30" SGI_SETWIDTH SGI_SETHEIGHT SGI_FULLPATH="/tmp_mnt/hosts/ddt/b/csm/ficus/stand/arcs/IP27prom/doc/html/dipsw11.gif"></TH><TH>Use Default Console</TH></TR>
</TABLE>
<P>If no user-defined console can be located by means of the ConsolePath environment
variable in the IO6prom, and this switch is turned On, then the first serial
device found in each module will be treated as a console device. The module
containing the Global Master CPU will become the overall system console.</P>
<LI><TABLE BORDER=1>
<TR><TH><IMG SRC="dipsw12.gif" ALIGN="MIDDLE" WIDTH="48" HEIGHT="30" SGI_SETWIDTH SGI_SETHEIGHT SGI_FULLPATH="/tmp_mnt/hosts/ddt/b/csm/ficus/stand/arcs/IP27prom/doc/html/dipsw12.gif"></TH><TH> through </TH><TH><IMG SRC="dipsw16.gif" ALIGN="MIDDLE" WIDTH="48" HEIGHT="30" SGI_SETWIDTH SGI_SETHEIGHT SGI_FULLPATH="/tmp_mnt/hosts/ddt/b/csm/ficus/stand/arcs/IP27prom/doc/html/dipsw16.gif"></TH><TH>Not yet assigned</TH></TR>
</TABLE>
<P>These switches are reserved for future use.</P>
</UL>
<H3><A NAME="PROMImages">PROM Images</A></H3>
<P><I>Of interest to developers only</I></P>
<P>The IP27prom build directory and the Irix flash commands deal with PROM
images in the <B>promgen</B> format. The file extension for such images is <I>.img</I>. Under Irix, they reside in the directory <I>/usr/cpu/firmware</I>.</P>
<P>To verify an image and view the version number of an image, use the command <B>promgen -h file.img</B>. The promgen utility resides in <I>stand/arcs/tools/promgen</I>.</P>
<HR>
<H2><A NAME="PowerOnDiags">Power-On Diagnostics</A></H2>
<H3><A NAME="BootStatusLEDs">Boot Status LEDs</A></H3>
<P>During system boot, the node board LEDs are constantly updated with values
indicating the boot progress, so that if the system were to crash during
any phase, the LEDs would indicate what it was doing at the time. Also,
diagnostics values are displayed on the Origin2000/200 Module System Controller
display during boot. Further into the boot process, a console becomes available
to report more detailed information on failures.</P>
<P>If a single processor fails very early during boot, before a console is
available, the PROM will present a non-flashing FLED (failure LED) value
and completely disable that processor by setting its PI_CPU_ENABLE bit to
zero. The system will continue to boot without that processor.</P>
<P>If a single process fails after a console is available, the PROM will flash
a FLED value, and wait for ^C to be entered on the console, whereupon it
will enter Dex POD mode. The system will continue to boot without that processor.</P>
<H3><A NAME="ReadingTheLEDs">Reading the LEDs</A></H3>
<P><IMG SRC="cpu_leds.gif" ALIGN="RIGHT" WIDTH="53" HEIGHT="184" SGI_FULLPATH="/tmp_mnt/hosts/ddt/b/csm/ficus/stand/arcs/IP27prom/doc/html/cpu_leds.gif"><BR>
Each node card has two side-by-side columns of 8 discreet LEDs. The left
column presents a status value from CPU (slice) A, and the right column
presents a status value from CPU B.</P>
<P>The columns have the most significant bit on top. The sense of the LED bits
is reversed such that a lit LED indicates a zero bit and an extinguished
LED indicates a one bit. For example, in the figure at right, CPU A is showing
0xf8, while CPU B is showing 0x03.<BR CLEAR=ALL>
</P>
<P>During the boot process, the CPU changes the LEDs before each phase of initialization.
If a CPU were to hang during any phase, the residual LED value would help
to indicate which phase hung and perhaps pinpoint the failing component
(for example, the R10000 data cache). LED values from 0x00 to 0x7f, as shown
in Table 1, are used for this purpose.</P>
<CENTER><P ALIGN="CENTER"><TABLE BORDER=1>
<CAPTION> Progress LED Values </CAPTION>
<TR><TH ALIGN=LEFT> LED </TH><TH ALIGN=LEFT> Name </TH><TH ALIGN=LEFT> Phase </TH></TR>
<TR><TD>0x00</TD><TD>RESET</TD><TD>-</TD><TR><TD>0x01</TD><TD>INITCPU</TD><TD>Initializing R10000 GPRS, FPRS, and COP0</TD><TR><TD>0x02</TD><TD>TESTCP1</TD><TD>Testing R10000 COP1 registers</TD><TR><TD>0x03</TD><TD>RUNTLB</TD><TD>Switch to mapped mode</TD><TR><TD>0x04</TD><TD>TESTICACHE</TD><TD>Test R10000 primary instruction cache</TD><TR><TD>0x05</TD><TD>TESTDCACHE</TD><TD>Test R10000 primary data cache</TD><TR><TD>0x06</TD><TD>TESTSCACHE</TD><TD>Test secondary cache</TD><TR><TD>0x07</TD><TD>FLUSHCACHES</TD><TD>Flush all caches</TD><TR><TD>0x08</TD><TD>CKHUBLOCAL</TD><TD>-</TD><TR><TD>0x09</TD><TD>CKHUBCONFIG</TD><TD>-</TD><TR><TD>0x0a</TD><TD>INVICACHE</TD><TD>Invalidate R10000 primary instruction cache</TD><TR><TD>0x0b</TD><TD>INVDCACHE</TD><TD>Invalidate R10000 primary data cache</TD><TR><TD>0x0c</TD><TD>INVSCACHE</TD><TD>Invalidate secondary cache</TD><TR><TD>0x0d</TD><TD>INMAIN</TD><TD>Succeeded in jumping to main()</TD><TR><TD>0x0e</TD><TD>SPEEDUP</TD><TD>About to increase PROM access speed</TD><TR><TD>0x0f</TD><TD>SPEEDUPOK</TD><TD>Increased PROM access speed</TD><TR><TD>0x10</TD><TD>INITDCACHE</TD><TD>-</TD><TR><TD>0x11</TD><TD>INITICACHE</TD><TD>-</TD><TR><TD>0x12</TD><TD>INITCOP0</TD><TD>-</TD><TR><TD>0x13</TD><TD>FLUSHTLB</TD><TD>-</TD><TR><TD>0x14</TD><TD>CLEARTAGS</TD><TD>-</TD><TR><TD>0x15</TD><TD>CCLFAILED_INITUART</TD><TD>-</TD><TR><TD>0x16</TD><TD>HUBINIT</TD><TD>-</TD><TR><TD>0x17</TD><TD>HUBCFAILED_INITUART</TD><TD>-</TD><TR><TD>0x18</TD><TD>NOCLOCK_INITUART</TD><TD>-</TD><TR><TD>0x19</TD><TD>HUBINITDONE</TD><TD>-</TD><TR><TD>0x1a</TD><TD>MSCPROBE</TD><TD>About to probe for presence of MSC</TD><TR><TD>0x1b</TD><TD>JUNKPROBE</TD><TD>About to probe for presence of Junk UART</TD><TR><TD>0x1c</TD><TD>DONEPROBE</TD><TD>Done probing for presence of MSC</TD><TR><TD>0x1d</TD><TD>UARTINIT</TD><TD>About to initialize selected UART</TD><TR><TD>0x1e</TD><TD>UARTINITDONE</TD><TD>Done initializing selected UART</TD><TR><TD>0x1f</TD><TD>CKHUBCHIP</TD><TD>-</TD><TR><TD>0x20</TD><TD>PODMAIN</TD><TD>-</TD><TR><TD>0x21</TD><TD>PODLOOP</TD><TD>About to enter POD mode, C portion</TD><TR><TD>0x22</TD><TD>PODPROMPT</TD><TD>Just about to enter POD prompt loop</TD><TR><TD>0x23</TD><TD>PODMODE</TD><TD>About to enter POD mode, assembler portion</TD><TR><TD>0x24</TD><TD>LOCALARB</TD><TD>Performing local arbitration (CPU A/B)</TD><TR><TD>0x25</TD><TD>SCINIT</TD><TD>-</TD><TR><TD>0x26</TD><TD>BMARB</TD><TD>-</TD><TR><TD>0x27</TD><TD>BMASTER</TD><TD>-</TD><TR><TD>0x28</TD><TD>BARRIER</TD><TD>About to perform first local barrier</TD><TR><TD>0x29</TD><TD>CKPDCACHE1</TD><TD>-</TD><TR><TD>0x2a</TD><TD>MAKESTACK</TD><TD>About to configure Dex mode stack and data</TD><TR><TD>0x2b</TD><TD>MAIN</TD><TD>Reached main()</TD><TR><TD>0x2c</TD><TD>LOADPROM</TD><TD>-</TD><TR><TD>0x2d</TD><TD>CKSCACHE1</TD><TD>-</TD><TR><TD>0x2e</TD><TD>CKBT</TD><TD>-</TD><TR><TD>0x2f</TD><TD>INSLAVE</TD><TD>-</TD><TR><TD>0x30</TD><TD>PROMJUMP</TD><TD>-</TD><TR><TD>0x31</TD><TD>NMI</TD><TD>-</TD><TR><TD>0x32</TD><TD>INV_IDCACHES</TD><TD>-</TD><TR><TD>0x33</TD><TD>INV_SCACHE</TD><TD>-</TD><TR><TD>0x34</TD><TD>WRCONFIG</TD><TD>-</TD><TR><TD>0x35</TD><TD>RTCINIT</TD><TD>About to initialize Hub Real Time Counter</TD><TR><TD>0x36</TD><TD>RTCINITDONE</TD><TD>Done initializing Hub Real Time Counter</TD><TR><TD>0x37</TD><TD>LOCK</TD><TD>-</TD><TR><TD>0x38</TD><TD>BARRIEROK</TD><TD>First local barrier succeeded</TD><TR><TD>0x39</TD><TD>LOCKOK</TD><TD>-</TD><TR><TD>0x3a</TD><TD>FPROMINIT</TD><TD>-</TD><TR><TD>0x3b</TD><TD>FPROMINITDONE</TD><TD>-</TD><TR><TD>0x3c</TD><TD>JUMPRAMU</TD><TD>About to jump to UALIAS space</TD><TR><TD>0x3d</TD><TD>JUMPRAMUOK</TD><TD>Jumped to UALIAS space</TD><TR><TD>0x3e</TD><TD>JUMPRAMC</TD><TD>About to jump to cached space</TD><TR><TD>0x3f</TD><TD>JUMPRAMCOK</TD><TD>Jumped to cached space</TD><TR><TD>0x40</TD><TD>STACKRAM</TD><TD>About to test stack area of memory</TD><TR><TD>0x41</TD><TD>STACKRAMOK</TD><TD>Done testing stack area of memory</TD><TR><TD>0x42</TD><TD>SLAVEINT</TD><TD>Slave saw command request interrupt</TD><TR><TD>0x43</TD><TD>SLAVECALL</TD><TD>Slave about to call requested command</TD><TR><TD>0x44</TD><TD>SLAVEREND</TD><TD>Slave command completed</TD><TR><TD>0x45</TD><TD>LAUNCHLOOP</TD><TD>About to enter slave launch loop</TD><TR><TD>0x46</TD><TD>LAUNCHINTR</TD><TD>Received launch interrupt</TD><TR><TD>0x47</TD><TD>LAUNCHCALL</TD><TD>Calling launched function</TD><TR><TD>0x48</TD><TD>LAUNCHDONE</TD><TD>Launched function returned</TD><TR><TD>0x49</TD><TD>UARTBASE</TD><TD>-</TD><TR><TD>0x4a</TD><TD>MDIRINIT</TD><TD>About to initialize Hub MD and SIMM controls</TD><TR><TD>0x4b</TD><TD>MDIRCONFIG</TD><TD>About to probe and configure memory size</TD><TR><TD>0x4c</TD><TD>I2CINIT</TD><TD>About to initialize PCF8584 I2C chip</TD><TR><TD>0x4d</TD><TD>I2CDONE</TD><TD>Done initializing PCF8584 I2C chip</TD><TR><TD>0x4e</TD><TD>CONFIG_INIT</TD><TD>-</TD><TR><TD>0x4f</TD><TD>IODISCOVER</TD><TD>About to discover Hub I/O</TD><TR><TD>0x50</TD><TD>HUB_CONFIG</TD><TD>-</TD><TR><TD>0x51</TD><TD>ROUTER_CONFIG</TD><TD>About to write Router cfg info into KLCONFIG</TD><TR><TD>0x52</TD><TD>INITII</TD><TD>About to initialize I/O section of Hub</TD><TR><TD>0x53</TD><TD>CONSOLE_GET</TD><TD>About to probe I/O section for console</TD><TR><TD>0x54</TD><TD>CONSOLE_GET_OK</TD><TD>Console probing completed</TD><TR><TD>0x55</TD><TD>NOT_USED_55</TD><TD>-</TD><TR><TD>0x56</TD><TD>INITIODONE</TD><TD>Done initializing I/O section of Hub</TD><TR><TD>0x57</TD><TD>STASH2</TD><TD>Reset error state saved</TD><TR><TD>0x58</TD><TD>STASH3</TD><TD>Hub error registers cleared</TD><TR><TD>0x59</TD><TD>STASH4</TD><TD>Hub error checking enabled</TD><TR><TD>0x5a</TD><TD>IODISCOVER_DONE</TD><TD>Done discovering Hub I/O</TD><TR><TD>0x5b</TD><TD>NMI_INIT</TD><TD>About to initialize NMI handler area</TD><TR><TR><TD>0x5c</TD><TD>TEST_INTS</TD><TD>About to test Hub interrupts</TD><TR><TD>0x5d</TD><TD>IORESET</TD><TD>About to perform early reset of Hub I/O section</TD><TR></TABLE></P>
</CENTER><P>In addition to indicating boot progress, the LEDs are used to indicate fatal
hardware problems found during diagnostics the PROM performs in each <A HREF="#SystemBootProcess">boot phase</A>. If a fatal problem is found, the CPU sets the LEDs to a failure value
between 0x80 and 0xff, as shown in Table 2, and automatically disables itself. </P>
<CENTER><P ALIGN="CENTER"><TABLE BORDER=1>
<CAPTION> Failure LED Values </CAPTION>
<TR><TH ALIGN=LEFT> LED </TH><TH ALIGN=LEFT> Name </TH><TH ALIGN=LEFT> Reason </TH></TR>
<TR><TD>0x81</TD><TD>CP1</TD><TD>R10000 COP1 register test failed</TD><TR><TD>0x82</TD><TD>RESTART</TD><TD>Restart Master unable to load io6prom</TD><TR><TD>0x83</TD><TD>ICACHE</TD><TD>R10000 primary instruction cache test failed</TD><TR><TD>0x84</TD><TD>DCACHE</TD><TD>R10000 primary data cache test failed</TD><TR><TD>0x85</TD><TD>SCACHE</TD><TD>Secondary cache test failed</TD><TR><TD>0x86</TD><TD>KILLED</TD><TD>CPU disabled by another node</TD><TR><TD>0x87</TD><TD>RTC</TD><TD>Real-time counter not counting</TD><TR><TD>0x88</TD><TD>ECC</TD><TD>-</TD><TR><TD>0x89</TD><TD>XTLBMISS</TD><TD>-</TD><TR><TD>0x8a</TD><TD>UTLBMISS</TD><TD>-</TD><TR><TD>0x8b</TD><TD>KTLBMISS</TD><TD>-</TD><TR><TD>0x8c</TD><TD>GENERAL</TD><TD>-</TD><TR><TD>0x8d</TD><TD>NOTIMPL</TD><TD>-</TD><TR><TD>0x8e</TD><TD>CACHE</TD><TD>-</TD><TR><TD>0x8f</TD><TD>OS</TD><TD>-</TD><TR><TD>0x90</TD><TD>HUBINTS</TD><TD>-</TD><TR><TD>0x91</TD><TD>HUBLOCAL</TD><TD>-</TD><TR><TD>0x92</TD><TD>HUBCONFIG</TD><TD>-</TD><TR><TD>0x93</TD><TD>PREM_DIR_REQ</TD><TD>All nodes must have premium DIMMs for this configuration</TD><TR><TD>0x94</TD><TD>UNUSED1</TD><TD>-</TD><TR><TD>0x95</TD><TD>HUBUART</TD><TD>-</TD><TR><TD>0x96</TD><TD>HUBCCS</TD><TD>-</TD><TR><TD>0x97</TD><TD>MAINRET</TD><TD>main() returned</TD><TR><TD>0x98</TD><TD>NOMEM</TD><TD>Node card has no local memory</TD><TR><TD>0x99</TD><TD>I2CFATAL</TD><TD>-</TD><TR><TD>0x9a</TD><TD>DISABLED</TD><TD>CPU is disabled by environment variable</TD><TR><TD>0x9b</TD><TD>DOWNLOAD</TD><TD>Error downloading IO6prom into RAM</TD><TR><TD>0x9c</TD><TD>COREDEBUG</TD><TD>Can't set CORE debug registers</TD><TR><TD>0x9d</TD><TD>IODISCOVER</TD><TD>Hub I/O discovery failed</TD><TR><TD>0x9e</TD><TD>HUB_CONFIG</TD><TD>Failed writing Hub info into KLCONFIG</TD><TR><TD>0x9f</TD><TD>ROUTER_CONFIG</TD><TD>Failed writing Router info into KLCONFIG</TD><TR><TD>0xa0</TD><TD>HUBIO_INIT</TD><TD>Hub I/O initialization failed</TD><TR><TD>0xa1</TD><TD>CONFIG_INIT</TD><TD>Failed initializing KLCONFIG</TD><TR><TD>0xa2</TD><TD>RTRCHIP</TD><TD>Router chip failed diags</TD><TR><TR><TD>0xa3</TD><TD>LINKDEAD</TD><TD>LLP link failed diags</TD><TR><TR><TD>0xa4</TD><TD>HUBBIST</TD><TD>Hub chip failed built-in self test (BIST)</TD><TR><TR><TD>0xa5</TD><TD>RTRBIST</TD><TD>Router chip failed built-in self test (BIST)</TD><TR><TR><TD>0xa6</TD><TD>RESETWAIT</TD><TD>Waiting for reset to go</TD><TR><TR><TD>0xa7</TD><TD>LLP_FAIL</TD><TD>LLP failed after reset</TD><TR><TR><TD>0xa8</TD><TD>LLP_NORESET</TD><TD>LLP never came up after reset</TD><TR><TR><TD>0xa9</TD><TD>BADMEM</TD><TD>No good local memory</TD><TR><TR><TD>0xaa</TD><TD>NOT_USED_AA</TD><TD>-</TD><TR><TR><TD>0xab</TD><TD>NET_DISCOVER</TD><TD>Hub Network discovery failed</TD><TR><TR><TD>0xac</TD><TD>NASID_CALC</TD><TD>NASID calculation failed</TD><TR><TR><TD>0xad</TD><TD>ROUTE_CALC</TD><TD>Route calculation failed</TD><TR><TR><TD>0xae</TD><TD>ROUTE_DIST</TD><TD>Route distribution failed</TD><TR><TR><TD>0xaf</TD><TD>NASID_DIST</TD><TD>NASID distribution failed</TD><TR><TR><TD>0xb0</TD><TD>NO_NASID</TD><TD>Master did not assign a NASID</TD><TR><TR><TD>0xb1</TD><TD>NO_MODULEID</TD><TD>Module ID arbitration failed</TD><TR><TR><TD>0xb2</TD><TD>MIXED_SN00</TD><TD>Origin200 mixed with Origin2000</TD><TR><TR><TD>0xb3</TD><TD>ERRPART</TD><TD>Error partition config</TD><TR><TR><TD>0xb3</TD><TD>MODEBIT</TD><TD>Error copying modebits</TD><TR></TABLE></P>
</CENTER><P>The following codes blink and indicate that an exception occurred so early
in the PROM that no TTY device was available print information about the
exception:</P>
<CENTER><P ALIGN="CENTER"><TABLE BORDER=1>
<CAPTION> Early Exception LED Values </CAPTION>
<TR><TH ALIGN=LEFT> LED </TH><TH ALIGN=LEFT> Name </TH><TH ALIGN=LEFT> Exception Type </TH></TR>
<TR><TD>0xf2</TD><TD>EXC_GENERAL</TD><TD>(Blinking) General exception</TD><TR><TD>0xf3</TD><TD>EXC_ECC</TD><TD>(Blinking) ECC exception</TD><TR><TD>0xf4</TD><TD>EXC_TLB</TD><TD>(Blinking) TLB exception</TD><TR><TD>0xf5</TD><TD>EXC_XTLB</TD><TD>(Blinking) XTLB exception</TD><TR><TD>0xf6</TD><TD>EXC_UNIMPL</TD><TD>(Blinking) Unimplemented exception</TD><TR><TD>0xf7</TD><TD>EXC_CACHE</TD><TD>(Blinking) Cache Error exception</TD></TABLE></P>
</CENTER><H3><A NAME="PODMode">POD Mode (PROM Command Interpreter)</A></H3>
<P>POD mode is a command interpreter present in the PROM which is most often
used for debugging of a crashed system. It can be used to examine the contents
of CPU registers, support chip registers, and memory. It can also enable
or disable certain node card features, such as CPUs and memory banks.</P>
<P>POD can be run in three modes: Dex, Cac, and Unc.</P>
<P>When running in Dex mode, POD requires very few system resources to run.
It does not require memory -- instead, it accesses its program text directly
from the PROM and uses the R10000 microprocessor's data cache as memory
for its stack. The secondary cache is not used. <A HREF="#DebugNMI">NMI</A> and uncaught exceptions typically result in a Dex mode POD prompt.</P>
<P><IMG SRC="snail.gif" ALIGN="RIGHT" WIDTH="48" HEIGHT="48" SGI_FULLPATH="/tmp_mnt/hosts/ddt/b/csm/ficus/stand/arcs/IP27prom/doc/html/snail.gif">Dex mode is generally very slow because PROM instruction fetches are very
slow. You would want to avoid performing long memory tests or flashing remote
PROMs from Dex mode. Certain commands may not be executed in Dex mode, especially
ones that attempt to program the PROM. See the <B>go cac</B> command for getting out of Dex mode.<BR CLEAR=RIGHT>
</P>
<P><IMG SRC="abomb.gif" ALIGN="RIGHT" WIDTH="48" HEIGHT="48" SGI_SETWIDTH SGI_SETHEIGHT SGI_FULLPATH="/tmp_mnt/hosts/ddt/b/csm/ficus/stand/arcs/IP27prom/doc/html/abomb.gif"> Also, when loading or storing data or running memory tests, <EM>be sure not to access cached memory addresses while running in Dex mode</EM>. See the <B><A HREF="#GoCommand">go dex</B> command</A>.<BR CLEAR=RIGHT>
</P>
<P>When running in Cac mode, POD places its program text, data, and stack in
cached memory. This may only occur after memory has been probed and configured.
POD runs very quickly out of cached memory. When the PROM takes an exception
or NMI and enters POD mode, it goes into Dex mode. In the right circumstances
it is possible to get back to Cac mode using the <B><A HREF="#GoCommand">go cac</B></A> command.</P>
<P>When running in Unc mode, POD places its program text, data, and stack in
uncached memory. This is similar to Cac mode, except the cache is not used
and it runs slower.</P>
<P>The PROM can be forced to enter POD mode at different stages of the boot
process by setting Debug Switches.</P>
<P>The POD mode prompt is in the format:</P>
<PRE>
<FONT SIZE="6"> POD Dex MSC 001 3A&gt;</FONT>
<FONT SIZE="6"> ___ ___ ___ ___ _ __</FONT>
<FONT SIZE="6"> 1 2 3 4 5 6</FONT>
</PRE>
<P>where the fields are:</P>
<OL>
<LI>Always POD, indicating POD mode.
<LI><I>Dex</I>, indicating POD mode is running memoryless out of the cache only, or<BR>
<I>Cac</I>, indicating POD mode is running out of cached memory, or<BR>
<I>Unc</I>, indicating POD mode is running out of uncached memory.
<LI><I>MSC</I>, indicating the POD prompt is being displayed on the MSC ACP port, or<BR>
<I>Junk</I>, indicating the POD prompt is being displayed on the Junk UART, or<BR>
<I>IOC3</I>, indicating the POD prompt is being displayed on an IOC3 UART, or<BR>
<I>Talk</I>, indicating the POD prompt is being displayed on the Net UART.
<LI>The NASID (node ID) of the current node.
<LI>Occasionally, status fields may be inserted here indicating errors or alternate
operating modes. <I>MDerr</I> indicates MD errors are pending (use the <B>error</B> command to view them and <B>clear</B> to clear them). <I>AltRegs</I> indicates the kernel register set is in effect rather than the PROM register
set.
<LI>The slot (1 to 4) and slice (A or B) of the CPU displaying the prompt.
<LI>Many POD mode commands, including memory tests, flashing PROMs, and <B>loop</B> or <B>repeat </B>statements can be aborted by typing ^C.
</OL>
<P>The following editing characters are provided at the POD prompt:</P>
<PRE>
^C Abort
^H, Backspace, or DEL Backspace
^R Redisplay line
^U Erase line
</PRE>
<P>Three handy command line editing features are borrowed from the C shell:</P>
<OL>
<LI>Wherever the symbol <B>!!</B> appears in a command line, it is substituted with the contents of the previous
command line.
<LI>Wherever the symbol <B>!$</B> appears in a command line, it is substituted with the last word from the
previous command line.
<LI>The command line <B>^<I>xxx</I>^<I>yyy</I></B> repeats the previous command line, except substitutes the first occurrence
of the string <I>xxx</I> with the string <I>yyy</I>.
</OL>
<P>In addition, environment variables (see <B><A HREF="#EnvironmentCommands">setenv</B> command</A>) are substituted wherever the name of an environment variable appears in
backquotes (``). This is useful as a form of aliases. For example,</P>
<PRE>
POD Dex Hub 000 1A&gt; setenv range
Set &quot;range&quot; to? n:1 u: 0x3ff0000 2m
POD Dex Hub 000 1A&gt; dirtest `range`
POD Dex Hub 000 1A&gt; dirinit `range`
POD Dex Hub 000 1A&gt; memtest `range`
</PRE>
<H3><A NAME="PODConsoles">POD Consoles</A></H3>
<P>POD mode will present a prompt on several possible I/O devices. It probes
for devices in the order listed below and uses the first one found. When
the CPU is at the POD prompt, it will blink an LED pattern at 0.5 Hz indicating
on which UART input is expected.</P>
<PRE>
junk If a Junk UART is plugged in, it is used preferentially.
Junk UARTs are available only in manufacturing and bring-up.
LED pattern: 0x80/0xb3
ioc3 If a BaseIO (IO6) is found, and one of the ports on it is
marked as the system console, and it can be initialized and
accessed without causing an exception, the ioc3 uart is used.
LED pattern: 0x80/0x8c
msc If the Module System Controller is responsive, the MSC
is used for I/O. (The MSC was at one time called the
Entry Level System Controller, or ELSC).
LED pattern: 0x80/0xbc
netuart If no UART is available, the netuart is used (see below).
This is not a real UART, but an emulation that allows one
Hub to talk to another.
LED pattern: 0x80/0xbf
</PRE>
<H4><A NAME="Netuart">Netuart</A></H4>
<P>When a CPU is using the netuart, it monitors some shared memory locations
and interrupt lines used for communication. From any node that has a UART
and is at the POD prompt, you can use the <B><A HREF="#TalkCommand">talk</B></A> command to communicate with CPUs that are using the netuart. Use of the
netuart is not recommended.</P>
<H3><A NAME="PODConstants">Constants</A></H3>
<P>PROM constants are similar to C constants. Hexadecimal numbers are prefixed
with <B>0x</B>; octal numbers are prefixed with <B>0</B>; binary numbers are prefixed with <B>0b</B>; all other numbers are in decimal.</P>
<P>Three special suffixes are provided to facilitate entering large constants:</P>
<PRE>
g Gigabytes e.g.: 1g == (1 &lt;&lt; 30)
m Megabytes e.g.: 32m == (32 &lt;&lt; 20)
k Kilobytes e.g.: 100k == (100 &lt;&lt; 10)
</PRE>
<H3><A NAME="PODExpressions">Expressions</A></H3>
<P>Arithmetic expressions are permitted and are similar to C expressions in
operators and order of evaluation. Many commands require expressions to
be parenthesized to avoid ambiguity. For example:</P>
<PRE>
px (0xdeadbeef &gt;&gt; 6) &amp; 0xff
sd md_memory_config (ld md_memory_config | 077777777)
</PRE>
<P>The supported operators are:</P>
<PRE>
Unary: () ~ ! - + LD LW LH LB, and * (same as LD)
Binary: + - * / % | &amp; ^ &lt;&lt; &gt;&gt; == != &lt; &gt; &lt;= &gt;= &amp;&amp; ||
</PRE>
<P>Commands that require strings may sometimes require quotes on the strings.
Within quotes, standard C escape sequences (\b, \t, \n, \r, \\, and \ddd)
are permitted. There is a 31-character limit on string length.</P>
<H3><A NAME="PODStatements">Statements</A></H3>
<P>More than one command may be performed on a command line by using a command
list in which commands are separated by semicolons; e.g.:</P>
<PRE>
sd u:0 1; ld u:0
</PRE>
<P>Commands that take other commands as aguments, such as <B>loop</B>, may take a single command or a compound command consisting of a command
list in curly braces; e.g.:</P>
<PRE>
loop ld pi_rt_count
loop { ld pi_rt_count; sd pi_rt_count 0 }
</PRE>
<P>A pound sign (#) begins a comment that lasts to the end of the input line.
This may be useful when cutting and pasting into a terminal window from
command files.</P>
<H3><A NAME="PODAddressModifiers">Address Modifiers</A></H3>
<P>For convenience in entering constants which represent R10000 and Origin2000
addresses, a number of modifiers are available. The modifiers should precede
the constants. Multiple modifiers may be used.</P>
<CENTER><P ALIGN="CENTER"><TABLE BORDER=1>
<CAPTION>Address Modifiers</CAPTION>
<TR><TH>Modifier</TH><TH>Action</TH><TH>Example</TH><TH>Equivalent To</TH></TR>
<TR><TD>h:</TD><TD>Set top byte to 0x90 (HSPEC).</TD><TD>h:256m</TD><TD>0x9000000010000000 (LBOOT)</TD></TR>
<TR><TD>i:</TD><TD>Set top byte to 0x92 (IO).</TD><TD>i:(16m+32)</TD><TD>0x9200000001000020</TD></TR>
<TR><TD>m:</TD><TD>Set top byte to 0x94 (MSPEC).</TD><TD>m:0</TD><TD>0x9400000000000000</TD></TR>
<TR><TD>u:</TD><TD>Set top byte to 0x96 (UNCAC).</TD><TD>u:0</TD><TD>0x9600000000000000</TD></TR>
<TR><TD>c:</TD><TD>Set top byte to 0xa8 (CAC).</TD><TD>c:0</TD><TD>0xa800000000000000</TD></TR>
<TR><TD>p:</TD><TD>Set top byte to 0x00 (PHYS).</TD><TD>p:c:0x100</TD><TD>0x100</TD></TR>
<TR><TD>s:</TD><TD>Sign extend word.</TD><TD>s:0xbfc00000</TD><TD>0xffffffffbfc00000</TD></TR>
<TR><TD>n:#</TD><TD>Add NASID, where # is NASID.<BR>
May only be used if CrayLink routing is configured.</TD><TD>n:2 c:1</TD><TD>0xa800000200000001</TD></TR>
<TR><TD>w:#</TD><TD>Set top byte to 0x92. Sets bit 24. Adds Widget, where # is widget. If remote,
adds bit 23.</TD><TD>w:1 0x200<BR>
n:1 w:1 0x200</TD><TD>0x9200000001000200<BR>
0x9200000101800200</TD> </TR>
<TR><TD>b:#</TD><TD>Adds offset for memory bank (# times 512 MB).</TD><TD>n:3 b:5 u:2k</TD><TD>0x96000003a0000800</TD></TR>
<TR><TD>L:</TD><TD>Converts address to corresponding directory entry LO in HSPEC.</TD><TD>L:0x2100560</TD><TD>0x90000000c08402a0</TD></TR>
<TR><TD>H:</TD><TD>Converts address to corresponding directory entry HI in HSPEC.</TD><TD>H:u:0x2100560</TD><TD>0x90000000c08402a8</TD></TR>
<TR><TD>P:#</TD><TD>Converts address to corresponding protection entry, where # is the region.</TD><TD>P:5 0x2100560</TD><TD>0x90000000c0840028</TD></TR>
<TR><TD>E:</TD><TD>Converts address to corresponding ECC word address.</TD><TD>E:0x2100560</TD><TD>0x9000000080840158</TD></TR>
</TABLE> </P>
</CENTER><H3><A NAME="PODHardwareRegisters">Hardware Registers</A></H3>
<P>The PROM knows the names and bit field assignments for approximately 500
hardware registers in the CPU, Hub, Router, and Crossbow, so you do not
need to manually look up and type their addresses (or values in the case
of CPU registers). Names of registers may appear in arithmetic expressions
and are replaced with the registers' addresses.</P>
<P>The names of R10000 Cop0 registers are recognized, and include Cause, Status,
etc. The names of the R10000 general purpose registers are recognized (v0,
a1, ta0, gp, r5, etc). General purpose registers may also be referred to
as $0, $1, $2, etc. Floating point registers may be referenced as $f0, $f1,
$f2, etc.</P>
<P>The names of Hub registers are prefixed according to the five sections of
the Hub with <I>PI_</I>, <I>MD_</I>, <I>II_</I>, <I>NI_</I>, and <I>CORE_</I>.</P>
<P>The names of Hub NI and Router registers can be used in place of the vector
address in some vector commands. Router registers are prefixed with <I>RR_</I>. The names of the Crossbow (XBOW) registers are prefixed with <I>XB_</I>.</P>
<P>Register names are case-insensitive and may be truncated to the extent that
they are unambiguous. For example:</P>
<PRE>
POD Dex IOC3 000 4A&gt; px (md_refresh_control + 8)
0x9200000001200028
POD Dex IOC3 000 4A&gt; pr n:1 md_ref
Register: MD_REFRESH_CONTROL (0x9200000101a00020)
Value : 0x0000000000000000 (loaded from remote register)
&lt;63&gt; RW ENABLE 0x1
&lt;23:12&gt; RW COUNTER 0x2e0
&lt;11:00&gt; RW CNT_THRESH 0x504
</PRE>
<H4><A NAME="HubPIRegs">Hub PI (Processor Interface) Registers</A></H4>
<P><TT><FONT SIZE="2">PI_BIST_COUNT_TARGET PI_BIST_ENTER_RUN PI_BIST_RDY PI_BIST_READ_DATA PI_BIST_SHIFT_LOAD
PI_BIST_SHIFT_UNLOAD PI_BIST_WRITE_DATA PI_CALIAS_SIZE PI_CC_MASK PI_CC_PEND_CLR_A
PI_CC_PEND_CLR_B PI_CC_PEND_SET_A PI_CC_PEND_SET_B PI_CPU_ENABLE_A PI_CPU_ENABLE_B
PI_CPU_NUM PI_CPU_PRESENT_A PI_CPU_PRESENT_B PI_CPU_PROTECT PI_CRB_SFACTOR
PI_CRB_TIMEOUT_A PI_CRB_TIMEOUT_B PI_ERR_INT_MASK_A PI_ERR_INT_MASK_B PI_ERR_INT_PEND
PI_ERR_STACK_ADDR_A PI_ERR_STACK_ADDR_B PI_ERR_STACK_FORMAT PI_ERR_STACK_SIZE
PI_ERR_STATUS0_A PI_ERR_STATUS0_A_CLEAR PI_ERR_STATUS0_B PI_ERR_STATUS0_B_CLEAR
PI_ERR_STATUS1_A PI_ERR_STATUS1_A_CLEAR PI_ERR_STATUS1_B PI_ERR_STATUS1_B_CLEAR
PI_FORCE_BAD_CHECK_BIT_A PI_FORCE_BAD_CHECK_BIT_B PI_GFX_BIAS_A PI_GFX_BIAS_B
PI_GFX_CREDIT_CNTR_A PI_GFX_CREDIT_CNTR_B PI_GFX_INT_CMP_A PI_GFX_INT_CMP_B
PI_GFX_INT_CNTR_A PI_GFX_INT_CNTR_B PI_GFX_PAGE_A PI_GFX_PAGE_B PI_INT_MASK0_A
PI_INT_MASK0_B PI_INT_MASK1_A PI_INT_MASK1_B PI_INT_PEND0 PI_INT_PEND1 PI_INT_PEND_MOD
PI_IO_PROTECT PI_MAX_CRB_TIMEOUT PI_NACK_CMP PI_NACK_CNT_A PI_NACK_CNT_B
PI_NMI_A PI_NMI_B PI_PROFILE_COMPARE PI_PROF_INT_EN_A PI_PROF_INT_EN_B PI_PROF_INT_PEND_A
PI_PROF_INT_PEND_B PI_PROT_OVRRD PI_REGION_PRESENT PI_REPLY_LEVEL PI_RTC_INT_EN_A
PI_RTC_INT_EN_B PI_RT_COMPARE_A PI_RT_COMPARE_B PI_RT_COUNTER PI_RT_FILTER_CTRL
PI_RT_INT_PEND_A PI_RT_INT_PEND_B PI_RT_LOCAL_CTRL PI_SOFTRESET PI_SPOOL_CMP_A
PI_SPOOL_CMP_B PI_SYSAD_ERRCHK_EN PI_UNUSED </FONT></TT></P>
<H4><A NAME="HubMDRegs">Hub MD (Memory/Directory) Registers</A></H4>
<P><TT><FONT SIZE="2">MD_DIR_DIMM_INIT MD_DIR_ERROR MD_DIR_ERROR_CLR MD_FANDOP_CAC_STAT MD_HSPEC_PROTECT
MD_IO_PROTECT MD_IO_PROT_OVRRD MD_LED0 MD_LED1 MD_MEMORY_CONFIG MD_MEM_DIMM_INIT
MD_MEM_ERROR MD_MEM_ERROR_CLR MD_MIG_CANDIDATE MD_MIG_CANDIDATE_CLR MD_MIG_DIFF_THRESH
MD_MIG_VALUE_THRESH MD_MISC_ERROR MD_MISC_ERROR_CLR MD_MLAN_CTL MD_MOQ_SIZE
MD_PERF_CNT0 MD_PERF_CNT1 MD_PERF_CNT2 MD_PERF_CNT3 MD_PERF_CNT4 MD_PERF_CNT5
MD_PERF_SEL MD_PROTOCOL_ERROR MD_PROTOCOL_ERROR_CLR MD_REFRESH_CONTROL MD_SLOT_ID_USTATUS
MD_UREG0_0 MD_UREG0_1 MD_UREG0_2 MD_UREG0_3 MD_UREG0_4 MD_UREG0_5 MD_UREG0_6
MD_UREG0_7 MD_UREG1_0 MD_UREG1_1 MD_UREG1_10 MD_UREG1_11 MD_UREG1_12 MD_UREG1_13
MD_UREG1_14 MD_UREG1_15 MD_UREG1_2 MD_UREG1_3 MD_UREG1_4 MD_UREG1_5 MD_UREG1_6
MD_UREG1_7 MD_UREG1_8 MD_UREG1_9 </FONT></TT></P>
<H4><A NAME="HubIIRegs">Hub II (I/O) Registers</A></H4>
<P><TT><FONT SIZE="2">II_IBCT0 II_IBCT1 II_IBDA0 II_IBDA1 II_IBIA0 II_IBIA1 II_IBLS0 II_IBLS1
II_IBNA0 II_IBNA1 II_IBSA0 II_IBSA1 II_ICCR II_ICDR II_ICMR II_ICRB0_A II_ICRB0_B
II_ICRB0_C II_ICRB0_D II_ICRB1_A II_ICRB1_B II_ICRB1_C II_ICRB1_D II_ICRB2_A
II_ICRB2_B II_ICRB2_C II_ICRB2_D II_ICRB3_A II_ICRB3_B II_ICRB3_C II_ICRB3_D
II_ICRB4_A II_ICRB4_B II_ICRB4_C II_ICRB4_D II_ICRB5_A II_ICRB5_B II_ICRB5_C
II_ICRB5_D II_ICRB6_A II_ICRB6_B II_ICRB6_C II_ICRB6_D II_ICRB7_A II_ICRB7_B
II_ICRB7_C II_ICRB7_D II_ICRB8_A II_ICRB8_B II_ICRB8_C II_ICRB8_D II_ICRB9_A
II_ICRB9_B II_ICRB9_C II_ICRB9_D II_ICRBA_A II_ICRBA_B II_ICRBA_C II_ICRBA_D
II_ICRBB_A II_ICRBB_B II_ICRBB_C II_ICRBB_D II_ICRBC_A II_ICRBC_B II_ICRBC_C
II_ICRBC_D II_ICRBD_A II_ICRBD_B II_ICRBD_C II_ICRBD_D II_ICRBE_A II_ICRBE_B
II_ICRBE_C II_ICRBE_D II_ICTO II_ICTP II_IECLR II_IFDR II_IGFX0 II_IGFX1
II_IIAP II_IIDEM II_IIDSR II_IIWA II_ILAPO II_ILAPR II_ILCSR II_ILLR II_IMEM
II_IOWA II_IPCA II_IPCR II_IPDR II_IPPR II_IPRB0 II_IPRB8 II_IPRB9 II_IPRBA
II_IPRBB II_IPRBC II_IPRBD II_IPRBE II_IPRBF II_IPRTE II_IPRTE0 II_IPRTE1
II_IPRTE2 II_IPRTE3 II_IPRTE4 II_IPRTE5 II_IPRTE6 II_IPRTE7 II_IPTP0 II_IPTP1
II_ITTE1 II_ITTE2 II_ITTE3 II_ITTE4 II_ITTE5 II_ITTE6 II_ITTE7 II_IXCC II_IXTT
II_NOT_DONE II_WCR II_WID II_WSTAT </FONT></TT></P>
<H4><A NAME="HubNIRegs">Hub NI (Network Interface) Registers</A></H4>
<P><TT><FONT SIZE="2">NI_AGE_CPU0_MEMORY NI_AGE_CPU0_PIO NI_AGE_CPU1_MEMORY NI_AGE_CPU1_PIO NI_AGE_GBR_MEMORY
NI_AGE_GBR_PIO NI_AGE_IO_MEMORY NI_AGE_IO_PIO NI_DIAG_PARMS NI_ERROR_CLEAR
NI_GLOBAL_PARMS NI_IO_PROTECT NI_LOCAL_TABLE&lt;00&gt; NI_META_TABLE&lt;00&gt; NI_PORT_ERROR
NI_PORT_PARMS NI_PORT_RESET NI_PROTECTION_CONFIG NI_PROT_OVRRD NI_RETURN_VECTOR
NI_SCRATCH_REG0 NI_SCRATCH_REG1 NI_STATUS_REV_ID NI_VECTOR NI_VECTOR_CLEAR
NI_VECTOR_DATA NI_VECTOR_PARMS NI_VECTOR_READ_DATA NI_VECTOR_STATUS </FONT></TT></P>
<H4><A NAME="HubCoreRegs">Hub CORE (Internal crossbar control) Registers</A></H4>
<P><TT><FONT SIZE="2">CORE_CACR CORE_CDBGSEL CORE_CFDR CORE_CMDAB CORE_CNDAB CORE_CRPQD CORE_CRQQD </FONT></TT></P>
<H4><A NAME="CrossbowRegs">Crossbow Registers (midplane)</A></H4>
<P><TT><FONT SIZE="2">XB_ARB_RELOAD XB_CTRL XB_ERR_CMDWORD XB_ERR_LOWER XB_ERR_UPPER XB_ID XB_INT_LOWER
XB_INT_UPPER XB_LINK_ARB_LOWER_8 XB_LINK_ARB_LOWER_9 XB_LINK_ARB_LOWER_A
XB_LINK_ARB_LOWER_B XB_LINK_ARB_LOWER_C XB_LINK_ARB_LOWER_D XB_LINK_ARB_LOWER_E
XB_LINK_ARB_LOWER_F XB_LINK_ARB_UPPER_8 XB_LINK_ARB_UPPER_9 XB_LINK_ARB_UPPER_A
XB_LINK_ARB_UPPER_B XB_LINK_ARB_UPPER_C XB_LINK_ARB_UPPER_D XB_LINK_ARB_UPPER_E
XB_LINK_ARB_UPPER_F XB_LINK_AUX_STAT_8 XB_LINK_AUX_STAT_9 XB_LINK_AUX_STAT_A
XB_LINK_AUX_STAT_B XB_LINK_AUX_STAT_C XB_LINK_AUX_STAT_D XB_LINK_AUX_STAT_E
XB_LINK_AUX_STAT_F XB_LINK_CTRL_8 XB_LINK_CTRL_9 XB_LINK_CTRL_A XB_LINK_CTRL_B
XB_LINK_CTRL_C XB_LINK_CTRL_D XB_LINK_CTRL_E XB_LINK_CTRL_F XB_LINK_IBUF_FLUSH_8
XB_LINK_IBUF_FLUSH_9 XB_LINK_IBUF_FLUSH_A XB_LINK_IBUF_FLUSH_B XB_LINK_IBUF_FLUSH_C
XB_LINK_IBUF_FLUSH_D XB_LINK_IBUF_FLUSH_E XB_LINK_IBUF_FLUSH_F XB_LINK_RESET_8
XB_LINK_RESET_9 XB_LINK_RESET_A XB_LINK_RESET_B XB_LINK_RESET_C XB_LINK_RESET_D
XB_LINK_RESET_E XB_LINK_RESET_F XB_LINK_STAT_8 XB_LINK_STAT_9 XB_LINK_STAT_A
XB_LINK_STAT_B XB_LINK_STAT_C XB_LINK_STAT_CLR_8 XB_LINK_STAT_CLR_9 XB_LINK_STAT_CLR_A
XB_LINK_STAT_CLR_B XB_LINK_STAT_CLR_C XB_LINK_STAT_CLR_D XB_LINK_STAT_CLR_E
XB_LINK_STAT_CLR_F XB_LINK_STAT_D XB_LINK_STAT_E XB_LINK_STAT_F XB_LLP_CTRL
XB_NIC XB_PERF_CTR_A XB_PERF_CTR_B XB_PKT_TO XB_STAT XB_STAT_CLR </FONT></TT></P>
<H4><A NAME="RouterRegs">Router Registers</A></H4>
<P><TT><FONT SIZE="2">RR_BIST_COUNT_TARGET RR_BIST_DATA RR_BIST_ENTER_RUN RR_BIST_READY RR_BIST_SHIFT_LOAD
RR_BIST_SHIFT_UNLOAD RR_DIAG_PARMS RR_ERROR_CLEAR1 RR_ERROR_CLEAR2 RR_ERROR_CLEAR3
RR_ERROR_CLEAR4 RR_ERROR_CLEAR5 RR_ERROR_CLEAR6 RR_GLOBAL_PARMS RR_HISTOGRAM1
RR_HISTOGRAM2 RR_HISTOGRAM3 RR_HISTOGRAM4 RR_HISTOGRAM5 RR_HISTOGRAM6 RR_LOCAL_TABLE&lt;00&gt;
RR_META_TABLE&lt;00&gt; RR_NIC_ULAN RR_PORT_PARMS1 RR_PORT_PARMS2 RR_PORT_PARMS3
RR_PORT_PARMS4 RR_PORT_PARMS5 RR_PORT_PARMS6 RR_PORT_RESET RR_PROTECTION_CONFIG
RR_RESET_MASK1 RR_RESET_MASK2 RR_RESET_MASK3 RR_RESET_MASK4 RR_RESET_MASK5
RR_RESET_MASK6 RR_SCRATCH_REG0 RR_SCRATCH_REG1 RR_STATUS_ERROR1 RR_STATUS_ERROR2
RR_STATUS_ERROR3 RR_STATUS_ERROR4 RR_STATUS_ERROR5 RR_STATUS_ERROR6 RR_STATUS_REV_ID </FONT></TT></P>
<H4><A NAME="Cop0Regs">R10000 Coprocessor 0 Registers</A></H4>
<P><TT><FONT SIZE="2">C0_23 C0_24 C0_7 C0_BADVADDR C0_BRDIAG C0_CACHEERR C0_CAUSE C0_COMPARE C0_CONFIG
C0_CONTEXT C0_COUNT C0_ECC C0_ENTRYHI C0_ENTRYLO0 C0_ENTRYLO1 C0_EPC C0_ERROREPC
C0_FRAMEMASK C0_INDEX C0_LLADDR C0_PAGEMASK C0_PERFCOUNT C0_PRID C0_RANDOM
C0_STATUS C0_TAGHI C0_TAGLO C0_WATCHHI C0_WATCHLO C0_WIRED C0_XCONTEXT </FONT></TT></P>
<H3><A NAME="PODSymbols">Symbols</A></H3>
<P>The PROM knows the names of symbols within the PROM (and within the Kernel
if one is loaded; see the <B><A HREF="#_wmh4_841959027">kern_sym</B></A> command). Symbols may appear in arithmetic expressions and are replaced
with their addresses. For example,</P>
<PRE>
POD Dex IOC3 000 4A&gt; px main
0xc00000001fc07784
POD Dex IOC3 000 4A&gt; dis (main+0x1c) 4
[main+0x001c, 0x1fc077a0]: 0001083c dsll32 at,at,#0
[main+0x0020, 0x1fc077a4]: 64420000 daddiu v0,v0,0x0
[main+0x0024, 0x1fc077a8]: 0039082c dadd at,at,t9
[main+0x0028, 0x1fc077ac]: 0002103c dsll32 v0,v0,#0
POD Dex IOC3 000 4A&gt; px &quot;memcpy&quot;
0xc00000001fc1db14
</PRE>
<P>Note that certain symbols, such as <B>memcpy</B>, must be quoted because they are reserved words in the PROM (POD command).</P>
<HR>
<H2><A NAME="PODModeCommands">POD Mode Commands</A></H2>
<H3><A NAME="CommandConventions">Conventions</A></H3>
<P>Data types shown in all caps are not to be input literally, but indicate
the type of input expected. Items shown in square brackets ([]) are optional.
Some of the types are:</P>
<CENTER><P ALIGN="CENTER"><TABLE BORDER=1>
<CAPTION>Data Types</CAPTION>
<TR><TH ALIGN=LEFT>Type</TH><TH ALIGN=LEFT>Represents</TH></TR>
<TR><TD>EXPR</TD><TD>Arithmetic expression</TD></TR>
<TR><TD>GPRNAME</TD><TD>GPR register name (symbolic or $num)</TD></TR>
<TR><TD>REGNO</TD><TD>Register number, from 0 to 31</TD></TR>
<TR><TD>BITNO</TD><TD>Bit number, from 0 to 63</TD></TR>
<TR><TD>ADDR</TD><TD>Address, or arithmetic expression enclosed in parenthesis</TD></TR>
<TR><TD>START</TD><TD>Start address</TD></TR>
<TR><TD>LEN</TD><TD>Length in bytes</TD></TR>
<TR><TD>VAL</TD><TD>Number, or arithmetic expression enclosed in parenthesis</TD></TR>
<TR><TD>COUNT</TD><TD>Count or length</TD></TR>
<TR><TD>CMD</TD><TD>Command</TD></TR>
<TR><TD>NODE</TD><TD><A HREF="#NodeIDsNASIDs">Node ID</A> (also called NASID: Numa Address Space Identifier)</TD></TR>
<TR><TD>SLICE</TD><TD>CPU, either A or B.</TD></TR>
<TR><TD>VEC</TD><TD><A HREF="#VectorAddressing">CrayLink Vector</A> path (e.g. 0x15)</TD></TR>
<TR><TD>VADDR</TD><TD>CrayLink Vector address (offset or NI or RR register name)</TD></TR>
</TABLE></P>
</CENTER><P>Parts of a command enclosed in square brackets ([]) are optional.</P>
<P>Multiple possibilities are separated by vertical bars (|).</P>
<H3><A NAME="CommandSummary">Command Summary</A></H3>
<P>The <B>help</B> or <B>?</B> command, used by itself, prints a command summary similar to that shown
in the table below. The <B>help</B> or <B>?</B> command may also take one command name argument to print the summary for
a specific command.</P>
<CENTER><P ALIGN="CENTER"><TABLE BORDER=1>
<CAPTION>Command Summary</CAPTION>
<TR><TH ALIGN=LEFT>Command</TH><TH ALIGN=LEFT>Purpose</TH><TH ALIGN=LEFT>Syntax</TH></TR>
<TR><TD>px</TD><TD>Print hex</TD><TD>px EXPR</TD></TR>
<TR><TD>pd</TD><TD>Print decimal</TD><TD>pd EXPR</TD></TR>
<TR><TD>po</TD><TD>Print octal</TD><TD>po EXPR</TD></TR>
<TR><TD>pb</TD><TD>Print binary</TD><TD>pb EXPR</TD></TR>
<TR><TD>pr</TD><TD>Print register</TD><TD>pr [GPRNAME [VAL]]</TD></TR>
<TR><TD>pf</TD><TD>Print fpreg</TD><TD>pf [REGNO]</TD></TR>
<TR><TD>pa</TD><TD>Print address</TD><TD>pa ADDR [BITNO]</TD></TR>
<TR><TD>lb</TD><TD>Load byte</TD><TD>lb ADDR [COUNT]</TD></TR>
<TR><TD>lh</TD><TD>Load half-word</TD><TD>lh ADDR [COUNT]</TD></TR>
<TR><TD>lw</TD><TD>Load word</TD><TD>lw ADDR [COUNT]</TD></TR>
<TR><TD>ld</TD><TD>Load double-word</TD><TD>ld ADDR [COUNT]</TD></TR>
<TR><TD>sb</TD><TD>Store byte</TD><TD>sb ADDR [VAL [COUNT]]</TD></TR>
<TR><TD>sh</TD><TD>Store half-word</TD><TD>sh ADDR [VAL [COUNT]]</TD></TR>
<TR><TD>sw</TD><TD>Store word</TD><TD>sw ADDR [VAL [COUNT]]</TD></TR>
<TR><TD>sd</TD><TD>Store double-word</TD><TD>sd ADDR [VAL [COUNT]]</TD></TR>
<TR><TD>sdv</TD><TD>sd with verify</TD><TD>sdv ADDR COUNT</TD></TR>
<TR><TD>sr</TD><TD>Store register</TD><TD>sr REG VAL</TD></TR>
<TR><TD>sf</TD><TD>Store fpreg</TD><TD>sf REGNO VAL</TD></TR>
<TR><TD>vr</TD><TD>Vector read</TD><TD>vr VEC VADDR</TD></TR>
<TR><TD>vw</TD><TD>Vector write</TD><TD>vw VEC VADDR VAL</TD></TR>
<TR><TD>vx</TD><TD>Vector exchange</TD><TD>vx VEC VADDR VAL</TD></TR>
<TR><TD>repeat</TD><TD>Repeat count</TD><TD>repeat COUNT CMD</TD></TR>
<TR><TD>loop</TD><TD>Repeat forever</TD><TD>loop CMD</TD></TR>
<TR><TD>while</TD><TD>While loop</TD><TD>while (EXPR) CMD</TD></TR>
<TR><TD>for</TD><TD>For loop</TD><TD>for (CMD;EXPR;CMD) CMD</TD></TR>
<TR><TD>if</TD><TD>If statement</TD><TD>if (EXPR) CMD</TD></TR>
<TR><TD>delay</TD><TD>Delay</TD><TD>delay MICROSEC</TD></TR>
<TR><TD>sleep</TD><TD>Sleep</TD><TD>sleep SEC</TD></TR>
<TR><TD>time</TD><TD>Benchmark timing</TD><TD>time CMD</TD></TR>
<TR><TD>echo</TD><TD>Echo a string</TD><TD>echo &quot;STRING&quot;</TD></TR>
<TR><TD>jump</TD><TD>Inv. cache &amp; jump</TD><TD>jump ADDR [A0 [A1]]</TD></TR>
<TR><TD>call</TD><TD>Call subroutine</TD><TD>call ADDR [A0 [A1]]</TD></TR>
<TR><TD>reset</TD><TD>Reset the system</TD><TD>reset</TD></TR>
<TR><TD>softreset</TD><TD>Softreset a node</TD><TD>softreset n:NODE</TD></TR>
<TR><TD>nmi</TD><TD>Send NMI to node</TD><TD>nmi n:NODE [a|b]</TD></TR>
<TR><TD>help</TD><TD>Display help</TD><TD>help [CMDNAME]</TD></TR>
<TR><TD>inval</TD><TD>Inv. cache(s)</TD><TD>inval [i][d][s]</TD></TR>
<TR><TD>flush</TD><TD>Flush+inv caches</TD><TD>flush</TD></TR>
<TR><TD>tlbc</TD><TD>Clear TLB</TD><TD>tlbc [INDEX]</TD></TR>
<TR><TD>tlbr</TD><TD>Read TLB</TD><TD>tlbr [INDEX]</TD></TR>
<TR><TD>dtag</TD><TD>Dump dcache tag</TD><TD>dtag line</TD></TR>
<TR><TD>itag</TD><TD>Dump icache tag</TD><TD>dtag line</TD></TR>
<TR><TD>stag</TD><TD>Dump scache tag</TD><TD>stag line</TD></TR>
<TR><TD>dline</TD><TD>Dump dcache line</TD><TD>dline line</TD></TR>
<TR><TD>iline</TD><TD>Dump icache line</TD><TD>iline line</TD></TR>
<TR><TD>sline</TD><TD>Dump scache line</TD><TD>sline line</TD></TR>
<TR><TD>adtag</TD><TD>Dump dcache tag</TD><TD>adtag line</TD></TR>
<TR><TD>aitag</TD><TD>Dump icache tag</TD><TD>aitag line</TD></TR>
<TR><TD>astag</TD><TD>Dump scache tag</TD><TD>astag line</TD></TR>
<TR><TD>adline</TD><TD>Dump dcache line</TD><TD>adline line</TD></TR>
<TR><TD>ailine</TD><TD>Dump icache line</TD><TD>ailine line</TD></TR>
<TR><TD>asline</TD><TD>Dump scache line</TD><TD>asline line</TD></TR>
<TR><TD>go</TD><TD>Set memory mode</TD><TD>go dex|unc|cac</TD></TR>
<TR><TD>bist</TD><TD>Self-test Hub</TD><TD>bist le|ae|lr|ar [n:NODE]</TD></TR>
<TR><TD>rbist</TD><TD>Self-test Router</TD><TD>rbist le|ae|lr|ar VEC</TD></TR>
<TR><TD>disable</TD><TD>Disable unit</TD><TD>disable n:NODE [SLICE]</TD></TR>
<TR><TD>enable</TD><TD>Enable unit</TD><TD>enable n:NODE [SLICE]</TD></TR>
<TR><TD>tdisable</TD><TD>Temp. disable</TD><TD>tdisable n:NODE [SLICE]</TD></TR>
<TR><TD>dirinit</TD><TD>Dir/prot init</TD><TD>dirinit START LEN</TD></TR>
<TR><TD>meminit</TD><TD>Memory clear</TD><TD>meminit START LEN</TD></TR>
<TR><TD>dirtest</TD><TD>Dir. test/init</TD><TD>dirtest START LEN</TD></TR>
<TR><TD>memtest</TD><TD>Memory test/init</TD><TD>memtest START LEN</TD></TR>
<TR><TD>santest</TD><TD>Mem. sanity test</TD><TD>santest ADDR</TD></TR>
<TR><TD>slave</TD><TD>Goto slave mode</TD><TD>slave</TD></TR>
<TR><TD>segs</TD><TD>List segments</TD><TD>segs [FLAG]</TD></TR>
<TR><TD>exec</TD><TD>Load/exec segment</TD><TD>exec [SEGNAME [FLAG]]</TD></TR>
<TR><TD>why</TD><TD>Why are we here?</TD><TD>why</TD></TR>
<TR><TD>fru</TD><TD>Run FRU Analyzer</TD><TD>fru [1 | 2]</TD></TR>
<TR><TD>clear</TD><TD>Clear errors</TD><TD>clear</TD></TR>
<TR><TD>error</TD><TD>Display errors</TD><TD>error</TD></TR>
<TR><TD>ioc3</TD><TD>Use IOC3 UART</TD><TD>ioc3</TD></TR>
<TR><TD>junk</TD><TD>Use JunkBus UART</TD><TD>junk</TD></TR>
<TR><TD>elsc</TD><TD>Use MSC (SysCtlr UART)</TD><TD>elsc</TD></TR>
<TR><TD>talk</TD><TD>Use Net UART</TD><TD>talk [n:NODE a|b]</TD></TR>
<TR><TD>nm</TD><TD>Look up PROM addr</TD><TD>nm ADDR</TD></TR>
<TR><TD>disc</TD><TD>Discover CrayLink Interconnect</TD><TD>disc</TD></TR>
<TR><TD>pcfg</TD><TD>Dump pcfg struct</TD><TD>pcfg [n:NODE] [v]</TD></TR>
<TR><TD>node</TD><TD>Get/set node ID</TD><TD>node [[VEC] ID]</TD></TR>
<TR><TD>crb</TD><TD>Dump II CRBs</TD><TD>crb [n:NODE]</TD></TR>
<TR><TD>crbx</TD><TD>137-col wide crb</TD><TD>crbx [n:NODE]</TD></TR>
<TR><TD>route</TD><TD>Set up route</TD><TD>route [VEC NODE]</TD></TR>
<TR><TD>flash</TD><TD>Prgm remote PROM</TD><TD>flash NODE [...]</TD></TR>
<TR><TD>nic</TD><TD>Read Hub NIC</TD><TD>nic [n:NODE]</TD></TR>
<TR><TD>rnic</TD><TD>Read Router NIC</TD><TD>rnic [VEC]</TD></TR>
<TR><TD>sc</TD><TD>System ctlr cmd</TD><TD>sc [&quot;STRING&quot;]</TD></TR>
<TR><TD>scw</TD><TD>Wr sysctlr nvram</TD><TD>scw ADDR [VAL [COUNT]]</TD></TR>
<TR><TD>scr</TD><TD>Rd sysctlr nvram</TD><TD>scr ADDR [COUNT]</TD></TR>
<TR><TD>dips</TD><TD>Rd hardware debug switches</TD><TD>dips</TD></TR>
<TR><TD>dbg</TD><TD>Set/Rd debug switches</TD><TD>dbg [VIRT_VAL PHYS_VAL]</TD></TR>
<TR><TD>pas</TD><TD>Set/Rd MSC password</TD><TD>pas [&quot;PASW&quot;]</TD></TR>
<TR><TD>module</TD><TD>Set/Rd module number</TD><TD>module [VAL]</TD></TR>
<TR><TD>modnic</TD><TD>Get module NIC</TD><TD>modnic</TD></TR>
<TR><TD>qual</TD><TD>Quality mode</TD><TD>qual [1|0]</TD></TR>
<TR><TD>ecc</TD><TD>ECC mode</TD><TD>ecc [1|0]</TD></TR>
<TR><TD>cpu</TD><TD>Switch to cpu</TD><TD>cpu [[n:NODE] a|b]</TD></TR>
<TR><TD>dis</TD><TD>Disassemble</TD><TD>dis ADDR [COUNT]</TD></TR>
<TR><TD>im</TD><TD>Set R10k int mask</TD><TD>im [BYTE]</TD></TR>
<TR><TD>dumpspool</TD><TD>Dump PI err spool</TD><TD>dumpspool [n:NODE SLICE]</TD></TR>
<TR><TD>error_dump</TD><TD>Dump Hub error info</TD><TD>error_dump</TD></TR>
<TR><TD>edump_bri</TD><TD>Dump Bridge error info</TD><TD>edump_bri [n:NODE]</TD></TR>
<TR><TD>maxerr</TD><TD>Test error limit</TD><TD>maxerr COUNT</TD></TR>
<TR><TD>rtab</TD><TD>Dump route table</TD><TD>rtab [VEC]</TD></TR>
<TR><TD>rstat</TD><TD>Dmp/clr rtr stat</TD><TD>rstat VEC</TD></TR>
<TR><TD>version</TD><TD>Show PROM version</TD><TD>version</TD></TR>
<TR><TD>memset</TD><TD>Fill mem w/ byte</TD><TD>memset DST BYTE LEN</TD></TR>
<TR><TD>memcpy</TD><TD>Copy memory bytes</TD><TD>memcpy DST SRC LEN</TD></TR>
<TR><TD>memcmp</TD><TD>Cmp memory bytes</TD><TD>memcmp DST SRC LEN</TD></TR>
<TR><TD>memsum</TD><TD>Add memory bytes</TD><TD>memsum SRC LEN</TD></TR>
<TR><TD>scandir</TD><TD>Scan dir states</TD><TD>scandir ADDR [LEN]</TD></TR>
<TR><TD>dirstate</TD><TD>Directory state</TD><TD>dirstate [STATE [BASE [LEN]]]</TD></TR>
<TR><TD>altregs</TD><TD>Use alt. regs</TD><TD>altregs NUM</TD></TR>
<TR><TD>traplog</TD><TD>Trap log</TD><TD>traplog ADDR</TD></TR>
<TR><TD>kern_sym</TD><TD>Use kernel symtab</TD><TD>kern_sym</TD></TR>
<TR><TD>kdebug</TD><TD>Enable kernel debug functions</TD><TD>kdebug [STACKADDR]</TD></TR>
<TR><TD>initlog</TD><TD>Init. PROM log</TD><TD>initlog [n:NODE]</TD></TR>
<TR><TD>initalllogs</TD><TD>Init. all PROM logs</TD><TD>initalllogs</TD></TR>
<TR><TD>setenv</TD><TD>Set variable</TD><TD>setenv [n:NODE] VAR [&quot;STRING&quot;]</TD></TR>
<TR><TD>unsetenv</TD><TD>Remove variable</TD><TD>unsetenv [n:NODE] VAR</TD></TR>
<TR><TD>printenv</TD><TD>Print variables</TD><TD>printenv [n:NODE] [VAR]</TD></TR>
<TR><TD>log</TD><TD>Print PROM log entries</TD><TD>log [n:NODE] [SKIP [COUNT]]</TD></TR>
<TR><TD>rlog</TD><TD>Print PROM log entries in reverse</TD><TD>rlog [n:NODE] [SKIP [COUNT]]</TD></TR>
<TR><TD>setpart</TD><TD>Set up partition</TD><TD>setpart RTR_LIST</TD></TR>
<TR><TD>hubsde</TD><TD>Send Hub data error</TD><TD>hubsde</TD></TR>
<TR><TD>rtrsde</TD><TD>Send Router data error</TD><TD>rtrsde</TD></TR>
<TR><TD>chklink</TD><TD>Check local link</TD><TD>chklink</TD></TR>
<TR><TD>dgxbow</TD><TD>Run Crossbow diagnostic</TD><TD>dgxbow [m&lt;n|h|m&gt; [n&lt;NODE&gt;]</TD></TR>
<TR><TD>dgbrdg</TD><TD>Run Bridge diagnostic</TD><TD>dgbrdg [m&lt;n|h|m&gt;] [n&lt;NODE&gt;] [s&lt;SLOT&gt;]</TD></TR>
<TR><TD>dgconf</TD><TD>Run BaseIO configuration space diagnostic</TD><TD>dgconf [m&lt;n|h|m&gt;] [n&lt;NODE&gt;] [s&lt;SLOT&gt;]</TD></TR>
<TR><TD>dgpci</TD><TD>Run PCI bus diagnostic</TD><TD>dgpci [m&lt;n|h|m&gt;] [n&lt;NODE&gt;] [s&lt;SLOT&gt;] [p&lt;PCI#&gt;]</TD></TR>
<TR><TD>dgspio</TD><TD>Run serial PIO diagnostic</TD><TD>dgspio [m&lt;n|h|m|x&gt;] [n&lt;NODE&gt;] [s&lt;SLOT&gt;] [p&lt;PCI#]</TD></TR>
<TR><TD>dgsdma</TD><TD>Run serial DMA diagnostic</TD><TD>dgsdma [m&lt;n|h|m|x&gt;] [n&lt;NODE&gt;] [s&lt;SLOT&gt;] [p&lt;PCI#]</TD></TR>
</TABLE></P>
</CENTER><H3><A NAME="CommandDescriptions">Command Descriptions</A></H3>
<H4>Evaluate Expressions</H4>
<UL>
<LI>Print Expression (Calculator)
<P>px EXPR<BR>
pd EXPR<BR>
po EXPR<BR>
pb EXPR</P>
<P>Prints the value of an arithmetic expression in hexadecimal, decimal, octal,
or binary.</P>
<PRE>
Example 1: px n:1 md_memory_config
Example 2: pd 0x3ea
Example 3: pd (0x12000 + 768) / 4
</PRE>
<LI>Print Address
<P>pa ADDR [BITNO]</P>
<P>Decodes an individual memory address and bit to print the name of the physical
DIMM slot where the bit resides and the data line number of the bit. If
only an address is specified, bit 0 is assumed. This works for both regular
memory addresses and back door directory (HSPEC) addresses. For example,</P>
<PRE>
POD Dex IOC3 000 4A&gt; pa 0x40000 21
Memory address 0x0000000000040000 bit 21: MMXL0 DIMML line 39
</PRE>
<LI>nm ADDR
<P>Given an address, attempts to look up the function containing the address
in the PROM symbol table (or Kernel table if using kernel symbols; see <A HREF="#_wmh4_841959027">kern_sym</A>), and if found, displays the function name and offset into the function.</P>
<PRE>
Example:
POD Dex Hub 000 1A&gt; nm 0xc00000001fc07c04
main+0x488
</PRE>
</UL>
<H4>Display Registers</H4>
<UL>
<LI>Print Register
<P>pr [GPRNAME [VAL | ~]</P>
<P>Prints the value of R10000 register(s) or a Hub register. Without arguments,
prints out the R10000 GPRs. With a register name argument, loads a value
from the register and decodes it into bit fields. With a register name and
value, decodes the specified value into bit fields. With a register name
and tilde (~), decodes the register's reset default value into bit fields.
If a value or tilde (~) is specified, the command may also be used with
router registers (<I>RR_*</I>).</P>
<P>A register name may be truncated to its smallest unambiguous form. If the
truncated name is ambiguous, all of the possible choices are listed.</P>
<PRE>
Example 1: pr
Prints all 32 R10000 GPRs with their number and symbolic names
Example 2: pr 2; pr $2; pr r2; pr r02; pr v0
All of these print the value of GPR 2
Example 3: pr cause
Prints the value of the R10000 COP0 CAUSE register
Example 4: pr pi
This register name is ambiguous and causes all of the
Hub PI registers to be printed.
Example 5: pr md_memory_config
Prints the address, contents, and individually decoded
bit fields for the specified Hub register
Example 6: pr n:1 md_memory_config
Prints the address, contents, and individually decoded
bit fields for the specified Hub register loaded
from the remote node with NASID 1.
Example 7: pr md_memory_config 0x001010004fffffff
Decodes the specified constant into individual bit
fields for the specified Hub register
Example 8: pr md_memory_config ~
Decodes the reset default value of the specified Hub
register into individual bit fields for the register.
Example 9: pr rr_status_rev_id ~
Decodes the reset default value of the specified Router
register into individual bit fields for the register.
</PRE>
<LI>Print Floating Point Register
<P>pf [REGNO]</P>
<P>Prints the value of R10000 COP1 (floating point) register(s)</P>
<PRE>
Example 1: pf
Prints all 32 R10000 FPRs
Example 2: pf 3
Prints $f3.
Example 3: px $f3
Also prints $f3 (floating point register names can be
used in expressions).
</PRE>
</UL>
<H4>Load From and Store To Memory</H4>
<UL>
<LI>lb ADDR [COUNT]<BR>
lh ADDR [COUNT]<BR>
lw ADDR [COUNT]<BR>
ld ADDR [COUNT]
<P>Loads a byte, half-word, word, or double-word from a specified address,
and displays the result in hexadecimal. If COUNT is specified, COUNT items
are loaded and displayed in columns. If the specified address is not properly
aligned, an exception may result. Note that cached addresses should not
be accessed while running in Dex mode.</P>
<LI>la ADDR [COUNT]
<P>Loads bytes similar to the <B>lb</B> command, except the output is displayed as ASCII characters instead of
hexadecimal. Bytes outside the range 0x20 (space) through 0x7e (tilde) are
displayed as octal byte codes. Note that cached addresses should not be
accessed while running in Dex mode. </P>
<LI>sb ADDR [VAL [COUNT]]<BR>
sh ADDR [VAL [COUNT]]<BR>
sw ADDR [VAL [COUNT]]<BR>
sd ADDR [VAL [COUNT]]
<P>Stores a byte(s), half-word(s), word(s), or double-word(s) to a specified
address. Note that cached addresses should not be accessed while running
in Dex mode.</P>
<P>If neither VAL or COUNT is specified, the commands enter editing mode in
which the current contents of each address is displayed and the user is
allowed to modify it by typing in a hexadecimal value (without the 0x).
Entering nothing goes on to the next address without modifying the location.
Entering a period exits editing mode.</P>
<P>If VAL is specified, the value is stored at the specified address. If COUNT
is also specified, the value is stored COUNT times starting at the specified
address.</P>
<LI>sdv ADDR COUNT
<P>Stores a double-word at a specified address, loads it back, and verifies
the result. If what was read back was not what was written, it prints an
error message. Note that cached addresses should not be accessed while running
in Dex mode.</P>
</UL>
<H4>Set Registers</H4>
<UL>
<LI>Set General Purpose Register
<P>sr GPRNAME VAL<BR>
GPRNAME = VAL</P>
<P>Assigns a R10000 GPR with the requested value. The modification is done
in the register storage area where the registers are saved in the event
of an exception or NMI.</P>
<LI>Set Floating Point Register
<P>sf REGNO VAL<BR>
$f REGNO = VAL</P>
<P>Assigns a R10000 FPR with the requested value. The modification is done
in the actual R10000 FPRs.</P>
<LI>Set Coprocessor 0 Register
<P>COP0REG = VAL</P>
<P>Assigns the value of a specified R10000 Coprocessor 0 register to a requested
value. The actual R10000 register is modified, except in the case of the
following registers, where the value is written into the register storage
area where the registers are saved in the event of an exception or NMI:
Status, Cause, EPC, BadVAddr, and ErrorEPC. The names of all the registers
are:</P>
<PRE>
Index, Random, EntryLo0, EntryLo1, Context, PageMask,
Wired, Cop0_7, BadVAddr, Count, EntryHi, Compare,
Status, Cause, EPC, PRId, Config, LLAddr, WatchLo,
WatchHi, XContext, FrameMask, BrDiag, Cop0_23, Cop0_24,
PerfCount, ECC, CacheErr, TagLo, TagHi, ErrorEPC.
</PRE>
</UL>
<H4>Vector Operation</H4>
<UL>
<LI>vr VEC VADDR<BR>
vw VEC VADDR VAL<BR>
vx VEC VADDR VAL
<P>Performs a CrayLink vector read, write, or exchange. VEC is the CrayLink
vector of the destination Hub or Router (see section Vector Addressing),
VADDR is the address of which register to access in the Hub or Router, and
VAL is the value to be written or exchanged.</P>
<P>VADDR, in addition to being a numeric offset, when talking to a Hub may
be a symbolic Hub register name from the subset of registers that begin
with <I>NI_</I>, or when talking to a Router may be a symbolic Router register name from
the subset of registers that begin with <I>RR_</I>.</P>
<LI>route [VEC NODE]
<P>Given a vector route VEC from the local Hub to a remote Hub, and a <A HREF="#NodeIDsNASIDs">Node ID</A> (or NASID) to be assigned to the remote Hub, this command programs a minimum
subset of the router tables in the local Hub, remote Hub, and all of the
intervening routers, as well as sets the remote node's NASID. This will
cause the remote node to crash. However, it renders the entire memory and
I/O space of the remote node accessible to the local node.</P>
<PRE>
Example:
POD Cac Hub 000 1A&gt; vr 0x53 ni_status_rev_id
POD Cac Hub 000 1A&gt; route 0x53 1
POD Cac Hub 000 1A&gt; pr n:1 ni_status_rev_id
POD Cac Hub 000 1A&gt; ld n:1 u:0 10
POD Cac Hub 000 1A&gt; flash 1
</PRE>
<P>If no vector and node are given, the PROM consults the internal pcfg structure
(see <B><A HREF="#_wmh4_841959430">disc</B> and <B>pcfg</B> commands</A>), calculates the NASIDs and routing tables, and programs the NASIDs and
routing tables for all Hubs and Routers in the system, using the same calculations
that the normal boot sequence uses.</P>
</UL>
<H4>Control</H4>
<UL>
<LI>repeat COUNT CMD
<P>Executes any POD command(s) a specified number of times. Repeat loops may
be nested and may be broken by typing Control-C.</P>
<PRE>
Example 1: repeat 20 vr 0 0
Example 2: repeat 4 { repeat 3 px 3; repeat 2 px 2 }
</PRE>
<LI>loop CMD
<P>Executes any POD command(s) indefinitely or until the loop is broken by
typing Control-C.</P>
<PRE>
Example 1: loop pr pi_rt_count
Example 2: loop { sd md_led0 0x55; sleep 1; sd md_led0 0xaa; sleep 1 }
</PRE>
<LI>while (EXPR) CMD
<P>Executes a command as long as expression is true.</P>
<PRE>
Example: while ((ld md_ureg8 &amp; 0x40) != 0) {}
</PRE>
<LI>for (CMD;EXPR;CMD) CMD
<P>Executes a &quot;for&quot; statement similar to the C &quot;for&quot; statement. The first command
is executed, then the last command and the second command are executed as
long as the expression is true.</P>
<PRE>
Example: for (v0=0;v0&lt;5;v0=v0+1) {px v0}
</PRE>
<LI>if (EXPR) CMD
<P>Executes the command if the expression is true.</P>
<PRE>
Example: loop { if (ld n:1 u:32m) { px 1 }; sleep 1 }
</PRE>
<LI>delay MICROSEC
<P>Pauses for a specified number of microseconds. May not be interrupted by
Control-C.</P>
<PRE>
Example: loop { sd md_led0 v0; v0=v0+1; delay 25000 }
</PRE>
<LI>sleep SEC
<P>Pauses for a specified number of seconds. May not be interrupted by Control-C.</P>
<LI>time CMD
<P>Benchmarks a specified command and displays the total execution time.</P>
<PRE>
Example: time memtest u:32m 32m; time memtest c:32m 32m
</PRE>
<LI>echo &quot;STRING&quot;
<P>Echos a specified string.</P>
<LI>jump ADDR [A0 [A1]]
<P>Loads the real R10000 a0 and a1 registers with values if specified, and
sets the program counter to the specified address.<BR>
</P>
<LI>call ADDR [A0 [A1 [A2 [A3]]]]
<P>Loads the real R10000 a0, a1, a2, and a3 registers with values if specified,
does a subroutine call to the specified address, and returns to POD prompt.
The return value of the subroutine is stored in the register area as v0
and can be seen using <B>pr v0</B>.</P>
<PRE>
Example: call hub_slot_get; pr v0
</PRE>
<LI>reset
<P>Causes the local node to reset. The reset signal propagates over CrayLinks
to other nodes in the system, causing them to also reset, except the reset
does not propagate past partition boundaries where the reset signal has
been explicitly blocked by the operating system in the routers.</P>
</UL>
<H4>Non-Maskable Interrupts</H4>
<UL>
<LI>nmi NODE [a|b]
<P>Sends a <A HREF="#DebugNMI">non-maskable interrupt</A> to a specific CPU on a specific node. If the slice is not specified, sends
an NMI is sent to both CPUs on the node.</P>
<LI>why
<P>Displays the current exception and NMI status. If an NMI is issued or an
exception occurs while the node is executing in the PROM, the node will
save the exception/NMI status information, including all of the GPRs, program
counter, some COP0 registers, and the exception vector address, and return
to a POD prompt in Dex mode.</P>
<PRE>
Example:
POD Dex Hub 000 1A&gt; ld u:1 # (Misaligned memory address)
9600000000000001:
8A: *** General Exception on node 0
8A: *** EPC: 0xffffffffbfc2a9cc (load+0x48)
8A: *** Press ENTER to continue.
POD Dex Hub 000 1A&gt; why
EPC : 0xffffffffbfc2a394 (load+0x48)
ERREPC : 0x0000000000000000 (0x0)
CACERR : 0x0000000000000000
Status : 0x0000000024407c80
BadVA : 0x0000000000000001 (0x1)
RA : 0xffffffffbfc2a500 (exec_load+0x114)
SP : 0xa800000000103660
A0 : 0x0000000000000001
Cause : 0xffffffff80000010 (BDSLOT INT:-------- &lt;Load Addr Err&gt;)
BusAdr : 0x0000000000000001
Reason : 242 (Unexpected General Exception.)
POD mode was called from: 0xc00000001fc01910 (bevPanic+0xe0)
</PRE>
<LI>fru [1 | 2]
<P>Runs the FRU Analyzer, which reviews the current state of the error registers
(see <B>error_dump</B> command) and attempts to determine which Field Replaceable Unit is the
culprit. This may be a node card, memory SIMM, processor HIMM, router card,
etc. If the argument 1 is given, the FRU Analyzer is run locally only. This
should be used if it is believed the CrayLink network connection is unreliable
or unconfigured. If the argument 2 is given, the FRU Analyzer takes into
account the error data for all nodes.</P>
</UL>
<H4>Help</H4>
<UL>
<LI>help [CMDNAME]<BR>
? [CMDNAME]
<P>If no argument is supplied, displays a summary of usage for all POD commands.
If a command name is given as an argument, displays a summary of usage for
that command only.</P>
<LI>version
<P>Displays version string of the PROM that is running. For example:</P>
<PRE>
POD Dex Hub 000 1A&gt; version
IP27 PROM
SGI Version 1.4 Bring-up built 05:08:35 PM Jul 25, 1996
</PRE>
</UL>
<H4>Cache</H4>
<UL>
<LI>inval [i][d][s]
<P>Invalidates the instruction, data, and or secondary caches. Any combination
of the three letters may be supplied. The contents of the caches is not
written back to memory.</P>
<LI>flush
<P>Causes the contents of the primary and secondary data caches to be flushed
to memory.</P>
<LI>Cache Line Operations
<P>dtag line<BR>
dtag line<BR>
stag line<BR>
dline line<BR>
iline line<BR>
sline line<BR>
adtag line<BR>
aitag line<BR>
astag line<BR>
adline line<BR>
ailine line<BR>
asline line</P>
<P>These functions display instruction, data, and secondary cache lines, addresses,
or tags.</P>
</UL>
<H4>TLB</H4>
<UL>
<LI>tlbc [INDEX]
<P>Clear TLB entry, or entire TLB if no index is specified.</P>
<LI>tlbr [INDEX]
<P>Read TLB entry, or entire TLB if no index is specified.</P>
</UL>
<H4>Operating Mode</H4>
<UL>
<LI><A NAME="GoCommand">go dex|unc|cac</A>
<P><B>go dex</B> flushes the data cache, invalidates all of the caches, initializes the
primary data cache as a stack and data area, then returns to the POD prompt
in memoryless (dirty exclusive) mode.</P>
<P><B>go unc</B> returns to the POD prompt with all POD code, data structures, and stack
in uncached memory. The area of memory to be used by the PROM is first tested,
then the contents of the PROM are copied into it and verified before jumping
to it.</P>
<P><B>go cac</B> returns to the POD prompt with all POD code, data structures, and stack
in cached memory. The area of memory to be used by the PROM is first tested,
then the contents of the PROM are copied into it and verified before jumping
to it.</P>
<P>See <A HREF="#PODMode">POD Mode (PROM Command Interpreter)</A> for more information on operating modes.</P>
</UL>
<H4>Built-in Self Test (BIST)</H4>
<UL>
<LI>bist le|ae|lr|ar [NODE]
<P>Performs a Hub built-in self test. If a NODE is specified, BIST is run on
a remote Hub instead of the local Hub. One of four possible arguments must
be specified:</P>
<PRE>
le Logic BIST Execute
ae Address BIST Execute
lr Logic BIST Results
ar Address BIST Results
</PRE>
<P>Executing a Hub BIST using the <B>le</B> or <B>ae</B> arguments will cause the Hub to perform the self-test, then automatically
reset the node since all state in the Hub is randomized. When the node eventually
returns to the POD prompt, the results can be obtained using the <B>lr</B> or <B>ar</B> arguments.</P>
<LI>rbist le|ae|lr|ar VEC
<P>Performs a Router built-in self test on a Router specified by a CrayLink
vector (see section Vector Addressing). One of four possible arguments must
be specified:</P>
<PRE>
le Logic BIST Execute
ae Address BIST Execute
lr Logic BIST Results
ar Address BIST Results
</PRE>
<P>The Router BIST should be executed using the <B>le</B> or <B>ae</B> arguments. Following the test, the Router will resets itself. Then the <B>lr</B> or <B>ar</B> arguments should be used to retrieve the results of the BIST.</P>
</UL>
<H4><A NAME="EnableAndDisableHardware">Enable and Disable Hardware</A></H4>
<UL>
<LI>disable NODE [SLICE]
<P>Sets the environment variable DisableA or DisableB in the specified node's <A HREF="#PROMLogOverview">PROM</A> log. If no slice is specified, both DisableA and DisableB are set. Once
disabled, a CPU will not participate in the boot process and will completely
prevent itself from making any Hub requests by storing a 1 into its PI_CPU_ENABLE
register as soon as possible.</P>
<LI>enable NODE [SLICE]
<P>Removes the environment variable DisableA or DisableB from the specified
node's <A HREF="#PROMLogOverview">PROM log</A>. If no slice is specified, both DisableA and DisableB are removed.</P>
<LI>tdisable NODE [SLICE]
<P>Temporarily disables a specified CPU until the next system reset. If no
slice is specified, both slice A and B are temporarily disabled. CPUs are
disabled by storing 1 into their PI_CPU_ENABLE register, which completely
prevents them from making any Hub requests. When the node is reset, the
CPU(s) will be re-enabled.</P>
</UL>
<H4><A NAME="_wmh4_841960997">Memory Test</A></H4>
<UL>
<LI>dirinit START LEN
<P>Initializes a range directory memory to the Unowned state. START is an ordinary
memory address that will be masked for the lower 40 bits and translated
to the corresponding directory address (see <B>L:</B> modifier), and LEN is the length in bytes of the area to initialize. Both
START and LEN must be multiples of 4096 (0x1000).</P>
<LI>meminit START LEN
<P>Initializes a range of memory to zeroes. START specifies the address, which
may be cached or uncached, and LEN specifies the length of the region in
bytes. Both START and LEN must be multiples of 4096 (0x1000).</P>
<LI>dirtest START LEN
<P>Tests a range of directory memory. START is an ordinary memory address that
will be masked for the lower 40 bits and translated to the corresponding
directory address (see <B>L:</B> modifier), and LEN is the length in bytes of the area to test. Both START
and LEN must be multiples of 4096 (0x1000).</P>
<P>See <A HREF="#DebugMemoryTests">Memory Tests</A> for a description of the tests performed. Following the tests, the directory
memory will be in an invalid state and must be re-initialized via the <B>dirinit</B> command before the corresponding real memory can be used.</P>
<LI>memtest START LEN
<P>Tests a range of memory. START specifies the address, which may be cached
or uncached, and LEN specifies the length of the region in bytes. Both START
and LEN must be multiples of 4096 (0x1000).</P>
<P>See <A HREF="#DebugMemoryTests">Memory Tests</A> for a description of the tests performed.</P>
<LI>santest ADDR
<P>Performs a sanity test of a memory address. ADDR specifies the address to
be tested, which must be double-word aligned. The address is checked for
readability and writability, with full error register monitoring and exception
catching.</P>
<P>See <A HREF="#DebugMemoryTests">Memory Tests</A> for a description of the sanity test.</P>
<LI>maxerr COUNT
<P>Sets the maximum number of errors that a memory test may print before it
gives up and goes onto the next phase of the test. The default is 32.</P>
<LI>qual [1|0]
<P>Turns the data quality checking features of the R10000 on or off in the
PI_SYSAD_ERRCHK_EN register. This may be useful during memory testing. See
section Memory Tests for more information.</P>
<LI>ecc [1|0]
<P><B>ecc 1</B> turns the IGNORE_ECC bit off and thereby enables ECC checking. When checking
is enabled, exceptions will occur when the ECC for directory memory or regular
memory do not match the data stored in directory memory or regular memory.</P>
<P><B>ecc 0</B> turns the IGNORE_ECC bit on and thereby disables ECC checking. When ECC
checking is disabled, exceptions will not occur due to ECC bad being. However,
the Hub cannot be made to stop error correcting.</P>
<LI>error
<P>Checks for any error bits turned on in the Hub MD section, and decodes and
displays them. You might want to run this whenever the prompt contain the
string <I>MDerr</I>, indicating there are memory/directory errors pending in the Hub.</P>
<LI>clear
<P>Clears any pending error bits in the Hub MD section.</P>
<LI>im [BYTE]
<P>Sets the R10000 interrupt mask field in the Status COP0 register. This affects
whether certain errors cause an interrupt to be taken, especially when running
memory test.</P>
</UL>
<H4>Memory Region</H4>
<UL>
<LI>memset DST BYTE LEN
<P>Fills a range of memory with a byte value. The fill uses double-word stores
where possible to speed the operation. DST is the start byte address, BYTE
is the byte value to use, and LEN is the length in bytes.</P>
<LI>memcpy DST SRC LEN
<P>Copies a range of memory. The copy uses double-word loads and stores where
possible to speed the operation. DST is the destination byte address, SRC
is the source byte address, and LEN is the length in bytes.</P>
<LI>memcmp DST SRC LEN
<P>Compares two ranges of memory and prints whether or not they are the same.
DST and SRC are the byte address of the two ranges, and LEN is the length
in bytes.</P>
<LI>memsum SRC LEN
<P>Adds up the bytes in a range of memory and prints the result. Uses double-word
loads where possible to speed up the operation. This may be used to compare
ranges of memory on different machines by comparing their byte sums. SRC
is the starting byte address, and LEN is the length in bytes.</P>
</UL>
<H4>Directory Region</H4>
<UL>
<LI>scandir ADDR [LEN]
<P>Scans a range of memory, showing the directory states of each location.
To reduce the amount of output, only the start of each region where the
directory state changes is printed. ADDR is an ordinary cache-line aligned
memory address that will be masked for the lower 40 bits and translated
to the corresponding directory address (see <B>L:</B> modifier), and LEN is the length in bytes of the area to test, defaulting
to one cache line.</P>
<LI>dirstate [STATE [BASE [LEN]]]
<P>Scans a range of addresses for a particular directory state.</P>
</UL>
<H4>Slave (Launch) Loop</H4>
<UL>
<LI>slave
<P>Causes a CPU to jump to the IP27prom Slave Launch Loop where it waits to
be assigned a task and awoken by an interrupt sent from another CPU.</P>
<LI>cpu [[NODE] a|b]
<P>Launches a specified CPU that is in the slave loop into <A HREF="#PODMode">POD Mode</A>, and puts the launcher into the Slave Launch Loop, thereby exchanging the
active CPU.</P>
</UL>
<H4>IO6prom</H4>
<UL>
<LI>segs [FLAG]
<P>Reads the IO6prom and prints information about the segments it contains,
their sizes, checksums, etc. If no flag is specified, a default flag of
1 is used. The possible flags are:</P>
<PRE>
0 Use the copy of the IO6prom internal to the IP27prom
instead of going out to the real IO6prom.
1 Use the real IO6prom.
</PRE>
<LI>exec [SEGNAME [FLAG]]
<P>Reads the IO6prom and jumps to a specified named segment. If no SEGNAME
is specified, the default <EM>io6prom</EM> is used. If no flag is specified, a default flag of 1 is used. The possible
flags are:</P>
<PRE>
0 Use the copy of the IO6prom internal to the IP27prom
instead of going out to the real IO6prom.
1 Use the real IO6prom.
2 Load the internal IO6prom, but don't jump to it.
Displays the entry point address and returns to POD mode.
3 Load the real IO6prom, but don't jump to it.
Example: exec io6prom
</PRE>
</UL>
<H4>Console Selection</H4>
<UL>
<LI>ioc3<BR>
junk<BR>
elsc<BR>
<A NAME="TalkCommand">talk</A> [NODE a|b]
<P>These commands switch the POD prompt to alternate consoles. Before switching,
they probe to make sure the selected console is accessible. See <A HREF="#PODConsoles">POD Consoles</A> for information on the types of consoles available. Note that <B>elsc</B> refers to the MSC.</P>
<P>The <B>talk</B> command, used with no arguments, switches over to the virtual <A HREF="Netuart">netuart</A>. With arguments, the <B>talk</B> command attempts to act as a terminal emulator and contact another node
that is using the virtual <A HREF="Netuart">netuart</A>.</P>
</UL>
<H4><A NAME="_wmh4_841959430">CrayLink Interconnect</A></H4>
<UL>
<LI>disc
<P>Runs the CrayLink Interconnect discovery algorithm. This may only be run
in <A HREF="#GoCommand">Cac mode</A> where memory is initialized. The internal <EM>promcfg</EM> data structure is built. This structure is a connectivity graph of all
Hubs and Routers in the system. The <B>pcfg</B> command can be used to view the results. See also: <B>route</B> command (below).</P>
<LI>pcfg [n:NODE] [v]
<P>Displays the contents of the <EM>promcfg</EM> data structure. This structure is a connectivity graph of all Hubs and
Routers in the system. This command should only be used in <A HREF="#GoCommand">Cac mode</A> after discovery has been performed. If the <B>v</B> argument is supplied, only abbreviated hub information will be displayed.
See also: <B>route</B> command (below).</P>
<LI>node [[VEC] ID]
<P>Sets a node ID (or NASID). If VEC is specified, it uses a CrayLink vector
write to set a remote node's NASID. This will crash the remote node, but
may be useful for accessing the remote node's memory and I/O space. If VEC
is not specified, the local Hub's NASID is set. This will crash the local
node, but it will return to POD mode.</P>
<LI>rtab [VEC]
<P>Displays the router tables in the local Hub if a vector VEC is not supplied.
Otherwise, displays the router tables in the device addressed by vector
VEC, whether it is a Hub or Router. See <A HREF="#VectorAddressing">Vector Addressing</A> for more information on vectors.</P>
<P>The routing table information in a Hub consists of 16 local table entries
and 32 meta table entries, each containing a single 4-bit direction. The
routing table information in a Router consists of 16 local table entries
and 32 meta table entries, each containing 24 bits of routing information
organized as 6 4-bit directions each.</P>
<P>See the Origin2000 Hub2 Programming Manual and the Origin2000 Router Manual
for a detailed description of hardware registers.</P>
<LI>rstat VEC
<P>Displays the link error and packet histogram information for a Router addressed
by a specified vector VEC. See <A HREF="#VectorAddressing">Vector Addressing</A> for more information about vectors. See the Origin2000 Router Manual for
a detailed description of hardware registers.</P>
<LI>hubsde
<P>Sends a Hub data error for diagnostic testing purposes.</P>
<LI>rtrsde
<P>Sends a Router data error for diagnostic testing purposes.</P>
<LI>chklink
<P>Reports on the status of the local Hub's CrayLink.</P>
</UL>
<H4>I/O Debug</H4>
<UL>
<LI>crb [NODE]
<P>Dumps the CRB registers from the IO section of the Hub chip, as raw hex
values.</P>
<LI>crbx [NODE]
<P>Dumps the CRB registers from the IO section of the Hub chip in a decoded
wide format that requires 132 columns to display.</P>
</UL>
<H4>PROM Flash</H4>
<UL>
<LI>flash NODE [...]
<P>Flashes a remote node's IP27 Flash PROM with a copy of the local node's
IP27 Flash PROM, over the CrayLink Interconnect. See section on <A HREF="#FlashingPROMs">Flashing PROMs</A> for more details.</P>
<P>The flash command must access the remote node through memory space, and
as such can be used only if the CrayLink routing tables are programmed and
the remote <A HREF="#NodeIDsNASIDs">Node ID</A> is assigned. The <B><A HREF="#_wmh4_841959430">route</B> command</A> is often useful for achieving this.</P>
<P>In emergencies, the <B>flash</B> command can be used from Dex mode, but it's extremely slow. If are running
in Dex mode (for example, by means of an NMI), you may want to try running
from cached memory (<B><A HREF="#GoCommand">go cac</B></A>) before flashing remote PROM(s). </P>
<PRE>
Example:
POD Dex Hub 000 1A&gt; go cac
POD Cac Hub 000 1A&gt; route 0x53 1
POD Cac Hub 000 1A&gt; flash 1
</PRE>
</UL>
<H4>NIC (Number In a Can)</H4>
<UL>
<LI>nic [NODE]
<P>Reads the unique laser tag from the <A HREF="#NumberInACan">NIC</A> (Number In a Can) of the local node if no <A HREF="#NodeIDsNASIDs">Node ID</A> is specified; otherwise reads the NIC of a remote node by accessing its
memory space.</P>
<PRE>
Example:
POD Dex Hub 000 1A&gt; nic
0x000000000001fcba
</PRE>
<LI>rnic [VEC]
<P>Reads the unique laser tag from the <A HREF="#NumberInACan">NIC</A> (Number In a Can) of a router, given a CrayLink vector to the router (default
0). See <A HREF="#VectorAddressing">Vector Addressing</A> for information about vectors.</P>
<PRE>
Example:
POD Dex Hub 000 1A&gt; rnic 1
0x0000000000020300
</PRE>
</UL>
<H4>System Controller</H4>
<UL>
<LI>scw ADDR [VAL [COUNT]]
<P>Stores byte(s) to the Origin2000 Module System Controller non-volatile RAM.
The NVRAM address must be between 0 and 2047, inclusive. Addresses 1792
through 2047 are reserved for MSC use.</P>
<P>If neither VAL or COUNT is specified, scw enters editing mode in which the
current contents of each address is displayed and the user is allowed to
modify it by typing in a hexadecimal value (without the 0x). Entering nothing
goes on to the next address without modifying the location. Entering a period
exits editing mode.</P>
<P>If VAL is specified, the value is stored at the specified address. If COUNT
is also specified, the value is stored COUNT times starting at the specified
address.</P>
<LI>scr ADDR [COUNT]
<P>Reads byte(s) from the Origin2000 Module System Controller non-volatile
RAM. The NVRAM address must be between 0 and 2047, inclusive. Addresses
1792 through 2047 are reserved for MSC use.</P>
<P>If COUNT is specified, COUNT bytes are loaded and displayed in columns.</P>
<LI>sc [&quot;command&quot;]
<P>Sends an arbitrary command string to the system controller for execution.
The result returned by the command is displayed. See <A HREF="#MSCCommands">Module System Controller Commands</A> for a description of commands that might be sent. The <B>dbg</B> and <B>pas</B> commands cannot be executed in this manner since they access the I2C bus
during operation. Instead, corresponding POD commands are provided. </P>
<PRE>
Example: sc &quot;dsp HiWorld&quot;
</PRE>
<LI>dips
<P>Displays the settings of the Hardware <A HREF="#DebugSwitchUse">Debug Switches</A>, exactly as they are set on the MSC front panel.</P>
<LI>dbg [VIRT_VAL PHYS_VAL]
<P>If no arguments are specified, the values of the Physical and Virtual <A HREF="#DebugSwitchUse">Debug Switches</A> are displayed.</P>
<P>If values are specified, then the Virtual and Physical Debug switches are
set to the values specified.</P>
<PRE>
Example: dbg 0 0x18
</PRE>
<P>This command is very similar to the MSC <B>dbg</B> command, except allows the MSC Physical and Virtual Debug Switches to be
set or viewed from IP27prom POD mode. Care should be taken because the arguments
are decimal by default, rather than hex as in the MSC <B>dbg</B> command. Use the <I>0x</I> prefix to set values in hex.</P>
<P>The above example turns off all of the Virtual Debug Switches, and turns
on Physical Debug Switches 4 and 5 (since 0x18 has the fourth and fifth
bits set, numbering from 1). Note that the system XORs the Physical and
Hardware Debug Switches to determine the actual Physical Debug Switches,
so this feature can be used to override remotely the Hardware Debug Switches.</P>
<LI>pas [&quot;PASW&quot;]
<P>This command is very similar to the MSC <B>pas</B> command, except allows the MSC password to be set or viewed from IP27prom
POD mode.</P>
<P>If no arguments are specified, the current four-character system controller
password is displayed.</P>
<P>If a password is specified, the MSC password is replaced by the specified
string, which must be four characters in length. The default MSC password
is <B>none</B>.</P>
<LI>module [VAL]
<P>This command is very similar to the MSC <B>mod</B> command, except allows the <A HREF="#ModuleNumbers">module number</A> of the module containing the current IP27 card to be set or viewed from
IP27prom POD mode. Care should be taken because the argument is decimal
by default, rather than hex as in the MSC <B>mod</B> command. Use the <I>0x</I> prefix to set values in hex.</P>
<P>If no arguments are specified, the current module number is displayed.</P>
<P>If a module number from 0 to 255 is specified, the module number is changed.
See section Module Numbering for important information about module numbers.
The <B>module</B> command does not verify the consistency of module numbers; however, the
IO6prom will repair inconsistent module numbers before allowing the system
to boot.</P>
<LI>modnic
<P>Displays the value of the mid-plane NIC of the module containing the current
node.</P>
</UL>
<H4><A NAME="_wmh4_841959027">Disassembler</A></H4>
<UL>
<LI>dis ADDR [COUNT]
<P>Disassembles a region of memory into R10000 instructions beginning at the
specified start address. If COUNT is specified, then COUNT instructions
will be disassembled (not counting branch delay slots). If COUNT is not
specified, then the disassembly will stop at the end of the function containing
the start address, if applicable. Otherwise, 12 instructions will be disassembled.</P>
<LI>kern_sym
<P>Toggles the set of symbols the PROM uses when translating addresses to symbols
and vice-versa. The two sets of symbols available are the IP27prom symbols
and the Kernel symbols (which are not available unless a Kernel has been
loaded since system boot).</P>
<LI>kdebug [STACKADDR]
<P>Turns on kernel debugging functions (see <A HREF="#KernelDebugging">Kernel Debugging</A>) and returns to POD in a modified <B>Dex</B> mode in which the cache is flushed and the stack pointer is moved into
memory, but the CPU continues to execute out of the PROM.</P>
<LI>altregs NUM
<P>If NUM is 1, causes the PROM to stop using the set of R10000 registers that
were saved on PROM entry, and instead use the set of registers saved by
the Kernel debugger Symmon. If NUM is 0, causes the PROM to switch back
to its regular saved registers. See <A HREF="#KernelDebugging">Kernel Debugging</A>.</P>
<LI>traplog ADDR
<P>Displays entries from the Kernel trap log.</P>
</UL>
<H4>Error Dump</H4>
<UL>
<LI>dumpspool [NODE SLICE]
<P>Dumps the PI error spool on the local Hub if NODE and SLICE are not specified.
Dumps the PI error spool(s) on a remote Hub if a NODE and SLICE are specified.
SLICE indicates the CPU(s), and may be A, B, or AB.</P>
<LI>error_dump
<P>Dumps the error state of the local Hub. All of the error bits in the various
sections of the Hub are decoded and displayed in detail.</P>
<LI>edump_bri [n:NODE]
<P>Dumps the error state of a local or remote Bridge. All of the error bits
in the various sections of the Bridge are decoded and displayed in detail.</P>
</UL>
<H4><A NAME="EnvironmentCommands">PROM Log and Environment Variables</A></H4>
<UL>
<LI>initlog [n:NODE]
<P>Initializes the <A HREF="#PROMLogOverview">PROM Log</A> in a new or corrupt PROM. Clears all variable entries and error log entries.
If a node is specified, the operation is done on a remote node's PROM instead
of the local PROM. This command may not be used on the local PROM in <A HREF="#GoCommand">Dex mode</A> since the PROM cannot be programmed while running from it.</P>
<P><I>WARNING</I>: Executing <B>initlog</B> on a remote PROM will crash the remote node if it is running in Dex mode
(out of the PROM).</P>
<LI>initalllogs
<P>Initializes the <A HREF="#PROMLogOverview">PROM Log</A> on every node in the system. This command may only be run when the system
is in Cac mode and the CrayLink network has already been fully and properly
configured.</P>
<P><I>WARNING</I>: Executing <B>initalllogs</B> will crash any remote node that is running in Dex mode (out of the PROM).</P>
<LI>setenv [n:NODE] VAR [STRING]
<P>Sets an environment variable in the PROM Log. If a node is specified, the
operation is done on a remote node's PROM instead of the local PROM. VAR
is the name of the variable and must be from 1 to 15 ASCII characters. STRING
is the value, which must be from 0 to 127 ASCII characters, and usually
must be enclosed in quotes. If STRING is omitted, the PROM will prompt for
a string (this is useful because the PROM parser may only handle strings
up to 31 characters in length). Certain variable names that are reserved
words in the PROM, such as &quot;ld&quot; or &quot;v0,&quot; may also have to be enclosed in
quotes. Numeric values must also be enclosed in quotes. This command may
not be used on the local PROM in Dex mode since the PROM cannot be programmed
while running from it.</P>
<P><I>WARNING</I>: Executing <B>setenv</B> on a remote PROM will crash the remote node if it is running in Dex mode
(out of the PROM).</P>
<PRE>
Example: setenv SwapBank &quot;1&quot;
</PRE>
<P>See <A HREF="#ReservedPROMLogVariables">Reserved PROM Log Variables</A> for information on specific environment variables.</P>
<LI>unsetenv [n:NODE] VAR
<P>Removes an environment variable from the <A HREF="#PROMLogOverview">PROM Log</A>. If a node is specified, the operation is done on a remote node's PROM
instead of the local PROM. VAR is the name of the variable and must be from
1 to 15 ASCII characters. Certain variable names that are reserved words
in the PROM, such as <B>ld</B> or <B>v0</B>, must be enclosed in quotes. This command may not be used on the local
PROM in Dex mode since the PROM cannot be programmed while running from
it.</P>
<P><I>WARNING</I>: Executing <I>unsetenv</I> on a remote PROM will crash the remote node if it is running in Dex mode
(out of the PROM).</P>
<LI>printenv [n:NODE] [VAR]
<P>Displays environment variable(s) in the <A HREF="#PROMLogOverview">PROM Log</A>. If a node is specified, the operation is done on a remote node's PROM
instead of the local PROM. If VAR is not specified, all environment variables
are printed. If VAR is specified, it is the name of the variable and must
be from 1 to 15 ASCII characters. Certain variable names that are reserved
words in the PROM, such as <B>ld</B> or <B>v0</B>, must be enclosed in quotes.</P>
<LI>log [n:NODE] [SKIP [COUNT]]
<P>Displays log entries from the <A HREF="#PROMLogOverview">PROM Log</A>. If a node is specified, the operation is done on a remote node's PROM
instead of the local PROM. If SKIP is specified, the first SKIP entries
are not displayed. If COUNT is specified, COUNT entries are displayed (otherwise,
24 entries are displayed). The output is paged to prevent it from scrolling
away.</P>
<LI>rlog [n:NODE] [SKIP [COUNT]]
<P>Displays log entries from the <A HREF="#PROMLogOverview">PROM Log</A> in reverse order. If a node is specified, the operation is done on a remote
node's PROM instead of the local PROM. If SKIP is specified, the first SKIP
entries are not displayed. If COUNT is specified, COUNT entries are displayed
(otherwise, 24 entries are displayed). The output is paged to prevent it
from scrolling away.</P>
</UL>
<H4><A NAME="PartitionCommands">Partitioning</A></H4>
<UL>
<LI>setpart RTR_LIST
<P>Sets reset partitions for partition (<I>testing only</I>).</P>
</UL>
<H4>I/O Diagnostics</H4>
<UL>
<LI>dgxbow [m&lt;n|h|m&gt; [n&lt;NODE&gt;]
<P>Runs Crossbow diagnostic. The first optional two-character argument specifies
the test mode as Normal, Heavy, or Manufacturing. The second optional argument
specifies a remote NASID on which to run the test.</P>
<LI>dgbrdg [m&lt;n|h|m&gt;] [n&lt;NODE&gt;] [s&lt;SLOT&gt;]
<P>Runs Bridge diagnostic. The first optional two-character argument specifies the test mode as Normal,
Heavy, or Manufacturing. The second optional argument specifies a remote
NASID on which to run the test. The third optional argument specifies a
slot on which to run the test.</P>
<LI>dgconf [m&lt;n|h|m&gt;] [n&lt;NODE&gt;] [s&lt;SLOT&gt;]
<P>Runs BaseIO configuration space diagnostic. The first optional two-character argument specifies the test mode as Normal,
Heavy, or Manufacturing. The second optional argument specifies a remote
NASID on which to run the test. The third optional argument specifies a
slot on which to run the test.</P>
<LI>dgpci [m&lt;n|h|m&gt;] [n&lt;NODE&gt;] [s&lt;SLOT&gt;] [p&lt;PCI#&gt;]
<P>Runs PCI bus diagnostic. The first optional two-character argument specifies the test mode as Normal,
Heavy, or Manufacturing. The second optional argument specifies a remote
NASID on which to run the test. The third optional argument specifies a
slot on which to run the test.</P>
<LI>dgspio [m&lt;n|h|m|x&gt;] [n&lt;NODE&gt;] [s&lt;SLOT&gt;] [p&lt;PCI#]
<P>Runs serial PIO diagnostic. The first optional two-character argument specifies the test mode as Normal,
Heavy, or Manufacturing. If x is present, external loopback is used. The
second optional argument specifies a remote NASID on which to run the test.
The third optional argument specifies a slot on which to run the test.</P>
<LI>dgsdma [m&lt;n|h|m|x&gt;] [n&lt;NODE&gt;] [s&lt;SLOT&gt;] [p&lt;PCI#]
<P>Runs serial DMA diagnostic. The first optional two-character argument specifies the test mode as Normal,
Heavy, or Manufacturing. If x is present, external loopback is used. The
second optional argument specifies a remote NASID on which to run the test.
The third optional argument specifies a slot on which to run the test.</P>
</UL>
<H2><A NAME="Debugging">Debugging with the IP27prom</A> <IMG SRC="debug.gif" ALIGN="RIGHT" WIDTH="60" HEIGHT="60" SGI_SETWIDTH SGI_SETHEIGHT SGI_FULLPATH="/tmp_mnt/hosts/ddt/b/csm/ficus/stand/arcs/IP27prom/doc/html/debug.gif"></H2>
<H3><A NAME="DebugReset">Reset</A></H3>
<P>The hardware reset signal is generated by pressing the left button on the <A HREF="#ModuleSystemController">front panel</A> of the Origin2000 Module System Controller, or by using the MSC <B>rst</B> command. All CPUs and other hardware in the module are reset. Reset may
also be sent by means of software, such as when the <B>reset</B> command is used in POD mode.</P>
<P>The reset signal is propagated by hardware over the CrayLinks into other
modules in the same partition. On system power-up, there are no partitions
and the reset propagates throughout the entire CrayLink network. Subsequently, <EM>reset barriers</EM> are put in place to separate the system into separately resettable <EM>partitions</EM>.</P>
<H3><A NAME="DebugNMI">Non-Maskable Interrupt (NMI)</A></H3>
<P>NMIs are used for debugging a system that is hung, usually because of a
software (PROM or Kernel) bug. An NMI to a CPU causes the CPU to stop what
it's doing and jump to a fixed address in the PROM. The code at that address,
called the NMI handler, attempts to bring the system to a PROM or Kernel
monitor where the state of the system can be examined to determine the cause
of the crash. The NMI handler is written carefully to avoid making assumptions
about the state of the system and to avoid using system resources unnecessarily.</P>
<P>NMIs can be sent by means of software or by hardware. Software can send
an NMI over the CrayLink Interconnect to any individual CPU. Pressing the
right button on the front panel of the Origin2000 Module System Controller,
or using the MSC <B>nmi</B> command, sends a hardware NMI to all of the CPUs plugged into the same
module -- these CPUs will attempt to propagate the NMI to other modules
in the same partition by means of a software NMI.</P>
<P>The NMI handler determines if the system was running in the Kernel or in
the PROM at the time of the NMI by examining the NMI program counter. If
the system was running in the PROM, the CPU immediately enters POD mode.
Otherwise, the handler checks if a Kernel debugging facility (such as symmon)
is available, and if so, transfers control to it. Sometimes the Kernel debugging
facility may subsequently hang due to data corruption. For this reason,
if another NMI is received (called a <EM>second NMI</EM>), the PROM will ignore the Kernel debugging facility and enter POD mode.</P>
<P>Occasionally, a hung Node may not respond to an NMI if the Hub or R10000
is completely hung. When a Node does respond to an NMI, a four-stage pattern
flashes along the Node LEDs.</P>
<H3><A NAME="KernelDebugging">Kernel Debugging</A></H3>
<P><I>Courtesy of Uday Hegde</I></P>
<P>There is support in the IP27prom to dump kernel data structures info via <I>idbg</I>. This is especially useful if <I>symmon</I> does not respond to the first NMI and you use the second NMI to drop into
the IP27prom.</P>
<P>On NMI, all the kernel registers are saved and you enter prom <B>Dex</B> mode. To switch to kernel debug mode, you just type <B>kdebug</B>. This will enable kernel symbols in the PROM, switch the stack to memory
so that we can do cached references, and switch your register set to the
one that was saved on NMI. The stack is automatically placed somewhere near
64 MB on each node, but this can be overridden with an optional address
to <B>kdebug</B>.</P>
<P>If any exceptions are taken while printing/inspecting kernel data structures,
the PROM will re-enter <B>Dex</B> mode. However, the kernel register state is still intact so just typing <B>kdebug</B> will get you back in business.</P>
<P>You can use <B>call idbg_func <I>args</I></B> to dump kernel data structures. Some of these may take TLB exceptions,
since TLB misses will not be processed normally. Any <I>idbg</I> function that does not use qprintf (and uses printf or other printing routines)
to dump the information will fail. </P>
<P>Here are some useful commands:</P>
<UL>
<LI><B>kdebug</B> [optional stack address] - switch to kdebug mode.
<LI><B>altregs &lt;num&gt;</B> or <B>&lt;Address&gt;</B> - Switch to an alternate register set. A number is interpreted as (nasid
&lt;&lt; 1 | slice). An address is used as an address to the register set.
<LI><B>call idbg_xxxxx [arg1 [arg2 [arg3 [arg4]]]]</B>
</UL>
<P>Here are some examples:</P>
<OL>
<LI>kdebug (or kdebug 0xa800000001000000 to force sp to an address)
<PRE>
1A 000: POD MSC Dex&gt;kdebug
1A 000:
1A 000: *** Turning on kernel symbol table lookup
1A 000: Using Alternate register set at 0x9600000000011400
1A 000:
1A 000: *** Entering POD mode with new stack pointer on node 0
1A 000: POD MSC Dex AltRegs 0x9600000000011400&gt; why
1A 000: EPC : 0xc000000000534378 (wait_for_interrupt+0x28)
1A 000: ERREPC : 0xc0000000004b44f4 (local_idle+0x8)
1A 000: CACERR : 0x00000000dfffffff
1A 000: Status : 0x0000000024400080
1A 000: BadVA : 0x0000000010008848 (0x10008848)
1A 000: RA : 0xc000000000534378 (wait_for_interrupt+0x28)
1A 000: SP : 0xa800000000deff88
1A 000: A0 : 0x0000000000000000
1A 000: Cause : 0x0000000000009000 (INT:8--5----)
1A 000: Reason : 253 (POD mode switch set or POD key pressed.)
1A 000: POD mode was called from: 0x0000000000000000 (0x0)
</PRE>
<LI>altregs (this example switches the register set to nasid 1, cpu 1's register
state at NMI)
<PRE>
1A 000: POD MSC Dex AltRegs 0x9600000000011400&gt; altregs 3
1A 000: Using Alternate register set at 0x9600000100011800
1A 000: POD MSC Dex AltRegs 0x9600000100011800&gt; why
1A 000: EPC : 0xc0000000004b44fc (local_idle+0x10)
1A 000: ERREPC : 0xc000000000534378 (wait_for_interrupt+0x28)
1A 000: CACERR : 0x00000000dfffffff
1A 000: Status : 0x0000000024400080
1A 000: BadVA : 0x000000001013fff0 (0x1013fff0)
1A 000: RA : 0xc000000000534378 (wait_for_interrupt+0x28)
1A 000: SP : 0xa800000100e03f88
1A 000: A0 : 0x0000000000000000
1A 000: Cause : 0x0000000000009000 (INT:8--5----)
</PRE>
<LI>Something that <I>symmon</I> cannot do
<PRE>
1A 000: POD MSC Dex AltRegs 0x9600000000011400&gt; a0=0x400; while(a0&lt;0x800) {call idbg_pfn a0; a0=a0+1}
1A 000: pfdat: addr 0xa800000001ff0000 [1024 0x400] flags 0x2800 &lt;dump cstale &gt;
1A 000: pageno 0x0 tag 0x0 use 1 rawcnt 1069
1A 000: next 0x0 [-1] prev 0x0 [-1] hchain 0x0 [-1]
1A 000: Bitmap base (pure) a800000001ffff00 (tainted) a800000001fffe00
1A 000: pdep1: 0x0 pdep2: 0x0
1A 000: PFMS: 0x0
1A 000:
1A 000: pfdat: addr 0xa800000001ff0040 [1025 0x401] flags 0x2800 &lt;dump cstale &gt;
1A 000: pageno 0x0 tag 0x0 use 1 rawcnt 1031
1A 000: next 0x0 [-1] prev 0x0 [-1] hchain 0x0 [-1]
1A 000: Bitmap base (pure) a800000001ffff00 (tainted) a800000001fffe00
1A 000: pdep1: 0x0 pdep2: 0x0
1A 000: PFMS: 0x0
1A 000:
1A 000: pfdat: addr 0xa800000001ff0080 [1026 0x402] flags 0x2800 &lt;dump cstale &gt;
1A 000: pageno 0x0 tag 0x0 use 1 rawcnt 1031
1A 000: next 0x0 [-1] prev 0x0 [-1] hchain 0x0 [-1]
1A 000: Bitmap base (pure) a800000001ffff00 (tainted) a800000001fffe00
1A 000: pdep1: 0x0 pdep2: 0x0
1A 000: PFMS: 0x0
1A 000:
1A 000: pfdat: addr 0xa800000001ff00c0 [1027 0x403] flags 0x2800 &lt;dump cstale &gt;
1A 000: pageno 0x0 tag 0x0 use 1 rawcnt 1031
1A 000: next 0x0 [-1] prev 0x0 [-1] hchain 0x0 [-1]
1A 000: Bitmap base (pure) a800000001ffff00 (tainted) a800000001fffe00
1A 000: pdep1: 0x0 pdep2: 0x0
1A 000: PFMS: 0x0
1A 000:
1A 000: pfdat: addr 0xa800000001ff0100 [1028 0x404] flags 0x2800 &lt;dump cstale &gt;
1A 000: pageno 0x0 tag 0x0 use 1 rawcnt 1031
1A 000: next 0x0 [-1] prev 0x0 [-1] hchain 0x0 [-1]
1A 000: Bitmap base (pure) a800000001ffff00 (tainted) a800000001fffe00
1A 000: pdep1: 0x0 pdep2: 0x0
</PRE>
<LI>idbg_runq
<PRE>
1A 000: POD MSC Dex AltRegs 0x9600000000011400&gt; call idbg_runq 1
1A 000: Runq(0xc000000001cfb7f8): active(0xf)
1A 000:
1A 000: CPU 0:
1A 000: CPU 1:
1A 000: CPU 2:
1A 000: CPU 3:
1A 000:
1A 000: vmp 0 at 0xa800000000f34000
1A 000: vmp 1 at 0xa800000000f34080
1A 000: vmp 2 at 0xa800000000f34100
1A 000: vmp 3 at 0xa800000000f34180
1A 000:
</PRE>
<LI>pb
<PRE>
1A 000: POD MSC Dex AltRegs 0x9600000000011400&gt; call idbg_print putbuf 0xfffffff
fffffffff
1A 000: Memfit Initialized...
1A 000: &lt;5&gt;NOTICE: [memsched_init]: There are 2 &lt;= 2^1 memory nodes.
1A 000: b.0.210
1A 000: &lt;4&gt;WARNING: Nasid 0 interrupt bit 31 set in INT_PEND1
1A 000: &lt;4&gt;WARNING: Nasid 0 interrupt bit 63 set in INT_PEND1
1A 000: &lt;4&gt;WARNING: Nasid 1 interrupt bit 31 set in INT_PEND1
1A 000: &lt;4&gt;WARNING: Nasid 1 interrupt bit 63 set in INT_PEND1
1A 000: &lt;4&gt;WARNING: CPU 0 (/hw/module/1/slot/n1/node/cpu/0) is downrev (925)
1A 000: &lt;4&gt;WARNING: CPU 1 (/hw/module/1/slot/n1/node/cpu/1) is downrev (925)
1A 000: &lt;4&gt;WARNING: CPU 2 (/hw/module/1/slot/n2/node/cpu/0) is downrev (925)
1A 000: &lt;4&gt;WARNING: CPU 3 (/hw/module/1/slot/n2/node/cpu/1) is downrev 000: Realtime overflow q:
</PRE>
<LI>nodenuma (and it ultimately fails since it uses <I>printf</I>)
<PRE>
1A 000: POD MSC Dex AltRegs 0x9600000000011400&gt; call idbg_nodepda_numa 1
1A 000: Dumping node numa parameters at 0xa800000100c0c000
1A 000: memoryd semaphore @ 0xa800000100c0c008 ((noname)) count -1 flags:
1A 000: wq: 0xa800000001aa0000; no meter info
1A 000: Migration Control Parameters, (mcd)@: 0xa800000100c108b0
1A 000: Migration Per Address Space Default Kernel Parameters:
1A 000: migration_base_enabled: 0x1
1A 000: migr_base_threshold: 0x3c
.......
1A 000: migr_unpegger_npages: 27
1A 000: migr_unpegger_lastnpages: 0
1A 000:
1A 000: *** General Exception on node 0
1A 000: *** EPC: 0xc000000000532664 (0xc000000000532664)
1A 000: *** Press ENTER to continue.
1A 000: POD MSC Dex&gt; kdebug
1A 000:
1A 000: POD MSC Dex AltRegs 0x9600000000011400
</PRE>
</OL>
<H3><A NAME="DebugMSC">Use of the MSC</A></H3>
<P>The MSC alternate console port is shared between CPUs. Upon taking an NMI
or exception, each CPU prints a brief three-line message on the MSC indicating
what happened, and waits for the user to press <TT>ENTER</TT>.</P>
<P>The user can then use the MSC <B>sel</B> command to select a particular CPU, press <TT>ENTER</TT> to get a POD prompt on that CPU, and use the <B>why</B> and <B>pr</B> commands to obtain detailed information on where the system was executing,
why it stopped, and what state the CPU registers and memory were in.</P>
<H3><A NAME="DebugFastLoops">Fast loops</A></H3>
<P>Since PROM command lines are precompiled, then executed by a fast stack-based
engine, a loop of register stores or loads (such as for testing I/O devices)
can be executed at relatively high speed. For example:</P>
<PRE>
loop { sd ADDR1 value1; sd ADDR2 value2 }
loop v0 = ld ADDR
</PRE>
<H3><A NAME="DebugMemoryTests">Memory Tests</A></H3>
<H4><A NAME="BankOrganization">Bank Organization</A></H4>
<P>Memory is organized in up to 8 banks of up to 512 MB each. The base address
of each bank is separated by 512 MB <I>regardless</I> of the the actual size of the bank. Thus, there is a <EM>hole</EM> in the memory address space wherever one bank follows another that's less
than 512 MB. Care should be taken to avoid testing a region of memory that
crosses a hole.</P>
<P>For example, if there are four banks of 64 MB in the system, there would
be memory in the following address ranges (assuming cached space):</P>
<PRE>
c:0 through c:(64m-1) <EM>or</EM> c:b:0 0 through c:b:0 (64m-1)
c:512m through c:(576m-1) <EM>or</EM> c:b:1 0 through c:b:1 (64m-1)
c:1024m through c:(1088m-1) <EM>or</EM> c:b:2 0 through c:b:2 (64m-1)
c:1536m through c:(1600m-1) <EM>or</EM> c:b:3 0 through c:b:3 (64m-1)
</PRE>
<H4><A NAME="RunningTheTests">Running the Tests</A></H4>
<P>Memory tests clear the error registers before they start. During the test,
if a data miscompare occurs, the contents of the error registers are decoded
and displayed along with the test address and data.</P>
<P>If the <B>qual on</B> command is used, the data quality checking features of the R10000 will
be enabled (PI_SYSAD_ERRCHK_EN). If data quality mode is on, then events
such as ECC errors and SysAD parity errors will cause the R10000 to take
exceptions during a memory test. On any exception during a memory test,
the contents of the error registers are decoded and displayed along with
the test address and data.</P>
<P>The <B>ecc off</B> command must be used prior to testing directory memory, or when testing
regular memory but the directory memory is uninitialized, to prevent false
ECC errors from occurring during the test.</P>
<P>Note that even when ECC checking is turned off, ECC correcting remains enabled.
It is not possible to turn off error correcting in the Hub. For this reason,
memory tests must be performed in the following order: test directory memory;
initialize directories; test regular memory.</P>
<P>The standard memory test performs multiple phases:</P>
<OL>
<LI>Store/load
<P>For each double-word address in the memory range, do a store of all 5's,
and immediately load it back and compare, then do a store of all A's, and
immediately load it back and compare. This test may find problems with RAM
cells that take too long to change state.<BR>
</P>
<LI>A5 fill/verify
<P>The memory range is filled with alternating double-word patterns of all
5's and all A's, then the range is read back and verified.<BR>
</P>
<LI>5A fill/verify
<P>The memory range is filled with alternating double-word patterns of all
A's and all 5's, then the range is read back and verified.<BR>
</P>
<LI>C3 fill/verify
<P>The memory range is filled with alternating double-word patterns of 0xc3c3c3c3c3c3c3c3
and 0x3c3c3c3c3c3c3c3c, then the range is read back and verified.<BR>
</P>
<LI>3C fill/verify
<P>The memory range is filled with alternating double-word patterns of 0x3c3c3c3c3c3c3c3c
and 0xc3c3c3c3c3c3c3c3, then the range is read back and verified.<BR>
</P>
<LI>Random fill/verify
<P>The memory range is filled with pseudo-random double-words (same pattern
every time), then read back and verified. This is an address test that verifies
that all memory addresses are unique.<BR>
</P>
<LI>Address fill/verify
<P>The memory range is filled with double-words corresponding to the address
being written, then read back and verified. This is an address test that
verifies that all memory addresses are unique. Since this is the last test,
memory is left filled with incrementing double-words.</P>
</OL>
<P>The <A HREF="#_wmh4_841960997">commands</A> for performing memory initialization and tests are:</P>
<PRE>
dirinit
dirtest
meminit
memtest
</PRE>
<P>It's not recommended to run memory tests in <A HREF="#GoCommand">Dex mode</A> since they so slow; they take very long and don't stress the memory. Also,
tests cannot be run to cached memory while in Dex mode since the cache is
already being used for POD memory.</P>
<P>Examples</P>
<OL>
<LI><TT>memtest u:32m 1m</TT><BR>
<TT>memtest 0x9600000002000000 0x100000</TT>
<P>These are equivalent and test one megabyte of uncached memory space starting
at an offset of 32 megabytes. The first argument is the start address, uncached
32 megabytes, and the second is the length.</P>
<LI><TT>memtest c:32m 32m</TT>
<P>Tests the second 32 megabytes of cached memory. Tests on cached memory are
very fast. However, it doesn't make sense to test a very small region of
memory since you would only be testing out of the cache.</P>
<LI><TT>memtest u:b:3 0 64m</TT>
<P>Tests 64 megabytes of uncached memory in bank 3. The <B>b:</B> is a shorthand way to add multiples of the bank size, 512 megabytes, to
the address.</P>
<LI><TT>memtest n:7 b:3 c: 1m 63m</TT><BR>
<TT>memtest (n:7 b:3 c: 1m) 63m</TT><BR>
<TT>memtest 0xa800000760100000 0x3f00000</TT>
<P>These are equivalent and test 63 megabytes of cached memory on node (NASID)
7, beginning at the the one megabyte point of bank 3.</P>
</OL>
<P>When testing directory/protection memory, as opposed to regular memory,
the dirtest command is used. It doesn't matter whether one uses a physical,
cached, or uncached address. ECC checking should be turned off when testing
directory memory.</P>
<P>The <B>maxerr</B> command controls the number of errors the memory test prints before it
gives up and goes on to the next phase of the memory test. The default is
to print 32 errors.</P>
<P>A final memory test available is the sanity test (<B>santest</B>) which tests a single address according to the following scheme:</P>
<OL>
<LI>Clear the error registers and verify that they clear
<LI>Test that no bits in the corresponding directory memory entry LO/HI are
stuck at 1 or 0, with error register checking.
<LI>Initialize the corresponding directory memory entry LO/HI to the Unowned
state.
<LI>Test that no bits in the memory location are stuck at 1 or 0, with error
register checking.
</OL>
<H3><A NAME="DebugProblemReporting">Problem Reporting</A></H3>
<P>There are four general types of problems that may occur in the PROM:</P>
<OL>
<LI>The PROM takes an unexpected exception and enters POD mode.
<LI>The PROM hangs, but can be made to enter POD mode by sending an NMI.
<LI>The PROM hangs, but does not respond to NMI.
<LI>The PROM waits for something to happen that never occurs.
</OL>
<P>If either of the first two cases occur, useful debugging information can
be dumped that may aid a PROM developer in quickly pin-pointing the problem.
At a minimum, the output of the following POD mode commands should be captured:</P>
<PRE>
why &lt;-- Prints the exception type and status registers
pr &lt;-- Prints all R10000 general purpose registers
error_dump &lt;-- Displays detailed Hub error register dump
crbx &lt;-- If it appears to be I/O-related
edump_bri &lt;-- If it appears to be Bridge-related
fru 1 &lt;-- Runs the FRU Analyzer on the error dump data
</PRE>
<P>The third case usually indicates the Hub chip has been hung, typically because
of I/O problems, and is very difficult to debug. The only available information
is the last thing the PROM printed (or the last progress LED value).</P>
<P>The fourth case usually indicates a CrayLink communications problem. One
node may be waiting on another, but never hear from it due to link errors.
Multiple nodes may believe they are the global master. It is very useful
to check for extinguished Router card LEDs to see if any of the CrayLink
connections have gone down, effectively isolating a CPU while the system
was running (see <A HREF="#ReadingTheRouterLEDs">Reading the Router LEDs</A>).</P>
<H3><A NAME="FlashingPROMs">Flashing PROMs</A></H3>
<P>The flashing method described here should not be necessary except in case
of blank systems or special emergencies. Ordinarily, the IO6prom and Irix <B>flashcpu</B>, <B>flashio</B>, and <B>flash</B> commands are all that is needed for flashing, but if a system can't come
up to the IO6prom or Irix due to a PROM problem, this may come in handy.</P>
<P>It is possible to use one node to flash another node's PROM using the IP27prom <B>flash</B> command. The contents of the PROM of the node doing the flash is copied
into the remote node.</P>
<P><B><I>Warning</I></B>: The remote node must perfectly match the node doing the flashing. <I>Never</I> copy a PROM to another node if the other node has a different secondary
cache size or clock speed. The IP27prom <B>flash</B> command does not automatically reconfigure PROMs as the IO6prom and Irix <B>flash</B> commands do.</P>
<OL>
<LI>Get to a POD prompt on the node from which the flash will be done. Try setting
Hardware Debug Switches 4 and 5 to enter memoryless POD mode. Alternately,
use <B>^Tnmi</B> from the MSC alternate console port part way through system initialization.
Either way will result in Dex POD mode.
<LI>Enter cached mode using the <B>go cac</B> command. Flashing should be done from cached mode if possible because it's
deathly slow in Dex mode, plus the route command sometimes has trouble changing
remote nodes' NASIDs when in Dex mode.
<LI>Establish NASIDs and routes for the node(s) to be flashed. If the system
was previously booted past global arbitration, NASIDs may already be assigned.
Check the NASIDs that appear in the POD prompts coming out on the MSC ports
to see if they may have already been assigned; if they are non-zero, route
command(s) may be unnecessary and it may become self-evident which nodes
have which NASIDs assigned.
<P>To establish routes manually, use the <B>route</B> command, which takes a CrayLink vector and a NASID to assign. Any NASID
less than 32 will do. Multiple nodes may be routed at the same time for
convenience. For example, if you're talking to node N1 and wish to flash
N2, N3, and N4 within the same module, the following commands may suffice:</P>
<UL>
<LI>route 0x4 1
<LI>route 0x56 2
<LI>route 0x46 3
</UL>
<P>The <B>route</B> command may sometimes be used without arguments to automatically determine
all nodes present in the system, and assign routes and NASIDs automatically
in one step.</P>
<P>The <B>route</B> command will most likely cause the remote nodes to crash since their NASIDs
are changed out from under them, but this is okay.</P>
<LI>Execute the <B>flash</B> command, specifying the NASID of the node to be flashed. More than one
NASID may be flashed in parallel to save time; for example,
<UL>
<LI>flash 1 2 3
</UL>
<P>After flashing, the system may be rebooted, or additional <B>route</B> and <B>flash</B> commands may be executed.</P>
</OL>
<HR>
<H2><A NAME="PROMLogOverview">PROM Log Overview</A></H2>
<P>The IP27 Flash PROM is an AMD29F080 containing 1 MB of data, organized as
16 pages of 64 KB. The first 14 pages are used for storing the IP27prom
code, and the last 2 pages are used for storing the PROM log. Sectors can
be flashed (erased) independently, so when new code is flashed into the
IP27prom, the last two sectors are left intact, and when the PROM log is
initialized, only the last two sectors are affected.</P>
<P>The PROM Log is used to store three types of data:</P>
<OL>
<LI>PROM environment variables, which consist of a key/value pair of strings.
<LI>PROM environment lists, which consist of multiple value strings stored under
the same key string.
<LI>Error log messages, which can be dumped and viewed from the PROM and get
copied into <I>/var/adm/SYSLOG</I> each time Irix boots.
</OL>
<P>Variables can be set and cleared, and log entries can be added to the first
(primary) sector. Space is used up each time anything is done to the PROM
Log (since data can't be erased except by flashing). When the primary sector
becomes full, the second (alternate) sector is flashed clean and all persistent
data (variables and lists) is compacted and copied into it. The new sector
then becomes the primary sector, and the old sector becomes the alternate
sector. Swapping back and forth in this manner minimizes the chance that
all data will be lost in case of a problem.</P>
<P>The <B>setenv</B>, <B>unsetenv</B>, and <B>printenv</B> POD commands are used to view and modify environment variables stored in
the PROM Log. Variable keys may be up to 15 ASCII characters in length,
and variable values may be up to 127 ASCII characters.</P>
<H3><A NAME="ReservedPROMLogVariables">Reserved PROM Log Variables</A></H3>
<P>Where the value field is numeric, it is generally stored as a decimal number,
or a hex number if prefixed by <I>0x</I>. The word # appears where the data is numeric.</P>
<CENTER><P ALIGN="CENTER"><TABLE BORDER=1>
<CAPTION>Reserved PROM Log Variables</CAPTION>
<TR><TH ALIGN=LEFT>Key</TH><TH ALIGN=LEFT>Value</TH><TH ALIGN=LEFT>Purpose</TH></TR>
<TR><TD>DisableA</TD><TD>reason</TD><TD>CPU A disabled if variable defined. The value is generally a description
of the reason the CPU is disabled.</TD></TR>
<TR><TD>DisableB</TD><TD>reason</TD><TD>CPU B disabled if variable defined. The value is generally a description
of the reason the CPU is disabled.</TD></TR>
<TR><TD>DisableMem</TD><TD>#...</TD><TD>List of memory banks (in the range 0 to 7) to disable.</TD></TR>
<TR><TD>DisableMemSz</TD><TD>########</TD><TD>Positional list of the sizes of all disabled banks, generated automatically
when memory is disabled by POD command.</TD></TR>
<TR><TD>DisableMemMask</TD><TD>#...</TD><TD>List of disabled banks, generated automatically when memory is disabled
by POD command.</TD></TR>
<TR><TD>MemDisReason</TD><TD>reason</TD><TD>String indicating why memory bank(s) were disabled.</TD></TR>
<TR><TD>DisableIO</TD><TD>reason</TD><TD>I/O probing disabled if present. Hub I/O section will not be initialized.</TD></TR>
<TR><TD>SwapBank</TD><TD>#</TD><TD>Alternate bank swapped with bank 0 if bank 0 is bad. Automatically incremented
if bank 0 is found to be bad.</TD></TR>
<TR><TD>OverrideNIC</TD><TD>#</TD><TD>Override Hub NIC, useful if NIC broken (this NIC is not the one used for
software licensing).</TD></TR>
<TR><TD>GlobalMaster</TD><TD>reason</TD><TD>If so, node wants to be global master (if multiple have this, lowest NIC).</TD></TR>
<TR><TD>LastModule</TD><TD>#</TD><TD>Number of the module this node card was last plugged into, updated automatically
(Origin2000 only).</TD></TR>
<TR><TD>Origin200Module</TD><TD>#</TD><TD>Module number for master/slave configuration (Origin200 only).</TD></TR>
<TR><TD>ForceConsole</TD><TD>-</TD><TD>Temporary variable automatically set if no console is found. After automatic
reboot, a default console will be selected.</TD></TR>
<TR><TD>DisableExpress</TD><TD>reason</TD><TD>If this variable is set, express links are disabled on subsequent reboots.
This is mostly useful for benchmarking the effects of express links.</TD></TR>
<TR><TD>NASIDOffset</TD><TD>#</TD><TD>Adds a value to the calculated NASID. May prevent successful booting --
for developer use only.</TD></TR>
<TR><TD>NASID</TD><TD>#</TD><TD>Variable automatically assigned during partitioning. Used to reassign NASID
if one partition is rebooted.</TD></TR>
<TR><TD>FencePorts</TD><TD>#...</TD><TD>List of router ports to fence off. Automatically assigned and used during
partitioning.</TD></TR>
</TABLE></P>
</CENTER><P>By convention, in Log entries the first part of the value should consist
of the date in local time, formatted in ASCII as follows: <I>YY/MM/DD hh:mm:ss</I>. This applies only if the date is available when the entry is made. The
PROM may not have a real-time clock, but the kernel may.</P>
<H3><A NAME="ErrorLogKeys">Error Log Keys</A></H3>
<P>Log entries are to be used very sparingly to avoid filling up the log. Any
given message should generally not be logged more than once per reboot.
Additional message types may be added later.</P>
<P>When the Irix kernel boots, it dumps the contents of the error log since
the last reboot into the <I>/var/adm/SYSLOG</I> file, and sets a marker entry in the log for the next reboot.</P>
<CENTER><P ALIGN="CENTER"><TABLE BORDER=1>
<CAPTION>Error Log Keys</CAPTION>
<TR><TH ALIGN=LEFT>Key</TH><TH ALIGN=LEFT>Value</TH><TH ALIGN=LEFT>Meaning</TH></TR>
<TR><TD>Fatal</TD><TD>string</TD><TD>Fatal error</TD></TR>
<TR><TD>Error</TD><TD>string</TD><TD>Non-fatal error</TD></TR>
<TR><TD>Info</TD><TD>string</TD><TD>Important info message</TD></TR>
</TABLE></P>
</CENTER><H3><A NAME="ListKeys">List Keys</A></H3>
<CENTER><P ALIGN="CENTER"><TABLE BORDER=1>
<CAPTION>List Keys</CAPTION>
<TR><TH ALIGN=LEFT>Key</TH><TH ALIGN=LEFT>Value</TH><TH ALIGN=LEFT>Meaning</TH></TR>
<TR><TD>-</TD><TD>-</TD><TD>There are currently no list keys in use.</TD></TR>
</TABLE></P>
</CENTER><HR>
<H2><A NAME="Origin2000Routers">Origin2000 Routers</A></H2>
<H3><A NAME="ReadingTheRouterLEDs">Reading the Router LEDs</A></H3>
<P><IMG SRC="router_leds.gif" ALIGN="RIGHT" WIDTH="53" HEIGHT="142" SGI_FULLPATH="/tmp_mnt/hosts/ddt/b/csm/ficus/stand/arcs/IP27prom/doc/html/router_leds.gif">Each router card has two side-by-side columns of 6 discreet LEDs.</P>
<P>The left side (green) LEDs indicate the connection status of router ports
1 through 6. They light up if a port has successfully negotiated and maintained
a connection with another device, and turn off if the port is disconnected
(physically or due to severe connection errors). These lights are very useful
for pinpointing a cable or router Field Replaceable Unit (FRU) and should
be one of the first things inspected if link(s) appear to be down. Note that although ports 4 through 6 connections are on the Origin2000 module
midplane, the connection lights are still useful because an improperly seated
card may not connect to the router properly.</P>
<P>The right side (yellow) LEDs are controlled by system software and typically
light up when there is traffic across the corresponding link.<BR CLEAR=ALL>
</P>
<H3><A NAME="VectorAddressing">Vector Addressing</A></H3>
<P>Early in the system boot, before the PROM has configured the CrayLink Interconnect,
Node IDs are not yet assigned (they're all zero) and Router tables are not
yet programmed. In this state, it is not yet valid to access the memory
and I/O spaces of remote nodes using regular remote memory accesses (where
the <A HREF="#NodeIDsNASIDs">Node ID</A> has been placed into physical address bits 40:32, such as by using the <B>n:</B> <A HREF="#PODAddressModifiers">modifier</A>).</P>
<P>The Origin2000 Hub and Routers have a feature called vector addressing which
allows access to the any remote Hub's <A HREF="#HubNIRegs">Network Interface (<I>NI_</I>) register subset</A>, and to all <A HREF="#RouterRegs">Router (<I>RR_</I>) registers</A>. To read or write a remote Hub or Router register requires specifying a
path called a vector. A vector contains a string of output port numbers
from 1 to 6 (corresponding directly to the hardware labeling A through F),
one per nybble, appearing in <EM>reverse</EM> order. For example, the vector 0x512 indicates the request should leave
the current Hub into a Router, leave port 2 of that Router into another
Router, leave port 1 of that Router into another Router, and finally leave
port 5 of that Router into either a Hub or Router, depending on which appears
on that last port. The response automatically follows the reverse path and
arrives back at the local Hub. The vector 0x0 accesses the device immediately
connected to the local Hub, which is usually a Router but may be a Hub if
a Null Router is being used.</P>
<P>POD contains several commands for performing vector operations, among them
vector read (<B>vr</B>) and vector write (<B>vw</B>). Here are several examples:</P>
<OL>
<LI><TT>vr 0 0</TT>
<P>Reads address 0 from the device immediately connected to the local Hub.
Address 0 is the NI_STATUS_REV_ID on a Hub, and RR_STATUS_REV_ID on a Router.
The status register was deliberately placed at address 0 on both Hubs and
Routers, and contains a bit field that can be used to tell which type is
connected.</P>
<LI><TT>vr 1 rr_scratch_reg0</TT>
<P>Goes out the Hub into the connected Router, out port 1 of that Router to
another Router, and reads one of that Router's scratch registers.</P>
<LI><TT>vw 0x512 ni_port_reset 0x80</TT>
<P>Goes through a string of 3 Routers to reach a Hub and writes 0x80 (warm
reset code) into that hub's NI_PORT_RESET register.</P>
<LI><TT>loop vr 0 0</TT>
<P>Loops repeatedly reading the status register of the immediately connected
device. May be useful for getting a rough idea of the link quality since
the number of polling iterations for each read is printed (if this number
is not constant or is very high, the link may be performing excessive retries).</P>
</OL>
<H3><A NAME="SystemConfigurations">System Configurations</A></H3>
<H4><A NAME="FullRouterConfiguration">Full Router Configuration</A></H4>
<CENTER><P ALIGN="CENTER"><IMG SRC="full_router.gif" WIDTH="525" HEIGHT="264" SGI_FULLPATH="/tmp_mnt/hosts/ddt/b/csm/ficus/stand/arcs/IP27prom/doc/html/full_router.gif"></P>
</CENTER><CENTER><H5 ALIGN="CENTER">Fully-Populated Origin2000 Module Connectivity</H5>
</CENTER><P>Consider the example CrayLink Interconnect configuration shown in the figure
above, which is a typical fully-populated single-module system having two
Routers (slots R1-R2) and four node cards (slots N1-N4). The five links
shown are permanent and internal to the system mid-plane, and nothing is
connected to either Router's external cable ports (1, 2, and 3). Any source
node can talk to any destination node or router using vectors shown in the
following table.</P>
<CENTER><P ALIGN="CENTER"><TABLE BORDER=1>
<CAPTION>Vector Routes</CAPTION>
<TR><TH></TH><TH COLSPAN=6> Destination </TH></TR>
<TR><TH> Source </TH><TH> N1 </TH><TH> N2 </TH><TH> N3 </TH><TH> N4 </TH><TH> R1 </TH><TH> R2 </TH></TR>
<TR><TH> N1 </TH><TD ALIGN=CENTER> 5 </TD><TD ALIGN=CENTER> 4 </TD><TD ALIGN=CENTER> 0x56 </TD><TD ALIGN=CENTER> 0x46 </TD><TD ALIGN=CENTER> 0 </TD><TD ALIGN=CENTER> 6 </TD></TR>
<TR><TH> N2 </TH><TD ALIGN=CENTER> 5 </TD><TD ALIGN=CENTER> 4 </TD><TD ALIGN=CENTER> 0x56 </TD><TD ALIGN=CENTER> 0x46 </TD><TD ALIGN=CENTER> 0 </TD><TD ALIGN=CENTER> 6 </TD></TR>
<TR><TH> N3 </TH><TD ALIGN=CENTER> 0x56 </TD><TD ALIGN=CENTER> 0x46 </TD><TD ALIGN=CENTER> 5 </TD><TD ALIGN=CENTER> 4 </TD><TD ALIGN=CENTER> 6 </TD><TD ALIGN=CENTER> 0 </TD></TR>
<TR><TH> N4 </TH><TD ALIGN=CENTER> 0x56 </TD><TD ALIGN=CENTER> 0x46 </TD><TD ALIGN=CENTER> 5 </TD><TD ALIGN=CENTER> 4 </TD><TD ALIGN=CENTER> 6 </TD><TD ALIGN=CENTER> 0 </TD></TR>
</TABLE></P>
</CENTER><H4><A NAME="FirstStarRouterConfiguration">Star Router Configuration (First Possibility)</A></H4>
<CENTER><P ALIGN="CENTER"><IMG SRC="star_router1.gif" WIDTH="523" HEIGHT="289" SGI_SETWIDTH SGI_SETHEIGHT SGI_FULLPATH="/tmp_mnt/hosts/ddt/b/csm/ficus/stand/arcs/IP27prom/doc/html/star_router1.gif"></P>
</CENTER><CENTER><H5 ALIGN="CENTER">Fully-Populated Star Router Connectivity (First Possibility)</H5>
</CENTER><P>A Star Router configurations is another way of populating an Origin2000
module. The figure above shows the connectivity of a fully populated Star
Router configuration with the Router in slot 1 and the Star Router in slot
2. It is also possible to place the Star Router in slot 1 and the Router
in slot 2 (see next configuration).</P>
<P>The midplane connection from R1 port 6 is internal to the system and connects
directly to N3. The connection from R1 port 3 is provided by an external
jumper (or cable) connecting to SR2, and is converted from differential
to single-ended by the XC chip in the Star Router. The remaining ports on
R1 (1 and 2) may be connected externally.</P>
<P>This configuration offers two advantages:</P>
<UL>
<LI>One of the router cards is replaced by a slightly less expensive Star Router
card.
<LI>Interconnect latency is at most one hop for all messages within the module.
</UL>
<P>The disadvantage is limited scalability.</P>
<P>Any source node can talk to any destination node (or R1) using vectors shown
in the table below.</P>
<CENTER><P ALIGN="CENTER"><TABLE BORDER=1>
<CAPTION>Vector Routes</CAPTION>
<TR><TH></TH><TH COLSPAN=5> Destination </TH></TR>
<TR><TH> Source </TH><TH> N1 </TH><TH> N2 </TH><TH> N3 </TH><TH> N4 </TH><TH> R1 </TH></TR>
<TR><TH> N1 </TH><TD ALIGN=CENTER> 5 </TD><TD ALIGN=CENTER> 4 </TD><TD ALIGN=CENTER> 6 </TD><TD ALIGN=CENTER> 3 </TD><TD ALIGN=CENTER> 0 </TD></TR>
<TR><TH> N2 </TH><TD ALIGN=CENTER> 5 </TD><TD ALIGN=CENTER> 4 </TD><TD ALIGN=CENTER> 6 </TD><TD ALIGN=CENTER> 3 </TD><TD ALIGN=CENTER> 0 </TD></TR>
<TR><TH> N3 </TH><TD ALIGN=CENTER> 5 </TD><TD ALIGN=CENTER> 4 </TD><TD ALIGN=CENTER> 6 </TD><TD ALIGN=CENTER> 3 </TD><TD ALIGN=CENTER> 0 </TD></TR>
<TR><TH> N4 </TH><TD ALIGN=CENTER> 5 </TD><TD ALIGN=CENTER> 4 </TD><TD ALIGN=CENTER> 6 </TD><TD ALIGN=CENTER> 3 </TD><TD ALIGN=CENTER> 0 </TD></TR>
</TABLE></P>
</CENTER><H4><A NAME="SecondStarRouterConfiguration">Star Router Configuration (Second Possibility)</A></H4>
<CENTER><P ALIGN="CENTER"><IMG SRC="star_router2.gif" WIDTH="525" HEIGHT="291" SGI_SETWIDTH SGI_SETHEIGHT SGI_FULLPATH="/tmp_mnt/hosts/ddt/b/csm/ficus/stand/arcs/IP27prom/doc/html/star_router2.gif"></P>
</CENTER><CENTER><H5 ALIGN="CENTER">Fully-Populated Star Router Connectivity (Second Possibility)</H5>
</CENTER><P>The second Star Router configuration has the Router in slot 2 and the Star
Router in slot 1. See the previous configuration for more details on the
Star Router configurations.</P>
<P>Any source node can talk to any destination node (or R2) using vectors shown
in the table below.</P>
<CENTER><P ALIGN="CENTER"><TABLE BORDER=1>
<CAPTION>Vector Routes</CAPTION>
<TR><TH></TH><TH COLSPAN=5> Destination </TH></TR>
<TR><TH> Source </TH><TH> N1 </TH><TH> N2 </TH><TH> N3 </TH><TH> N4 </TH><TH> R2 </TH></TR>
<TR><TH> N1 </TH><TD ALIGN=CENTER> 6 </TD><TD ALIGN=CENTER> 3 </TD><TD ALIGN=CENTER> 5 </TD><TD ALIGN=CENTER> 4 </TD><TD ALIGN=CENTER> 0 </TD></TR>
<TR><TH> N2 </TH><TD ALIGN=CENTER> 6 </TD><TD ALIGN=CENTER> 3 </TD><TD ALIGN=CENTER> 5 </TD><TD ALIGN=CENTER> 4 </TD><TD ALIGN=CENTER> 0 </TD></TR>
<TR><TH> N3 </TH><TD ALIGN=CENTER> 6 </TD><TD ALIGN=CENTER> 3 </TD><TD ALIGN=CENTER> 5 </TD><TD ALIGN=CENTER> 4 </TD><TD ALIGN=CENTER> 0 </TD></TR>
<TR><TH> N4 </TH><TD ALIGN=CENTER> 6 </TD><TD ALIGN=CENTER> 3 </TD><TD ALIGN=CENTER> 5 </TD><TD ALIGN=CENTER> 4 </TD><TD ALIGN=CENTER> 0 </TD></TR>
</TABLE></P>
</CENTER><H4><A NAME="NullRouterConfiguration">Null Router Configuration</A></H4>
<CENTER><P ALIGN="CENTER"><IMG SRC="null_router.gif" WIDTH="525" HEIGHT="246" SGI_FULLPATH="/tmp_mnt/hosts/ddt/b/csm/ficus/stand/arcs/IP27prom/doc/html/null_router.gif"></P>
</CENTER><CENTER><H4 ALIGN="CENTER">Null Router Connectivity (Two Possibilities)</H4>
</CENTER><P>The Null Router configuration is the simplest way to create a 4-CPU system.
The figure above shows the two possible connectivities of a module using
the Null Router configuration.</P>
<P>In this configuration, only one inexpensive Null Router card is needed.
Null Routers contain very little componentry and simply connect two Hub
slots together. The system is not at all scalable, and may be only half-populated
(populating both halves as two separate systems is not supported).</P>
<P>Either node may talk to the other using the vector 0. No other vector routes
are possible.</P>
<HR>
<CENTER><P ALIGN="CENTER"><IMG SRC="cheeser.gif" ALIGN="MIDDLE" WIDTH="100" HEIGHT="100" SGI_SETWIDTH SGI_SETHEIGHT SGI_FULLPATH="/tmp_mnt/hosts/ddt/b/csm/ficus/stand/arcs/IP27prom/doc/html/cheeser.gif"><BLINK>*</BLINK><IMG SRC="cheeser.gif" ALIGN="MIDDLE" WIDTH="100" HEIGHT="100" SGI_FULLPATH="/tmp_mnt/hosts/ddt/b/csm/ficus/stand/arcs/IP27prom/doc/html/cheeser.gif"><BLINK>*</BLINK><IMG SRC="cheeser.gif" ALIGN="MIDDLE" WIDTH="100" HEIGHT="100" SGI_FULLPATH="/tmp_mnt/hosts/ddt/b/csm/ficus/stand/arcs/IP27prom/doc/html/cheeser.gif"><BLINK>*</BLINK><IMG SRC="cheeser.gif" ALIGN="MIDDLE" WIDTH="100" HEIGHT="100" SGI_FULLPATH="/tmp_mnt/hosts/ddt/b/csm/ficus/stand/arcs/IP27prom/doc/html/cheeser.gif"><BLINK>*</BLINK><IMG SRC="cheeser.gif" ALIGN="MIDDLE" WIDTH="100" HEIGHT="100" SGI_FULLPATH="/tmp_mnt/hosts/ddt/b/csm/ficus/stand/arcs/IP27prom/doc/html/cheeser.gif"></P>
</CENTER><CENTER><P ALIGN="CENTER">&quot;I give this document 5 cheeses, my highest rating.&quot;-Cheeser, <I>The Dairy News.</I></P>
</CENTER><HR>
</BODY>
</HTML>
View Git Blame Copy Permalink