1. Introduction
    1.1. Project/Component Working Name:
        Sun4v VBSC to POST interface

    1.2. Name of Document Author/Supplier:
        Eric.Blanchard@sun.com        

    1.3. Date of This Document:
        10/3/07

    1.4. Name of Major Document Customer(s)/Consumer(s):
        1.4.1. The Product Approval Committees you expect to review your project
                HS PAC
        1.4.2. The ARC(s) you expect to review your project
                FWARC
        1.4.3. The Director/VP who is "Sponsoring" this project
                N/A
        1.4.4. The name of your business unit
                SG

    1.5. Email Aliases:
        1.5.1. Responsible Manager:
                chad.solomon@sun.com
        1.5.2. Responsible Engineer:
                eric.blanchard@sun.com            

2. Project Summary
    2.1. Project Description
        This case describes the interfaces between the VBSC
        and POST for Sun4v platforms.

    2.2. Risks and Assumptions
        This requires some flag day changes between post and vbsc on
        Huron and Marmaba.

3. Business Summary
   3.1. Problem Area

    The interfaces originally approved for communication between vbsc to post on
    sun4v platforms were not sufficient to communicate all the necessary information
    between the two consolidations.

4. Technical Description

   4.1 Purpose: This case is designed to replace the existing VBSC to POST interface
       specification for Huron, and to extend the interface to Maramba. The old VBSC
       to POST interfaces which this case deprecates are described in [2], [3], [4],
       and [5]. This case only obsoletes those interfaces for Niagara2 and VF platforms;
       there is no intention of back-porting these changes to Niagara1 based systems.

   4.2 Background:

        One function of the VBSC software is to compile a list of machine
        information and pass this information to POST so that POST knows what
        hardware it should be running it's diagnostics on. Once POST has
        completed, POST must pass back a list of failed devices so that VBSC
        can take the appropriate course of action. This document specifies the
	interface used by VBSC and POST to communicate information.
      
   4.3 VBSC to POST interface
        The new VBSC to POST interface is defined in [1]. This document includes all of the
        platform generic specifications of the interface such as the definitions of
        values that are used on all platforms that use this interface. The end of the document
        contains platform specific extensions to the generic interface, and must be updated
        for each platform that chooses to extend the platform generic interface.

        Upon approval of this new interface FWARC 2006/588, FWARC 2007/108,
        FWARC 2006/687, FWARC 2007/180, section 4.1.2 of FWARC/2007/494 and 
	section 4.1.2 of FWARC/2007/526 will not no longer be valid.
              
    4.4. Interfaces:

        Exported Interfaces :

        POST interface data     Obsolete        POST data format for Niagara2 and
        format                  uncommitted     VF systems as described and
                                                updated by FWARC 2006/588, 
                                                FWARC 2007/108 FWARC 2006/687, 
                                                FWARC 2007/180, section 4.1.2 of 
                                                FWARC/2007/494 and section 4.1.2 
                                                of FWARC/2007/526

       Usage of %o7 to hold      uncommitted    register usage as described in [1]
       POST return address            

       Usage of %g1 to hold      uncommitted    register usage as described in [1]
       POST interface data            

       POST Entry data           uncommitted   SRAM bit array elements setup by VBSC
       elements                                and consumed by POST, section 2.1

       POST Exit data            uncommitted   SRAM bit array elements setup by POST
       elements                                and consumed by VBSC, section 2.2

       Huron SRAM data layout    uncommitted   SRAM data layout consisting of Entry 
                                               and Exit data elements, section 3

       Glendale SRAM data layout uncommitted   SRAM data layout consisting of Entry 
                                               and Exit data elements, section 4

       Monza SRAM data layout    uncommitted   SRAM data layout consisting of Entry 
                                               and Exit data elements, section 5

       Turgo SRAM data layout    uncommitted   SRAM data layout consisting of Entry 
                                               and Exit data elements, section 6

       Maramba SRAM data layout  uncommitted   SRAM data layout consisting of Entry 
                                               and Exit data elements, section 7

       Batoka SRAM data layout   uncommitted   SRAM data layout consisting of Entry 
                                               and Exit data elements, section 8

5. Reference Documents
    [1] Genaric Sun4v POST to VBSC Specification

            sun4v_vbsc_post_interface.txt

        [2] FWARC 2006/588 VBSc to POST interface

            http://sac.eng/Archives/CaseLog/arc/FWARC/2006/588/

        [3] FWARC 2006/678 Huron VBSC to POST Interface Extension

            http://sac.eng/Archives/CaseLog/arc/FWARC/2006/678/

        [4] FWARC 2007/108 Huron VBSC to POST Interface Extension

            http://sac.eng/Archives/CaseLog/arc/FWARC/2007/108/

        [5] FWARC 2007/180 Huron VBSC to POST Interface Extension (x8_bank_mode)

            http://sac.eng/Archives/CaseLog/arc/FWARC/2007/180/