Document Audience:INTERNAL
Document ID:I0849-1
Title:New capability is available on E10000 systems to identify MSRAM modules from POST output.
Copyright Notice:Copyright © 2005 Sun Microsystems, Inc. All Rights Reserved
Update Date:2002-10-24

---------------------------------------------------------
          - Sun Proprietary/Confidential: Internal Use Only -
---------------------------------------------------------------------  
                        FIELD INFORMATION NOTICE
              (For Authorized Distribution by SunService)
FIN #: I0849-1
Synopsis: New capability is available on E10000 systems to identify MSRAM modules from POST output.
Create Date: Oct/22/02
SunAlert: No
Top FIN/FCO Report: No
Products Reference: Mirrored SRAM CPU modules
Product Category: Server / Service
Product Affected: 
Systems Affected:
-----------------  
Mkt_ID    Platform   Model   Description              Serial Number
------    --------   -----   -----------              -------------
  -        E10000     ALL    Ultra Enterprise 10000         -


X-Options Affected:
-------------------
Mkt_ID   Platform   Model   Description   Serial Number
------   --------   -----   -----------   -------------
  -         -         -          -              -
Parts Affected: 
Part Number   Description   Model
-----------   -----------   -----
     -             -          -
References: 
BugId: 4401066 - Need to identify mirrored SRAM CPU modules after 
                 bringup/DR.
       4419788 - MSRAM processor property for Starfire.

PatchId: ssp3.4	110304-06: SSP 3.4: Updates for hpost, redx, and autoconfig.
                110316-04: SSP 3.4: OBP patch.
Issue Description: 
Mirrored SRAM CPU modules (IBM Sombra and Sony Espejo) are being
installed as upgrades in existing E10000 systems.  In some cases, these
are installed alongside older CPU modules.  The Field needs to be able
to determine if a Mirrored SRAM (MSRAM) module is installed in a
particular CPU location in order to more effectively service faulty CPU
modules.  This issue does not directly impact customer systems but does
affect serviceability.

RFE 4401066 requested that field personnel be given a way to probe the
E10000 and decipher which CPU modules have MSRAM.  New HPOST patches
for SSP3.4  software provide this capability.  A patch for SSP3.5 is
pending.  It is expected that these patches will enable field personnel
to more easily diagnose and resolve CPU Ecache issues on E10000
systems.  

           SSP3.4  110304-06
                      
Without these recommended patches, there is a high risk that an
incorrect CPU module could be sent to a customer site or that
inappropriate Best Practices actions could take place, i.e., no
replacement on first Ecache parity error, even though the CPU in error
has Mirrored SRAM.  The Best Practice for MSRAM CPU modules is to
replace them on the first error and submit them for RCCA/CPAS.  

Once these patches are installed, POST output will change as follows:

1)  In phase proc1, POST will try to acquire the Module Capability (MCAP) 
    value from the UPA_CONFIG register of the CPU.  (This value was 
    previously unused for Sunfire E6000 and Starfire E10000 processor 
    modules).  For currently shipped processor modules, the MCAP bits have 
    now been hard wired to signify the following assignments:

MCAP    MCAP   MIRRORED ECACHE?
BINARY  HEX  DATA SRAMS  TAG SRAMS  COMMENTS ON PROCESSOR MODULE & ECACHE
==============================================================================
b'0000  0x0  unknown     unknown    Cannot determine anything with MCAP = 0
b'0001  0x1  YES         YES        466mhz "Blaze" with IBM (Sombra) MSRAMs
b'0010  0x2  YES         YES        466mhz "Blaze" with Sony (Espejo) MSRAMs
b'0011  0x3  YES         NO         400mhz "Sapphire" with IBM (Sombra) MSRAMs
b'0100  0x4  YES         NO         400mhz "Sapphire" with Sony (Espejo) MSRAMs
==============================================================================

In addition, bits 4, 5, and 6 of the post2obp processor auxiliary, the 
fields are now used as follows:
      
      6:  Ecache TAG SRAM is mirrored  (1 = YES, 0 = NO)
      5:  Ecache DATA SRAMs are mirrored  (1 = YES, 0 = NO)
      4:  Ecache SRAMs mirrored info is valid (1 = YES, 0 = NO)
      
After obtaining the MCAP value in phase proc1m the MCAP value will be
checked.  For older legacy processor modules, the value will be "0",
indicating that the type of ecache is unknown in regards to mirrored
or not.  If the MCAP value is non-zero, POST will check to see if it is
a known value.  If the non-zero MCAP value is unknown, then WARN on
that unknown non-zero value and message that nothing could be
determined by it, but do not FAIL the proc.   

An example unknown MCAP value WARNING message will appear as follows:

WARNING: Proc 0.3: Unknown MCAP value: 0x5
        Cannot check post2obp proc aux info with unknown MCAP value.

   In the above case, the mirrored status information was detected to
   be valid because it was written in during phase jtag_integ(see item 
   #4).  But since the MCAP value is unknown, the mirrored status information 
   could not be cross checked.  The WARNING will be issued, but HPOST will
   continue without failing the processor with the unknown MCAP value.

   Another example WARNING is as follows:

WARNING: Proc 0.3: Unknown MCAP value: 0x5
        Cannot set post2obp proc aux info with unknown MCAP value.

   In this case, the mirrored status information in the post2obp processor
   auxiliary structure was not valid, perhaps because phase jtag_integrity
   (see item #4) was skipped.  A subsequent detection of an unknown MCAP 
   value results in a message that the post2obp processor auxiliary 
   information could not be SET based solely on the unknown MCAP value.  
   Again, HPOST will continue with only the WARNING message and the proc 
   will not be failed.
        
2) A new postrc directive has been added for extra messaging during the 
   ecache SRAM probe:

   A user could make the following entry in the postrc to allow more
   messaging during HPOST, regarding probing of the ecache SRAMs for
   their mirrored status:

   debug_maskx00001000  # Extra messaging proc ecache SRAM mirrored status.

   Note that some of the new messaging requires HPOST verbosity to be
   at level 120 as well as having the new postrc entry above.        
 
3) The postyymmdd.time.log file format has changed.  The detected processor 
   ecache SRAM status is now printed at the end of the POST log file.  
   
   At the end of every POST log file, the post2obp auxiliary info structure
   will now be included, with each new line beginning with: "#E".  The
   following is a real example of the new post2obp information being included
   at the end of the new POST log file:
   
   --------------------EXAMPLE postyymmdd.time.log: 
START------------------------
   <...snip...>
   phase final_config: Final configuration...
   Configuring in 3F, FOM = 92160.00: 10 procs, 8 Scards, 9216 MBytes.
   Creating OBP handoff structures...
   Configured in 3F with 10 processors, 8 Scards, 9216 MBytes memory.
   Interconnect       frequency is  83.241 MHz, from SNMP MIB.
   Processor external frequency is 124.878 MHz, from SNMP MIB.
   Processor internal frequency is 249.724 MHz, from proc clk_mode probe.
   NOTE: 2 processors were detected running at least 9.00% below rated speed.
         Check system clock values/ratios using the SSP command sys_clock
   Boot processor is 3.0 = 12
   POST (level=16, verbose=20) execution time 6:53
   #E Auxiliary Info structures:
   #E brd: cpu3 cpu2 cpu1 cpu0 MCAP  ioc1 ioc0  iom type
   #E  3:  0013 0013 0013 0013 0000  0000 0000  01: 2 * (SYSIO w/ 2 SBus slots)
   #E  4:  0013 0013 0013 0013 0000  0000 0000  01: 2 * (SYSIO w/ 2 SBus slots)
   #E  5:  0074 0074 0004 0004 11    0000 0000  01: 2 * (SYSIO w/ 2 SBus slots)
   # SMI E10000 POST log closed Wed Mar 20 06:58:46 2002
   --------------------EXAMPLE postyymmdd.time.log: 
END--------------------------
      
   Breaking down an example line;
   
   #E brd: cpu3 cpu2 cpu1 cpu0 MCAP  ioc1 ioc0  iom type
   #E  5:  0074 0074 0004 0004 11    0000 0000  01: 2 * (SYSIO w/ 2 SBus slots)   		
   CODE       XXAB XXCD XXEF XXGH IJKL  XXXX XXXX
  
   (NOTE: "CODE" is just for FIN explanation.  It won't be in the POST log)

   CODE KEY:

     A.  For brd-5, cpu3, we have a "7" in that field (all 3 bits set),
	 indicating the processor module has mirrored data and mirrored
	 tag SRAMs, and that information is "valid".
	 
     B.  Ecache Setting, outside the scope of this FIN
     
     C.  For brd-5, cpu2, we have a "7" in that field (bits [4,5,6] are set),
	 indicating the processor module has mirrored data and mirrored
	 tag SRAMs, and that information is "valid".
	 
     D.  Ecache Setting, outside the scope of this FIN		     	

     E.  For brd-5, cpu3, we have a 0" in that field (0 bits set).  See
     	 note for K
	 
     F.  Ecache Setting, outside the scope of this FIN
     
     G.  For brd-5, cpu3, we have a 0" in that field (0 bits set).  See
     	 note for L
	 
     H.  Ecache Setting, outside the scope of this FIN
     
     I.  MCAP value = "1"; Proc identified as a 466mhz "Blaze" with IBM 
         (sombra) MSRAMs.  (see table above)
     
     J.  MCAP value = "1"; Proc identified as a 466mhz "Blaze" with IBM 
         (sombra) MSRAMs.  (see table above)
     
     K.  MCAP is blank.  The proc is not present or the phase jtag_integ was 
         skipped AND the proc was FAILED before its MCAP value could be  
        dechipered in phase proc1.
     
     L.  MCAP is blank.  The proc is not present or the phase jtag_integ was 
         skipped AND the proc was FAILED before its MCAP value could be 
         deciphered in phase proc1.
		 	     			     	  
  So for system board three, we can't identify which type of procs they
  are, but they are not mirrored SRAMs or mirrored TAGs, as the data is
  valid.
  
Some other items to note, necessary for the explanation above, but do not 
directly affect the field:
   
4) A result of this patch, phase jtag_integ now:
      
   . Checks the JTAG (scantool) database on the SSP, to see if special
     MSRAM handling is required for both the ecache data AND now tag SRAMs.

   . If the JTAG (scantool) database on the SSP doesn't show that special
     MSRAM handling is required for a given processor, cautiously do an
     electronic JTAG probe of that processor's ecache SRAM's Component IDs
     to be sure.  This is just in case the database was incorrect because
     autoconfig was never run for a given system board, and that system
     board may have processor modules that have MSRAMs that require special
     handling.  If so, fail the system board and instruct user to run 
     autoconfig.

   . Checks all other processor e-cache tag and data SRAMs in the domain, to
     see if they are mirrored or not.

   . Records the ecache data and ecache tag status for each processor, into
     the post2obp auxiliary info structure, and mark the info as "valid".
      
5) For hpost -Q arg: Make sure that extracted post2obp mirrored status
   information is not misleading statement.
Implementation: 
---
        |   |   MANDATORY (Fully Proactive)
         ---    
         
  
         ---
        |   |   CONTROLLED PROACTIVE (per Sun Geo Plan) 
         --- 
         
                                
         ---
        | X |   REACTIVE (As Required)
         ---
Corrective Action: 
The following recommendation is provided as a guideline for authorized
Sun Services Field Representatives who may encounter the above
mentioned problem.

Install the following patches on E10000 systems for the complete solution:

   SSP3.4: Patches 110316-04, 110304-06 or later
Comments: 
None  

============================================================================
Implementation Footnote: 
i)   In case of MANDATORY FINs, Enterprise Services will attempt to    
     contact all affected customers to recommend implementation of 
     the FIN. 
   
ii)  For CONTROLLED PROACTIVE FINs, Enterprise Services mission critical    
     support teams will recommend implementation of the FIN  (to their  
     respective accounts), at the convenience of the customer. 

iii) For REACTIVE FINs, Enterprise Services will implement the FIN as the   
     need arises.
----------------------------------------------------------------------------
All released FINs and FCOs can be accessed using your favorite network 
browser as follows:
 
SunWeb Access:
-------------- 
* Access the top level URL of http://sdpsweb.ebay/FIN_FCO/

* From there, select the appropriate link to query or browse the FIN and
  FCO Homepage collections.
 
SunSolve Online Access:
-----------------------
* Access the SunSolve Online URL at http://sunsolve.Corp/

* From there, select the appropriate link to browse the FIN or FCO index.

Internet Access:
----------------
* Access the top level URL of https://infoserver.Sun.COM
--------------------------------------------------------------------------
General:
--------
* Send questions or comments to finfco-manager@sdpsweb.EBay
--------------------------------------------------------------------------
Statusactive