From sacadmin Thu Oct 18 08:23:37 2007 Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9IFNbc9015024; Thu, 18 Oct 2007 08:23:37 -0700 (PDT) Received: (from ehring@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id l9IFNbqW015020; Thu, 18 Oct 2007 08:23:37 -0700 (PDT) Date: Thu, 18 Oct 2007 08:23:37 -0700 (PDT) From: Stephen Ehring Message-Id: <200710181523.l9IFNbqW015020@sac.sfbay.sun.com> To: FWARC-record@sac.sfbay.sun.com Subject: Sun4v VBSC to POST interface [FWARC/2007/605 FastTrack timeout 10/25/2007] Status: RO Content-Length: 571 Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Sun4v VBSC to POST interface 1.2. Name of Document Author/Supplier: Author: Eric Blanchard 1.3 Date of This Document: 18 October, 2007 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: unknown 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From sacadmin Thu Oct 18 08:31:32 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9IFVVqb015205 for ; Thu, 18 Oct 2007 08:31:31 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9IFS6sC020349 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Thu, 18 Oct 2007 23:28:07 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ400F1V5MT8100@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 18 Oct 2007 09:28:05 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ400CXB5MQS020@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 18 Oct 2007 09:28:02 -0600 (MDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9IFS22f029380 for ; Thu, 18 Oct 2007 15:28:02 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ400J01597QO00@mail-amer.sun.com> (original mail from Stephen.Ehring@Sun.COM) for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 18 Oct 2007 09:28:02 -0600 (MDT) Received: from [129.148.131.33] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ400DBM5MOF440@mail-amer.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 18 Oct 2007 09:28:00 -0600 (MDT) Date: Thu, 18 Oct 2007 11:27:59 -0400 From: Stephen Ehring Subject: FWARC 2007/605 Sun4v VBSC to POST interface Sender: Stephen.Ehring@sun.com To: Firmware Arch Message-id: <47177B7F.20803@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.7pre (X11/20071014) Status: RO Content-Length: 5556 I'm sponsoring this case for Eric Blanchard. The case describes the interface that VBSC and POST use to pass information between the two consolidations. The case is intended to replace the previous cases, which were deemed insufficient and do not represent what was implemented, anyway. The interfaces can be released in a micro/minor version of the firmware and will constitute a flag day between POST and VBSC Steve http://sac.eng.sun.com/Archives/CaseLog/arc/FWARC/2007/605/onepager.txt 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]. 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. VBSC and POST run on two different processors with separate memory spaces. VBSC runs on the service processor and POST runs on the host processor (N2, VF, ect...). The Service processor and the Host processor share information by reading and writing an area of shared memory residing in the fpga. Before POST runs, VBSC sets up the POST interface structure in the memory of the FPGA and enters all of the required values of the POST entry Info. The POST entry Info includes a list of the machine information, communication channel information, and POST runtime options. When POST starts, POST extracts the POST entry Info from the POST interface structure and configures its self accordingly. After POST finishes, it enters all of the required values of the POST Return Info into the POST interface structure. The POST Return Info includes the results from the tests that POST ran and the POST Exit Reason. VBSC extracts the POST Return Info from the POST interface structure and takes the appropriate action. 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 will no longer be valid. 4.4. Interfaces: Exported Interfaces : Machine state before uncommitted Machine state as described in [1] and after POST 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 interface uncommitted Data format as described in [1] structure data format 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/ From sacadmin Thu Oct 18 13:22:04 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9IKM48i023819 for ; Thu, 18 Oct 2007 13:22:04 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9IKIe1O058660 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Thu, 18 Oct 2007 14:18:40 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ400I4XJ34QQ00@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@Sun.COM); Thu, 18 Oct 2007 13:18:40 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ400EAFJ30NF80@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@Sun.COM); Thu, 18 Oct 2007 13:18:36 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9IKIagZ020522 for ; Thu, 18 Oct 2007 20:18:36 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ400A01HY6CF00@mail-amer.sun.com> (original mail from S.Jain@Sun.COM) for fwarc@Sun.COM (ORCPT fwarc@Sun.COM); Thu, 18 Oct 2007 14:18:35 -0600 (MDT) Received: from [129.145.155.9] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ4006YTJ2JJH10@mail-amer.sun.com> for fwarc@Sun.COM (ORCPT fwarc@Sun.COM); Thu, 18 Oct 2007 14:18:20 -0600 (MDT) Date: Thu, 18 Oct 2007 13:18:19 -0700 From: S.Jain@Sun.COM Subject: Re: FWARC 2007/605 Sun4v VBSC to POST interface In-reply-to: <47177B7F.20803@sun.com> Sender: S.Jain@Sun.COM To: Stephen Ehring Cc: Firmware Arch Message-id: <4717BF8B.9030906@Sun.COM> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_eiVQzPuLRD4WCGuSEvS48g)" X-PMX-Version: 5.2.0.264296 References: <47177B7F.20803@sun.com> User-Agent: Thunderbird 2.0.0.7pre (X11/20071014) Status: RO Content-Length: 23441 This is a multi-part message in MIME format. --Boundary_(ID_eiVQzPuLRD4WCGuSEvS48g) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Some platforms like Glendale and Monza had extended Huron defined VBSC-POST interface to suit that platform. Pls see -- FWARC/2007/526 for monza platform binding FWARC/2007/494 for glendale platform binding Do these need to change? Regards, Sunit Stephen Ehring wrote: > I'm sponsoring this case for Eric Blanchard. The case describes the > interface that VBSC and POST use to pass information between the two > consolidations. The case is intended to replace the previous cases, > which were deemed insufficient and do not represent what was > implemented, anyway. The interfaces can be released in a micro/minor > version of the firmware and will constitute a flag day between POST > and VBSC > > Steve > > http://sac.eng.sun.com/Archives/CaseLog/arc/FWARC/2007/605/onepager.txt > > 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]. > > 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. > > VBSC and POST run on two different processors with separate > memory spaces. > VBSC runs on the service processor and POST runs on the host > processor > (N2, VF, ect...). The Service processor and the Host processor > share > information by reading and writing an area of shared memory > residing in the fpga. > > Before POST runs, VBSC sets up the POST interface structure in > the memory of > the FPGA and enters all of the required values of the POST > entry Info. The > POST entry Info includes a list of the machine information, > communication > channel information, and POST runtime options. When POST > starts, POST extracts > the POST entry Info from the POST interface structure and > configures its self > accordingly. After POST finishes, it enters all of the required > values of the > POST Return Info into the POST interface structure. The POST > Return Info > includes the results from the tests that POST ran and the POST > Exit Reason. > VBSC extracts the POST Return Info from the POST interface > structure and > takes the appropriate action. > > 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 will no longer be valid. > 4.4. Interfaces: > > Exported Interfaces : > > Machine state before uncommitted Machine state as > described in [1] > and after POST > 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 interface uncommitted Data format as > described in [1] > structure data format > 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/ > > > -- Sunit Jain Sun Microsystems, Inc. 4110 Nework Circle, Mailstop USCA11-206, Santa Clara, CA 95054 --Boundary_(ID_eiVQzPuLRD4WCGuSEvS48g) Content-type: multipart/related; boundary="Boundary_(ID_UpVDoDZ2qyj+ypJO6fPHGg)" --Boundary_(ID_UpVDoDZ2qyj+ypJO6fPHGg) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT
Some platforms like Glendale and Monza had extended Huron defined VBSC-POST interface to suit that platform. Pls see --

FWARC/2007/526 for monza platform binding
FWARC/2007/494 for glendale platform binding

Do these need to change?

Regards,
Sunit


Stephen Ehring wrote:
I'm sponsoring this case for Eric Blanchard. The case describes the interface that VBSC and POST use to pass information between the two consolidations. The case is intended to replace the previous cases, which were deemed insufficient and do not represent what was implemented, anyway. The interfaces can be released in a micro/minor version of the firmware and will constitute a flag day between POST and VBSC

Steve

http://sac.eng.sun.com/Archives/CaseLog/arc/FWARC/2007/605/onepager.txt

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].

  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.

       VBSC and POST run on two different processors with separate memory spaces.
       VBSC runs on the service processor and POST runs on the host processor
       (N2, VF, ect...). The Service processor and the Host processor share
       information by reading and writing an area of shared memory
       residing in the fpga.

       Before POST runs, VBSC sets up the POST interface structure in the memory of
       the FPGA and enters all of the required values of the POST entry Info. The
       POST entry Info includes a list of the machine information, communication
       channel information, and POST runtime options. When POST starts, POST extracts
       the POST entry Info from the POST interface structure and configures its self
       accordingly. After POST finishes, it enters all of the required values of the
       POST Return Info into the POST interface structure. The POST Return Info
       includes the results from the tests that POST ran and the POST Exit Reason.
       VBSC extracts the POST Return Info from the POST interface structure and
       takes the appropriate action.

       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 will no longer be valid.
                4.4. Interfaces:

       Exported Interfaces :

       Machine state before    uncommitted     Machine state as described in [1]
       and after POST             
       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 interface          uncommitted     Data format as described in [1]
       structure data format                  
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/




--
Sunit Signature



Sunit Jain
Sun Microsystems, Inc.
4110 Nework Circle,
Mailstop USCA11-206,
Santa Clara, CA 95054


--Boundary_(ID_UpVDoDZ2qyj+ypJO6fPHGg) Content-id: Content-type: image/gif; name=Sunlogo.gif Content-transfer-encoding: BASE64 Content-disposition: inline; filename=Sunlogo.gif R0lGODlhYgBcALMAAP///1iDn2KLpdXg54Kit+Do7b3O2aG5yZeyw3easfX3+W2T q+rv86vBz4yqvcvY4SwAAAAAYgBcAAAE/xDISau9OOvNu/9gKI5kaZ5oqq5s675w LM90bd94ru987//AoHBILBqPyKRyyWw6n9CodEqtWq/YrHbL7Xq/4LB4TC6bz+i0 es1uu9/wuHxOr9vv+FyBECAU2gsBggJ/a4KBAYQkDAYNDQaFTAULBYMHg5EeA3x9 AocGSwyeApeJpYoeBoIHChKqgkqTCZa0iZkZD6sVDgEJSQqjs6a1AgwciMYUDQEH SJOnwqS0CZQalbAVAwEPRwWjy4nRpwejyRfaggPZAd2evQvQg6oJ7tS3E+h9FQwN EgoInkBRKOBIIIB/tiYwABgAgQlvguglAicA0QAD9cpduCbI4EB3+v8o8OolAaKg fgAegAzgEYRJiQ0BvBK0LaMghxgQCeJGQdQCdw4oKKAJShS1kzL7FBCGMsTLerwS lOpls0/Ue+AwUUiQYGhHCjONcQW2UxtOYS09CIMJM9GABg/WAhWWqFUFugEW2MXI iKY5AGsBNCDEcYAAnAxo3utwqKo7dQAaR3T32IJJQQQkLADFKbNCogAEcHvFNagE iiRoTl4dIJlqqqz/Tpj5tV/irxMQ+AVQKJoAuwAQ4RQxla07AnwScILNfLiFqSRP DwJ+O6SE6gEgJ01XgiBG1gh0Cmj0vbkGBTrZab5JQTduVzQ9S+C0AEVVh4cw3Rea lra6fNrl09r/VrtdR1NTJcxTDyXEXAKTc0ldANIf7tXnj06+AOBQdc5NZQyCI6gk iAOjjDPIYOxVoNsFy0ngjkEOcPUVRtsNOAEiQdF4wjzwNEgLhBLMwiJ7HCVDDkcF ANOPMKaVRBQwaYVYoo+JRBmZjRN4NSA4GapSADoCABCjAtVpJ9ggABCQYQqvSDPM MEA6yVIFpQg0Ule6gfLKAgD9sWcF9JE4AAJ+sEnleBlcg8p2TS3nlnQ08TRSMxQ4 +oABysU5QpunqKLpbIggFwgBZs5EgDltRuLOLSMt8N8CBFBqaCKcDGCmBowUtJit silggAHAnWcATxJcFCwKtGGZxkyfdiDfuAhr9kDQYhn8ioABCNjaj3eMGMBPAwwo 4IitgnmnSj+NFMDIAQYcgC64RMSKQAIGnMqOaF9SQkAjDjTgwABxPUAAAg4UUMlF UiUwwAK5PMDgA8f+QOq4mbGj3gDNBKDAJgU4sAADsBowADWRCUbAI28BlibGiA4x cQOblAwPzP04YDPNepGz8WCRwbXAuP1kNvG+RCTJQLh/qMOArWQeRO7SxmALANS8 qfOl0bzxtvGtVhzwcR4xRAAAOw== --Boundary_(ID_UpVDoDZ2qyj+ypJO6fPHGg) Content-id: Content-type: image/gif; name=Sun1.gif Content-transfer-encoding: BASE64 Content-disposition: inline; filename=Sun1.gif R0lGODlhrAB2AMQAAO6LL/jGmfWvcq7D0cfV31qEoP738oKituHq7Z62x9Xg5vGd U/vYuPa6hP3z6f3q2fvhyfGVROyBHv///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAACsAHYAAAX/4CSKRFGMaKqubOu+cCzP dG1PRzHcfO//wKAMYTIIj8ikEpkoHJbQqHSKyhGo2KzWpjBtv+DwqJkQm89SkwLN bgOJBaN7TpeVnvW8XkXe+/cmV3+DcyYIhIhoXSeJjWEDTo6SW5Blk5dTOTuYnEua naBIOWuhpT9qpqk8qKqtM4ausTBesrUstLa5I7i6uby9tazAwQWkw7LCZwwQPBAM KQ4NDkLLUA8M00CjYAIL3t4QEgs0EAEiCxIpDRINQuLN5inlIuvM2gWCWw0RABIR EeHGzegmIkI6FBAaPHAn0AbBFA/XPbu3CQy6ieIeNJg44UGAAAtRMAAA0AE6Bx+n /z2AMI3BA4/xJqBsEIDjiIQgRWQMYE9mgwb2ri285mBkyRFGWdYLoBApTRpNKn65 qLOfBAnmwgHoZ/PqVQbovAqYIHGCBKvsJkDoZ/DgiLZnF5712i6cWLJpJXqVwHEv g3VeAZwT528GJDwW+eqMcO3dSQcSxqJ4NwEdy354n/lrPM6yWbciQq4zt5nB2coS LkvQmBovM8qTBY5G7SzyBAGtYxwWQ9WswHdnf15NQdlgwXRlC5uNsFwnaJlMDbaj jFk57r+KkzccQbmsxHUCGqCL+WIRb8W+dY7z9/MncYHoBmdOn57y8BEO+HVLWzxd d771uEZfbPS0Vg947dnkgv8BRYTRm33rSZCNCpTFh9p8EH4GwQP3iWBaO+tMNw5k zN2HDmsgKgYbd7JlB2BaNiSjxYO/jYMbAN1INkI/G1kYn3bq4XUWZjexJ51ZAOyj GG4LrDOOaQAs0A8zPNpUZYD1cBiZNwq68Ak3C9jT5DntOCDAPwIoGEAECzDwEEFr MrOAZHOKwNQD/EDEJljmsInjRCahmU0DUQYQ5gRrRmBTogwYyoyjiC7ApjSGFWAJ MC9NYNp2oJTACDCAfZUKHHJg6syEpgRyTC19rBqLp67G8ACqLjgQ0hkMFnBIEh/+ 0OEXRMKAGzMO9ASGFUr06sOvW9QZg3jTiGfGbkmEU5f/PMaKsCEKjT3HQrG3ylQN ftvKE64K18jAZgvYIJStCuUixAKpvPrTDwALheXPNPZeZY5Je5Goqb8TbJWfVwLh 5tUzAVi1AL9SEkxgqO8e95moHhJ21UIHx4WbORKtdRVzZp3p7QjIIrGpm2kxsMx4 yzFl28eQpWNQNFeNZVtNIhcV2cEu+cPydBHIrGOQ+87KQnymHZVxm+i0M2w4AgRg m2X84EyaOF2OQO0RvYZD8jW4iYi0YJ9ldiZJHLajFgMGwb3aBHGXFVBzeLP4WQC0 omDhigO30+tZLp8l8EWRNWqb4S7Qe4S1QeLGD3810jfchxEIMCxfB08O1kGWlVVf /+UENnxWxRcOmLHg/EX5DWqQpXnWNzpzukLK1LTMtW0h4l3YaWnHjtU6N5d1EVUX zcZh7UES6NM7tqZgnOqBVw/8COBhZdrRebfwdRDby11bmFFbPo5B4d3nuVbjgDfS iyR91TTLpJGud03gFZybfBre2muv6FgAU7LiFQc4gEc/qR8MHAe+wDyjY73LkMi8 cRCFOacuYsmOAMuiMNv4jmQseoBVGIMam1hIYTH5X1pEFhwR9EMyphMa9W6BjyQY EBoy6FutWDC90PBgQg3ToQiEuAIi4ucGrQKFUfphOx8ckDx6ME8p/rKRZCFCRrEq xZeymIo7cFEVcJBC1wo0xv8ziM4RWMxdC844BzYmYotJwA0KwFWgnkyjKKhyiQzG 5QOJFGWO7eJWSCCAOhUU5VxA+N4R9CUNuLSPL1RDFF06YpWjwWw0LASAnBRjITvx 7iobEoeTRubJq6TIanxrC75Q0I9p3MxqV3lY2mYogy4gBgkQiNtCeNZKiZDEVjNb zWyMtT3UiBAAH3GMhFI3xMKEpSbDi4zIQjkW3LAmSQ+YmgfJiCQOKapsvmtiDHJV KiR08m11G1K02EE/8GQLMoLhRzH1R7eD9NBiOIqM1bDzjO+wczyzQVLh0ObJh0Vm mMCxX4yKsQQLdY4r65gSXtjkDb6FhXsnEgfkLuSj53z/DCtRWgfO+vkiirZJdLN7 HSsVFU17JLR5N4DjIg9ivBdZ7ZFQVAtXUGC1j23KhenwzDkHNix0/GM+/iQPSgmq AtxYU3nAQRvgoKKDhmIlIYmDKF98GpyfOMNlBgkXPCV0QGT2FC/hCVYzMRPRFJF0 GV0FiujQER738PQszBEb/erZACb1QJG502gG+ckhAOAsZ6yRGArQV0pxTENkbPKW QZ4kKu8sCWGsmUgmoVizeHQQhjlbFw+8uARUGfGIc+Th3EaASEQ6cYdFvJ4P53ja GEgxEc8khFUKiYQwNuIvvJ3DnbTwiy+CIo3GvQRykyuJbTAXFM6NhbTUIc5ORNcV /95QQXZbIVM38ClSC5hVkyAQMYBEak1Xw2tP0EESZgDmUHOMGI4KpFE6dLcNHLKR /NiREOE8MgKEEmZwbtVW1mhOtqjxL1pvZN+q6sE4/2DHPieDnMtqxnb2QVvcikTZ EpGsN224bxs2d9N1zKqDFXZva6aaIQFpa4UvdXGIHZyHnvJFSlK6jYoq/NYZ2odk 10HKO35qHfTMWCp0KGyFM2dMLSFVRUytynFYkifW5iyA9aRyOkbCvTCIuA1skeRl R8bj+bTFbceR8F6gaLUkFQaWBLspG77MBmcQaxnZcMZLmEGUjrQLJe/kSWhc5toX u+0aOdFWobeAu+eOQHMBznppHa7raER1Q4CEoHSl0cjQTSu3056WRHFDTQjfkroR tz01IkirakQAttV7iAqsEUHnWbthubZuAzlz7YdU87oOlfj1HmotbDHguthhMDWy 3fDqZZuB2M4mrq6i3QZYUZsNSby2GVSlbTNYu9tiyDa4v8DtcZv73OcOAQA7 --Boundary_(ID_UpVDoDZ2qyj+ypJO6fPHGg)-- --Boundary_(ID_eiVQzPuLRD4WCGuSEvS48g)-- From sacadmin Fri Oct 19 10:03:43 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9JH3gCw015092 for ; Fri, 19 Oct 2007 10:03:42 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9JH072v002997 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Sat, 20 Oct 2007 01:00:18 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ600G0H4KFCY00@nwk-avmta-1.sfbay.Sun.COM> for fwarc@sun.com (ORCPT fwarc@Sun.COM); Fri, 19 Oct 2007 10:00:15 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ600EFX4KER370@nwk-avmta-1.sfbay.Sun.COM> for fwarc@sun.com (ORCPT fwarc@Sun.COM); Fri, 19 Oct 2007 10:00:15 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9JH08FJ020310 for ; Fri, 19 Oct 2007 17:00:08 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ600L013B9PZ00@mail-amer.sun.com> (original mail from Stephen.Ehring@Sun.COM) for fwarc@Sun.COM (ORCPT fwarc@Sun.COM); Fri, 19 Oct 2007 11:00:08 -0600 (MDT) Received: from [129.148.131.33] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ600MQ04JUQK40@mail-amer.sun.com> for fwarc@Sun.COM (ORCPT fwarc@Sun.COM); Fri, 19 Oct 2007 10:59:54 -0600 (MDT) Date: Fri, 19 Oct 2007 12:59:53 -0400 From: Stephen Ehring Subject: Re: FWARC 2007/605 Sun4v VBSC to POST interface In-reply-to: <4717BF8B.9030906@Sun.COM> Sender: Stephen.Ehring@sun.com To: Firmware Arch Message-id: <4718E289.1040700@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47177B7F.20803@sun.com> <4717BF8B.9030906@Sun.COM> User-Agent: Thunderbird 2.0.0.7pre (X11/20071014) Status: RO Content-Length: 129 I've modified this case to "waiting need spec" until the project team can address issues brought up by Sunit and DavidK. Steve From sacadmin Fri Oct 19 11:39:13 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9JIdCJp017385 for ; Fri, 19 Oct 2007 11:39:13 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9JIZUDt008453 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Fri, 19 Oct 2007 19:35:48 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ600A0P8ZN8M00@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Fri, 19 Oct 2007 11:35:47 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ6004R58ZMLW60@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Fri, 19 Oct 2007 11:35:47 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9JIZk4M010466 for ; Fri, 19 Oct 2007 11:35:46 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ600C017QIH500@fe-sfbay-09.sun.com> (original mail from Eric.Blanchard@Sun.COM) for fwarc@sun.com (ORCPT fwarc@sun.com); Fri, 19 Oct 2007 11:35:46 -0700 (PDT) Received: from [129.148.9.185] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ600FE78ZBFYC0@fe-sfbay-09.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Fri, 19 Oct 2007 11:35:36 -0700 (PDT) Date: Fri, 19 Oct 2007 14:35:34 -0400 From: Eric.Blanchard@sun.com Subject: Re: FWARC 2007/605 Sun4v VBSC to POST interface In-reply-to: <4717BF8B.9030906@Sun.COM> Sender: Eric.Blanchard@sun.com To: S.Jain@sun.com Cc: Stephen Ehring , Firmware Arch Message-id: <4718F8F6.4080300@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <47177B7F.20803@sun.com> <4717BF8B.9030906@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4v; en-US; rv:1.7) Gecko/20070109 Status: RO Content-Length: 7174 S.Jain@Sun.COM wrote: > > Some platforms like Glendale and Monza had extended Huron defined > VBSC-POST interface to suit that platform. Pls see -- > > FWARC/2007/526 for monza platform binding > FWARC/2007/494 for glendale platform binding > > Do these need to change? The goal of this specification is to have the vbsc to post interface common for all N2 and VF platforms. I will need to add the Monza and Glendale platforms to this specification by giving these platforms their own sections at the end of the document. When Monza and Glendale are covered by this new specification, then the sections in FWARC/2007/526 and FWARC/2007/494 that pertain to the post interface will not be valid. Is the best way to invalidate the post interface sections in the Monza and Glendale platform bindings by removing those sections from the platform bindings, or is it better to note in this case that the post interface sections in FWARC/2007/526 and FWARC/2007/494 are no longer valid? -Eric > > Regards, > Sunit > > > Stephen Ehring wrote: > >> I'm sponsoring this case for Eric Blanchard. The case describes the >> interface that VBSC and POST use to pass information between the two >> consolidations. The case is intended to replace the previous cases, >> which were deemed insufficient and do not represent what was >> implemented, anyway. The interfaces can be released in a micro/minor >> version of the firmware and will constitute a flag day between POST >> and VBSC >> >> Steve >> >> http://sac.eng.sun.com/Archives/CaseLog/arc/FWARC/2007/605/onepager.txt >> >> 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]. >> >> 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. >> >> VBSC and POST run on two different processors with separate >> memory spaces. >> VBSC runs on the service processor and POST runs on the host >> processor >> (N2, VF, ect...). The Service processor and the Host processor >> share >> information by reading and writing an area of shared memory >> residing in the fpga. >> >> Before POST runs, VBSC sets up the POST interface structure in >> the memory of >> the FPGA and enters all of the required values of the POST >> entry Info. The >> POST entry Info includes a list of the machine information, >> communication >> channel information, and POST runtime options. When POST >> starts, POST extracts >> the POST entry Info from the POST interface structure and >> configures its self >> accordingly. After POST finishes, it enters all of the >> required values of the >> POST Return Info into the POST interface structure. The POST >> Return Info >> includes the results from the tests that POST ran and the POST >> Exit Reason. >> VBSC extracts the POST Return Info from the POST interface >> structure and >> takes the appropriate action. >> >> 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 will no longer be valid. >> 4.4. Interfaces: >> >> Exported Interfaces : >> >> Machine state before uncommitted Machine state as >> described in [1] >> and after POST >> 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 interface uncommitted Data format as >> described in [1] >> structure data format >> 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/ >> >> >> > > -- > > > > Sunit Jain > Sun Microsystems, Inc. > 4110 Nework Circle, > Mailstop USCA11-206, > Santa Clara, CA 95054 > > > From sacadmin Fri Oct 19 11:59:04 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9JIx3xL017825 for ; Fri, 19 Oct 2007 11:59:04 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9JItUvw020880 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Sat, 20 Oct 2007 02:55:39 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ6002099WQY400@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Fri, 19 Oct 2007 12:55:38 -0600 (MDT) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ600B8L9WQKBC0@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Fri, 19 Oct 2007 12:55:38 -0600 (MDT) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l9JItb3A014516; Fri, 19 Oct 2007 11:55:37 -0700 (PDT) Received: from [192.168.0.3] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9JItaEB038353; Fri, 19 Oct 2007 11:55:37 -0700 (PDT) Date: Fri, 19 Oct 2007 11:55:35 -0700 From: David Kahn Subject: Re: FWARC 2007/605 Sun4v VBSC to POST interface To: Eric.Blanchard@sun.com Cc: S.Jain@sun.com, Stephen Ehring , Firmware Arch Message-id: <4718FDA7.9030507@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) Status: RO Content-Length: 1227 Eric.Blanchard@sun.com wrote: >> FWARC/2007/526 for monza platform binding >> FWARC/2007/494 for glendale platform binding >> >> Do these need to change? > > > The goal of this specification is to have the vbsc to post interface > common for all N2 and VF platforms. I will need to add the Monza and > Glendale platforms to this specification by giving these platforms their > own sections at the end of the document. When Monza and Glendale are > covered by this new specification, then the sections in FWARC/2007/526 > and FWARC/2007/494 that pertain to the post interface will not be valid. > > Is the best way to invalidate the post interface sections in the Monza > and Glendale platform bindings by removing those sections from the > platform bindings, or is it better to note in this case that the post > interface sections in FWARC/2007/526 and FWARC/2007/494 are no longer > valid? Are the interfaces defined in those two cases actually changing? If yes, then this new case (or cases) can deprecate the previous cases, and the interface tables will list the specific interfaces that are being deprecated by this case. If not, then I'm confused as to what you are trying to do with this case. -David From sacadmin Fri Oct 19 12:43:12 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9JJhAdH018594 for ; Fri, 19 Oct 2007 12:43:11 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9JJdkvF007018 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Sat, 20 Oct 2007 03:39:47 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ600D03BY9YN00@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Fri, 19 Oct 2007 12:39:45 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ6004R9BY9LO60@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Fri, 19 Oct 2007 12:39:45 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9JJdi8k017151 for ; Fri, 19 Oct 2007 12:39:44 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ600K01BNMWA00@fe-sfbay-10.sun.com> (original mail from Eric.Blanchard@Sun.COM) for fwarc@sun.com (ORCPT fwarc@sun.com); Fri, 19 Oct 2007 12:39:44 -0700 (PDT) Received: from [129.148.9.185] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ60014LBXMF1A0@fe-sfbay-10.sun.com>; Fri, 19 Oct 2007 12:39:23 -0700 (PDT) Date: Fri, 19 Oct 2007 15:39:22 -0400 From: Eric.Blanchard@sun.com Subject: Re: FWARC 2007/605 Sun4v VBSC to POST interface In-reply-to: <4718FDA7.9030507@sun.com> Sender: Eric.Blanchard@sun.com To: David Kahn Cc: S.Jain@sun.com, Stephen Ehring , Firmware Arch Message-id: <471907EA.90007@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <4718FDA7.9030507@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4v; en-US; rv:1.7) Gecko/20070109 Status: RO Content-Length: 1499 David Kahn wrote: > > > Eric.Blanchard@sun.com wrote: > >>> FWARC/2007/526 for monza platform binding >>> FWARC/2007/494 for glendale platform binding >>> >>> Do these need to change? >> >> >> >> The goal of this specification is to have the vbsc to post interface >> common for all N2 and VF platforms. I will need to add the Monza and >> Glendale platforms to this specification by giving these platforms >> their own sections at the end of the document. When Monza and >> Glendale are covered by this new specification, then the sections in >> FWARC/2007/526 and FWARC/2007/494 that pertain to the post interface >> will not be valid. >> >> Is the best way to invalidate the post interface sections in the >> Monza and Glendale platform bindings by removing those sections from >> the platform bindings, or is it better to note in this case that the >> post interface sections in FWARC/2007/526 and FWARC/2007/494 are no >> longer valid? > > > Are the interfaces defined in those two cases actually > changing? > > If yes, then this new case (or cases) can deprecate the > previous cases, and the interface tables will list the > specific interfaces that are being deprecated by this case. The POST interface for Glendale and Monza are changing so I am going to list the Glendale and Monza post interfaces defined in FWARC/2007/526 and FWARC/2007/494 as depreciated by this case. -Eric > > If not, then I'm confused as to what you are trying to > do with this case. > > -David From sacadmin Fri Oct 19 15:19:30 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9JMJTM1022258 for ; Fri, 19 Oct 2007 15:19:29 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9JMG3Fj027945 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Fri, 19 Oct 2007 23:16:05 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ600305J6RYJ00@nwk-avmta-1.sfbay.Sun.COM> for fwarc@sun.com (ORCPT fwarc@sun.com); Fri, 19 Oct 2007 15:16:03 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ6002Y5J6Q0G20@nwk-avmta-1.sfbay.Sun.COM> for fwarc@sun.com (ORCPT fwarc@sun.com); Fri, 19 Oct 2007 15:16:02 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9JMG2ts007365 for ; Fri, 19 Oct 2007 15:16:02 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ600901J2TIU00@fe-sfbay-09.sun.com> (original mail from Hitendra.Zhangada@Sun.COM) for fwarc@sun.com (ORCPT fwarc@sun.com); Fri, 19 Oct 2007 15:16:02 -0700 (PDT) Received: from [129.150.35.134] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ600F1QJ6O3880@fe-sfbay-09.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Fri, 19 Oct 2007 15:16:01 -0700 (PDT) Date: Fri, 19 Oct 2007 15:17:35 -0700 From: Hitendra Zhangada Subject: Re: FWARC 2007/605 Sun4v VBSC to POST interface In-reply-to: <471907EA.90007@Sun.COM> Sender: Hitendra.Zhangada@sun.com To: Eric.Blanchard@sun.com Cc: Firmware Arch Message-id: <47192CFF.9070107@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4718FDA7.9030507@sun.com> <471907EA.90007@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) Status: RO Content-Length: 2038 Eric.Blanchard@Sun.COM wrote: > David Kahn wrote: > >> >> >> Eric.Blanchard@sun.com wrote: >> >>>> FWARC/2007/526 for monza platform binding >>>> FWARC/2007/494 for glendale platform binding >>>> >>>> Do these need to change? >>> >>> >>> >>> The goal of this specification is to have the vbsc to post interface >>> common for all N2 and VF platforms. I will need to add the Monza and >>> Glendale platforms to this specification by giving these platforms >>> their own sections at the end of the document. When Monza and >>> Glendale are covered by this new specification, then the sections in >>> FWARC/2007/526 and FWARC/2007/494 that pertain to the post interface >>> will not be valid. >>> >>> Is the best way to invalidate the post interface sections in the >>> Monza and Glendale platform bindings by removing those sections from >>> the platform bindings, or is it better to note in this case that the >>> post interface sections in FWARC/2007/526 and FWARC/2007/494 are no >>> longer valid? >> >> >> Are the interfaces defined in those two cases actually >> changing? >> >> If yes, then this new case (or cases) can deprecate the >> previous cases, and the interface tables will list the >> specific interfaces that are being deprecated by this case. > > > The POST interface for Glendale and Monza are changing so I am going > to list the Glendale and Monza post interfaces defined in > FWARC/2007/526 and FWARC/2007/494 as depreciated by this case. Note that changing an interface is not the same as deprecating it. If you are changing how an existing interface works then the original interface is NOT deprecated but rather modified by your case. I have not looked at all the specifications yet but I just want to make sure changing existing interfaces are not viewed as deprecating it. -- Hitendra Zhangada ============================================= SPS Common SW Features Engineering Software Group, Sun Microsystems, Inc. From sacadmin Fri Oct 19 15:38:30 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9JMcT0g022675 for ; Fri, 19 Oct 2007 15:38:30 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9JMZ5R1035444 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Fri, 19 Oct 2007 16:35:06 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ600L0HK2HI800@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Fri, 19 Oct 2007 16:35:05 -0600 (MDT) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ6005MXK2GBT60@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Fri, 19 Oct 2007 16:35:04 -0600 (MDT) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l9JMZ4AT012402; Fri, 19 Oct 2007 15:35:04 -0700 (PDT) Received: from [192.168.0.3] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9JMZ3La050588; Fri, 19 Oct 2007 15:35:04 -0700 (PDT) Date: Fri, 19 Oct 2007 15:35:03 -0700 From: David Kahn Subject: Re: FWARC 2007/605 Sun4v VBSC to POST interface To: Hitendra Zhangada Cc: Eric.Blanchard@sun.com, Firmware Arch Message-id: <47193117.4070805@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) Status: RO Content-Length: 870 Hitendra Zhangada wrote: > Note that changing an interface is not the same as deprecating it. If > you are changing how an existing interface works then the original > interface is NOT deprecated but rather modified by your case. My understanding is that the old interface will be replaced by the new one. In ARC terms, they are deprecating the old interface and creating a new interface to replace the old one, and that this case will fully describe that interface and the old materials in the old cases will effectively be obsolete except as they pertain to older firmware already released. Any newer releases will use the new interfaces defined by this case (after approval and integration.) If that's not true, work with your case sponsor to figure out what the right ARC/interface terminology is and how that should be handled in the case materials. -David From sacadmin Tue Nov 27 11:59:20 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lARJxKVx020171 for ; Tue, 27 Nov 2007 11:59:20 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lARJxKmg006437 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Tue, 27 Nov 2007 11:59:20 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JS60062JKUVFV00@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 27 Nov 2007 12:59:19 -0700 (MST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JS600EB0KUVDHD0@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 27 Nov 2007 12:59:19 -0700 (MST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lARJxJDi001530 for ; Tue, 27 Nov 2007 19:59:19 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JS600G01KPH3G00@mail-amer.sun.com> (original mail from Stephen.Ehring@Sun.COM) for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 27 Nov 2007 12:59:19 -0700 (MST) Received: from [129.148.131.33] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JS600I7PKURXV90@mail-amer.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 27 Nov 2007 12:59:16 -0700 (MST) Date: Tue, 27 Nov 2007 14:59:15 -0500 From: Stephen Ehring Subject: Re: FWARC 2007/605 Sun4v VBSC to POST interface In-reply-to: <47193117.4070805@sun.com> Sender: Stephen.Ehring@sun.com To: Firmware Arch Message-id: <474C7713.30303@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47193117.4070805@sun.com> User-Agent: Thunderbird 2.0.0.10pre (X11/20071125) Status: RO Content-Length: 1435 David Kahn wrote: > > > Hitendra Zhangada wrote: > > >> Note that changing an interface is not the same as deprecating it. If >> you are changing how an existing interface works then the original >> interface is NOT deprecated but rather modified by your case. > > My understanding is that the old interface will be replaced > by the new one. In ARC terms, they are deprecating the old > interface and creating a new interface to replace the old > one, and that this case will fully describe that interface > and the old materials in the old cases will effectively be > obsolete except as they pertain to older firmware already > released. Any newer releases will use the new interfaces > defined by this case (after approval and integration.) That is correct. The project team is requesting we deprecate the old interfaces (specified by the cases called out in section 4 of the onepager). These interfaces were never fully implemented and were insufficient for the data that needed to be communicated between POST and VBSC. The project team has updated the specification based on feedback from DavidK and Hitendra. I'm re-starting the timer which will time out on 12/4 unless there are other issues raised that need to be resolved. http://sac.eng/Archives/CaseLog/arc/FWARC/2007/605/materials/onepager.txt Updated spec here: http://sac.eng/Archives/CaseLog/arc/FWARC/2007/605/materials/sun4v_vbsc_post_interface.txt Steve From sacadmin Tue Nov 27 12:50:37 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lARKobhF007310 for ; Tue, 27 Nov 2007 12:50:37 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lARKobJP000695 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Tue, 27 Nov 2007 13:50:37 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JS600A03N8DOT00@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 27 Nov 2007 13:50:37 -0700 (MST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JS6007TPN8CLO10@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 27 Nov 2007 13:50:36 -0700 (MST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lARKoa3m005573 for ; Tue, 27 Nov 2007 20:50:36 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JS600E01LQK0V00@mail-amer.sun.com> (original mail from William.Clemence@Sun.COM) for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 27 Nov 2007 13:50:36 -0700 (MST) Received: from [129.148.9.170] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JS60065RN865660@mail-amer.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 27 Nov 2007 13:50:30 -0700 (MST) Date: Tue, 27 Nov 2007 15:50:30 -0500 From: william clemence - Sun Microsystems - Burlington United States Subject: Re: FWARC 2007/605 Sun4v VBSC to POST interface In-reply-to: <474C7713.30303@sun.com> Sender: William.Clemence@sun.com To: Stephen Ehring Cc: Firmware Arch Reply-to: William.Clemence@sun.com Message-id: <474C8316.3040504@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <47193117.4070805@sun.com> <474C7713.30303@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4v; en-US; rv:1.7) Gecko/20070109 Status: RO Content-Length: 2866 Section 4 for Glendale is incorrect. The REM should be on bit 9 not bit 15 as in the one-pager 4.4.1 IO Device Results This is the bit to device mapping for the IO Device Results Word in the POST Exit Info portion of the POST Interface Structure. bit | field ------+-------------------- 0 | XAUI_PORT0 1 | XAUI_PORT1 2 | PCISWITCH0 3-5 | Unused 6 | GBEO 7 | Unused 8 | PCIE-BRIDGE 9 | Unused <<<< REM 10 | USB0 11 | USB1 12 | DISPLAY 13-14 | Unused 15 | REM <<< Unused 16-63 | Unused Section 5 for Monza is also incorrect. See below. 5.4.1 IO Device Results This is the bit to device mapping for the IO Device Results Word in the POST Exit Info portion of the POST Interface Structure. bit | field ------+-------------------- 0 | XAUI_PORT0 1 | XAUI_PORT1 2 | PCISWITCH0 3-5 | Unused 6 | GBEO 7 | GBE1 8 | PCIE-BRIDGE 9 | Unused 10 | USB <<< Unused 11-12 | Unused 13 | GBE2 >>>> 14 | USB <<< USB is here... 14 | RTM <<< RTM is on bit 15 not 14. 15-63 | Unused <<< 16-63 are unused.. Bill Stephen Ehring wrote: > David Kahn wrote: > >> >> >> Hitendra Zhangada wrote: >> >> >>> Note that changing an interface is not the same as deprecating it. >>> If you are changing how an existing interface works then the original >>> interface is NOT deprecated but rather modified by your case. >> >> >> My understanding is that the old interface will be replaced >> by the new one. In ARC terms, they are deprecating the old >> interface and creating a new interface to replace the old >> one, and that this case will fully describe that interface >> and the old materials in the old cases will effectively be >> obsolete except as they pertain to older firmware already >> released. Any newer releases will use the new interfaces >> defined by this case (after approval and integration.) > > That is correct. The project team is requesting we deprecate the old > interfaces (specified by the cases called out in section 4 of the > onepager). These interfaces were never fully implemented and were > insufficient for the data that needed to be communicated between POST > and VBSC. > > The project team has updated the specification based on feedback from > DavidK and Hitendra. I'm re-starting the timer which will time out on > 12/4 unless there are other issues raised that need to be resolved. > > http://sac.eng/Archives/CaseLog/arc/FWARC/2007/605/materials/onepager.txt > > Updated spec here: > > http://sac.eng/Archives/CaseLog/arc/FWARC/2007/605/materials/sun4v_vbsc_post_interface.txt > > > Steve From sacadmin Wed Nov 28 06:59:38 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lASExc0j019885 for ; Wed, 28 Nov 2007 06:59:38 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lASExakd063239 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Wed, 28 Nov 2007 07:59:38 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JS800A0D1NE6K00@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Wed, 28 Nov 2007 07:59:38 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JS80012E1ND3L50@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Wed, 28 Nov 2007 07:59:37 -0700 (MST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lASExbd3017716 for ; Wed, 28 Nov 2007 06:59:37 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JS8001011JSNP00@fe-sfbay-10.sun.com> (original mail from Eric.Blanchard@Sun.COM) for fwarc@sun.com (ORCPT fwarc@sun.com); Wed, 28 Nov 2007 06:59:37 -0800 (PST) Received: from [129.150.66.19] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JS800MI31NBD310@fe-sfbay-10.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Wed, 28 Nov 2007 06:59:37 -0800 (PST) Date: Wed, 28 Nov 2007 06:59:34 -0800 From: Eric Blanchard Subject: Re: FWARC 2007/605 Sun4v VBSC to POST interface In-reply-to: <474C8316.3040504@Sun.COM> Sender: Eric.Blanchard@sun.com To: William.Clemence@sun.com Cc: Stephen Ehring , Firmware Arch Message-id: <474D8256.9060506@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <47193117.4070805@sun.com> <474C7713.30303@sun.com> <474C8316.3040504@Sun.COM> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060414 Status: RO Content-Length: 3693 I am requesting that these changes be made to the io device words on glendale and monza. POST requested the io device results to be defined for n2 in such a way that a common io device results word format is used for all n2 platforms. Each n2 platform will only use a subset of these device words since the devices are not common among all platforms. These bits had to be moved because the current definition of io device words doubled up devices on bits. For example bit 9 was used for SAHSBA on huron and bit 9 is used for REM on Glendale, so I moved REM to bit 15, a bit that was unused by all platforms. -Eric william clemence - Sun Microsystems - Burlington United States wrote: > Section 4 for Glendale is incorrect. The REM should be on bit 9 not > bit 15 as in the one-pager > > 4.4.1 IO Device Results > > This is the bit to device mapping for the IO Device Results > Word in the > POST Exit Info portion of the POST Interface Structure. > > bit | field > ------+-------------------- > 0 | XAUI_PORT0 > 1 | XAUI_PORT1 > 2 | PCISWITCH0 > 3-5 | Unused > 6 | GBEO > 7 | Unused > 8 | PCIE-BRIDGE > 9 | Unused <<<< REM > 10 | USB0 > 11 | USB1 > 12 | DISPLAY > 13-14 | Unused > 15 | REM <<< Unused > 16-63 | Unused > > > Section 5 for Monza is also incorrect. See below. > > > 5.4.1 IO Device Results > > This is the bit to device mapping for the IO Device Results > Word in the > POST Exit Info portion of the POST Interface Structure. > > bit | field > ------+-------------------- > 0 | XAUI_PORT0 > 1 | XAUI_PORT1 > 2 | PCISWITCH0 > 3-5 | Unused > 6 | GBEO > 7 | GBE1 > 8 | PCIE-BRIDGE > 9 | Unused > 10 | USB <<< Unused > 11-12 | Unused > 13 | GBE2 > >>>>> 14 | USB <<< USB is here... >>>> > 14 | RTM <<< RTM is on bit 15 not 14. > 15-63 | Unused <<< 16-63 are unused.. > > > > > Bill > > > > Stephen Ehring wrote: > >> David Kahn wrote: >> >>> >>> >>> Hitendra Zhangada wrote: >>> >>> >>>> Note that changing an interface is not the same as deprecating it. >>>> If you are changing how an existing interface works then the original >>>> interface is NOT deprecated but rather modified by your case. >>> >>> >>> >>> My understanding is that the old interface will be replaced >>> by the new one. In ARC terms, they are deprecating the old >>> interface and creating a new interface to replace the old >>> one, and that this case will fully describe that interface >>> and the old materials in the old cases will effectively be >>> obsolete except as they pertain to older firmware already >>> released. Any newer releases will use the new interfaces >>> defined by this case (after approval and integration.) >> >> >> That is correct. The project team is requesting we deprecate the old >> interfaces (specified by the cases called out in section 4 of the >> onepager). These interfaces were never fully implemented and were >> insufficient for the data that needed to be communicated between POST >> and VBSC. >> >> The project team has updated the specification based on feedback from >> DavidK and Hitendra. I'm re-starting the timer which will time out on >> 12/4 unless there are other issues raised that need to be resolved. >> >> http://sac.eng/Archives/CaseLog/arc/FWARC/2007/605/materials/onepager.txt >> >> >> Updated spec here: >> >> http://sac.eng/Archives/CaseLog/arc/FWARC/2007/605/materials/sun4v_vbsc_post_interface.txt >> >> >> Steve > > From sacadmin Wed Nov 28 09:04:30 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lASH4UtT022874 for ; Wed, 28 Nov 2007 09:04:30 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lASH4TjC017533 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Wed, 28 Nov 2007 09:04:30 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JS80040D7FHC800@nwk-avmta-1.sfbay.Sun.COM> for fwarc@sun.com (ORCPT fwarc@sun.com); Wed, 28 Nov 2007 09:04:29 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JS800AY97FGRUE0@nwk-avmta-1.sfbay.Sun.COM> for fwarc@sun.com (ORCPT fwarc@sun.com); Wed, 28 Nov 2007 09:04:28 -0800 (PST) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lASH4SYT062163; Wed, 28 Nov 2007 09:04:28 -0800 (PST) Received: from [192.168.0.3] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lASH4Ri7094821; Wed, 28 Nov 2007 09:04:27 -0800 (PST) Date: Wed, 28 Nov 2007 09:04:27 -0800 From: David Kahn Subject: Re: FWARC 2007/605 Sun4v VBSC to POST interface To: Stephen Ehring Cc: Eric Blanchard , William.Clemence@sun.com, Firmware Arch Message-id: <474D9F9B.3070908@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 4019 Stephen: If the materials need to be updated to reflect changes, then please stop the clock on this case, update the materials and then restart the clock. -David Eric Blanchard wrote: > I am requesting that these changes be made to the io device words on > glendale and monza. POST requested the io device results to be defined > for n2 in such a way that a common io device results word format is used > for all n2 platforms. Each n2 platform will only use a subset of these > device words since the devices are not common among all platforms. These > bits had to be moved because the current definition of io device words > doubled up devices on bits. For example bit 9 was used for SAHSBA on > huron and bit 9 is used for REM on Glendale, so I moved REM to bit 15, a > bit that was unused by all platforms. > > -Eric > > william clemence - Sun Microsystems - Burlington United States wrote: > >> Section 4 for Glendale is incorrect. The REM should be on bit 9 not >> bit 15 as in the one-pager >> >> 4.4.1 IO Device Results >> >> This is the bit to device mapping for the IO Device Results >> Word in the >> POST Exit Info portion of the POST Interface Structure. >> >> bit | field >> ------+-------------------- >> 0 | XAUI_PORT0 >> 1 | XAUI_PORT1 >> 2 | PCISWITCH0 >> 3-5 | Unused >> 6 | GBEO >> 7 | Unused >> 8 | PCIE-BRIDGE >> 9 | Unused <<<< REM >> 10 | USB0 >> 11 | USB1 >> 12 | DISPLAY >> 13-14 | Unused >> 15 | REM <<< Unused >> 16-63 | Unused >> >> >> Section 5 for Monza is also incorrect. See below. >> >> >> 5.4.1 IO Device Results >> >> This is the bit to device mapping for the IO Device Results >> Word in the >> POST Exit Info portion of the POST Interface Structure. >> >> bit | field >> ------+-------------------- >> 0 | XAUI_PORT0 >> 1 | XAUI_PORT1 >> 2 | PCISWITCH0 >> 3-5 | Unused >> 6 | GBEO >> 7 | GBE1 >> 8 | PCIE-BRIDGE >> 9 | Unused >> 10 | USB <<< Unused >> 11-12 | Unused >> 13 | GBE2 >> >>>>>> 14 | USB <<< USB is here... >>>>> >> 14 | RTM <<< RTM is on bit 15 not 14. >> 15-63 | Unused <<< 16-63 are unused.. >> >> >> >> >> Bill >> >> >> >> Stephen Ehring wrote: >> >>> David Kahn wrote: >>> >>>> >>>> >>>> Hitendra Zhangada wrote: >>>> >>>> >>>>> Note that changing an interface is not the same as deprecating it. >>>>> If you are changing how an existing interface works then the original >>>>> interface is NOT deprecated but rather modified by your case. >>>> >>>> >>>> >>>> My understanding is that the old interface will be replaced >>>> by the new one. In ARC terms, they are deprecating the old >>>> interface and creating a new interface to replace the old >>>> one, and that this case will fully describe that interface >>>> and the old materials in the old cases will effectively be >>>> obsolete except as they pertain to older firmware already >>>> released. Any newer releases will use the new interfaces >>>> defined by this case (after approval and integration.) >>> >>> >>> That is correct. The project team is requesting we deprecate the old >>> interfaces (specified by the cases called out in section 4 of the >>> onepager). These interfaces were never fully implemented and were >>> insufficient for the data that needed to be communicated between POST >>> and VBSC. >>> >>> The project team has updated the specification based on feedback from >>> DavidK and Hitendra. I'm re-starting the timer which will time out on >>> 12/4 unless there are other issues raised that need to be resolved. >>> >>> http://sac.eng/Archives/CaseLog/arc/FWARC/2007/605/materials/onepager.txt >>> >>> >>> Updated spec here: >>> >>> http://sac.eng/Archives/CaseLog/arc/FWARC/2007/605/materials/sun4v_vbsc_post_interface.txt >>> >>> >>> Steve >> >> > From sacadmin Wed Nov 28 13:07:13 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lASL7DZf007482 for ; Wed, 28 Nov 2007 13:07:13 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lASL7CeH032737 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Wed, 28 Nov 2007 14:07:13 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JS800F09INYGF00@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Wed, 28 Nov 2007 14:07:10 -0700 (MST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JS800CY9INXNZ10@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Wed, 28 Nov 2007 14:07:09 -0700 (MST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lASL79dG024144 for ; Wed, 28 Nov 2007 21:07:09 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JS800701EJU9300@mail-amer.sun.com> (original mail from Stephen.Ehring@Sun.COM) for fwarc@sun.com (ORCPT fwarc@sun.com); Wed, 28 Nov 2007 14:07:09 -0700 (MST) Received: from [129.148.131.33] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JS8002OUINP2BB0@mail-amer.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Wed, 28 Nov 2007 14:07:01 -0700 (MST) Date: Wed, 28 Nov 2007 16:07:01 -0500 From: Stephen Ehring Subject: Re: FWARC 2007/605 Sun4v VBSC to POST interface In-reply-to: <474C8316.3040504@Sun.COM> Sender: Stephen.Ehring@sun.com To: Firmware Arch Message-id: <474DD875.7090907@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47193117.4070805@sun.com> <474C7713.30303@sun.com> <474C8316.3040504@Sun.COM> User-Agent: Thunderbird 2.0.0.10pre (X11/20071125) Status: RO Content-Length: 542 william clemence - Sun Microsystems - Burlington United States wrote: > Section 4 for Glendale is incorrect. The REM should be on bit 9 not > bit 15 as in the one-pager > > The project team has implemented this change. They have also added Turgo and Batoka platforms to the interface document so that follow-on cases are not necessary for those platforms. http://sac.eng/Archives/CaseLog/arc/FWARC/2007/605/materials/sun4v_vbsc_post_interface.txt I've extended the case timer by one day so the case now times out on 12/5/2007. Steve From sacadmin Wed Nov 28 16:01:45 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lAT01i6A010549 for ; Wed, 28 Nov 2007 16:01:45 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lAT01Yfl011728 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Thu, 29 Nov 2007 00:01:43 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JS800607QQTN700@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@Sun.COM); Wed, 28 Nov 2007 17:01:41 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JS800CMYQQTOEA0@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@Sun.COM); Wed, 28 Nov 2007 17:01:41 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lAT01fBj026676 for ; Wed, 28 Nov 2007 16:01:41 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JS800M01PBAHT00@fe-sfbay-09.sun.com> (original mail from Cindy.Wang@Sun.COM) for fwarc@Sun.COM (ORCPT fwarc@Sun.COM); Wed, 28 Nov 2007 16:01:41 -0800 (PST) Received: from [129.145.155.72] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JS8004XRQQ9CS60@fe-sfbay-09.sun.com> for fwarc@Sun.COM (ORCPT fwarc@Sun.COM); Wed, 28 Nov 2007 16:01:22 -0800 (PST) Date: Wed, 28 Nov 2007 16:01:21 -0800 From: Cindy Wang Subject: Re: [Fwd: Re: FWARC 2007/605 Sun4v VBSC to POST interface] In-reply-to: <474DEEF8.7030801@Sun.COM> Sender: Cindy.Wang@sun.com To: Cindy Wang , Stephen Ehring , fwarc@sun.com Cc: Anand.Misra@sun.com, yukong Message-id: <474E0151.30806@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <474DEEF8.7030801@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4v; en-US; rv:1.7) Gecko/20070109 Status: RO Content-Length: 1210 Turgo uses bit 10 for pci bridge on PCI tray, In 6.4.1, PCIE-BRIDGE2 should be on bit 10 not bit 15 as in the one-pager. Or should the code be changed? Thanks cindy Anand Misra wrote: > Hello: > > Please make sure the Turgo specific information is correct in this FWARC > case. > > Regards, > Anand. > > ------------------------------------------------------------------------ > > Subject: > Re: FWARC 2007/605 Sun4v VBSC to POST interface > From: > Stephen Ehring > Date: > Wed, 28 Nov 2007 16:07:01 -0500 > To: > Firmware Arch > > To: > Firmware Arch > > > william clemence - Sun Microsystems - Burlington United States wrote: > >> Section 4 for Glendale is incorrect. The REM should be on bit 9 not >> bit 15 as in the one-pager >> >> > The project team has implemented this change. They have also added Turgo > and Batoka platforms to the interface document so that follow-on cases > are not necessary for those platforms. > > http://sac.eng/Archives/CaseLog/arc/FWARC/2007/605/materials/sun4v_vbsc_post_interface.txt > > > I've extended the case timer by one day so the case now times out on > 12/5/2007. > > Steve > From sacadmin Wed Nov 28 16:32:54 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lAT0WsF6010820 for ; Wed, 28 Nov 2007 16:32:54 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lAT0WrGs011574 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Wed, 28 Nov 2007 16:32:54 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JS800H0DS6TSJ00@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@Sun.COM); Wed, 28 Nov 2007 16:32:53 -0800 (PST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JS800GL3S6TVM10@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@Sun.COM); Wed, 28 Nov 2007 16:32:53 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAT0Wr25019819 for ; Thu, 29 Nov 2007 00:32:53 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JS800701S0TT600@mail-amer.sun.com> (original mail from William.Clemence@Sun.COM) for fwarc@Sun.COM (ORCPT fwarc@Sun.COM); Wed, 28 Nov 2007 17:32:53 -0700 (MST) Received: from [129.148.9.170] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JS800ALVS6SFW00@mail-amer.sun.com> for fwarc@Sun.COM (ORCPT fwarc@Sun.COM); Wed, 28 Nov 2007 17:32:52 -0700 (MST) Date: Wed, 28 Nov 2007 19:32:51 -0500 From: william clemence - Sun Microsystems - Burlington United States Subject: Re: [Fwd: Re: FWARC 2007/605 Sun4v VBSC to POST interface] In-reply-to: <474E0151.30806@Sun.COM> Sender: William.Clemence@Sun.COM To: Cindy Wang Cc: Stephen Ehring , fwarc@Sun.COM, Anand.Misra@Sun.COM, yukong Reply-to: William.Clemence@Sun.COM Message-id: <474E08B3.90803@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <474DEEF8.7030801@Sun.COM> <474E0151.30806@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4v; en-US; rv:1.7) Gecko/20070109 Status: RO Content-Length: 1588 Sorry I mis-read the bit in your putback and thought I saw bit 15. We'll update it when this new interface is incorperated in 7.1. We need to move a Monza bit too at that time. If it gets pushed to go back into the 7.0, which I don't think it we will need do the adjustment all at once in that gate too. Cindy Wang wrote: > > > Turgo uses bit 10 for pci bridge on PCI tray, > In 6.4.1, PCIE-BRIDGE2 should be on bit 10 not bit 15 as in the > one-pager. Or should the code be changed? > > Thanks > > cindy > > > Anand Misra wrote: > >> Hello: >> >> Please make sure the Turgo specific information is correct in this >> FWARC case. >> >> Regards, >> Anand. >> >> ------------------------------------------------------------------------ >> >> Subject: >> Re: FWARC 2007/605 Sun4v VBSC to POST interface >> From: >> Stephen Ehring >> Date: >> Wed, 28 Nov 2007 16:07:01 -0500 >> To: >> Firmware Arch >> >> To: >> Firmware Arch >> >> >> william clemence - Sun Microsystems - Burlington United States wrote: >> >>> Section 4 for Glendale is incorrect. The REM should be on bit 9 not >>> bit 15 as in the one-pager >>> >>> >> The project team has implemented this change. They have also added >> Turgo and Batoka platforms to the interface document so that >> follow-on cases are not necessary for those platforms. >> >> http://sac.eng/Archives/CaseLog/arc/FWARC/2007/605/materials/sun4v_vbsc_post_interface.txt >> >> >> I've extended the case timer by one day so the case now times out on >> 12/5/2007. >> >> Steve >> > From sacadmin Thu Nov 29 13:16:32 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lATLGV1f014513 for ; Thu, 29 Nov 2007 13:16:31 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lATLGSW2028326 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Thu, 29 Nov 2007 21:16:30 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSA00A01DRH1A00@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 29 Nov 2007 13:16:29 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSA002FKDRG8IB0@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 29 Nov 2007 13:16:28 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lATLGSV1021961 for ; Thu, 29 Nov 2007 13:16:28 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSA00M01DQXH200@fe-sfbay-09.sun.com> (original mail from Mehrdad.Mojgani@Sun.COM) for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 29 Nov 2007 13:16:28 -0800 (PST) Received: from [129.145.155.190] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSA008ESDRFKDA0@fe-sfbay-09.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 29 Nov 2007 13:16:28 -0800 (PST) Date: Thu, 29 Nov 2007 13:16:27 -0800 From: Mehrdad Mojgani Subject: Re: [Fwd: Re: FWARC 2007/605 Sun4v VBSC to POST interface] In-reply-to: <474E08B3.90803@Sun.COM> Sender: Mehrdad.Mojgani@sun.com To: William.Clemence@sun.com Cc: Cindy Wang , Stephen Ehring , fwarc@sun.com, Anand.Misra@sun.com, yukong Reply-to: Mehrdad.Mojgani@sun.com Message-id: <474F2C2B.5070307@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <474DEEF8.7030801@Sun.COM> <474E0151.30806@Sun.COM> <474E08B3.90803@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 1811 Can we change this to avoid any incompatibility right now? Regards, Mehrdad william clemence - Sun Microsystems - Burlington United States wrote: > Sorry I mis-read the bit in your putback and thought I saw bit 15. > We'll update it when this new interface is incorperated in 7.1. We > need to move a Monza bit too at that time. > > If it gets pushed to go back into the 7.0, which I don't think it we > will need do the adjustment all at once in that gate too. > > > Cindy Wang wrote: > >> >> >> Turgo uses bit 10 for pci bridge on PCI tray, >> In 6.4.1, PCIE-BRIDGE2 should be on bit 10 not bit 15 as in the >> one-pager. Or should the code be changed? >> >> Thanks >> >> cindy >> >> >> Anand Misra wrote: >> >>> Hello: >>> >>> Please make sure the Turgo specific information is correct in this >>> FWARC case. >>> >>> Regards, >>> Anand. >>> >>> ------------------------------------------------------------------------ >>> >>> >>> Subject: >>> Re: FWARC 2007/605 Sun4v VBSC to POST interface >>> From: >>> Stephen Ehring >>> Date: >>> Wed, 28 Nov 2007 16:07:01 -0500 >>> To: >>> Firmware Arch >>> >>> To: >>> Firmware Arch >>> >>> >>> william clemence - Sun Microsystems - Burlington United States wrote: >>> >>>> Section 4 for Glendale is incorrect. The REM should be on bit 9 >>>> not bit 15 as in the one-pager >>>> >>>> >>> The project team has implemented this change. They have also added >>> Turgo and Batoka platforms to the interface document so that >>> follow-on cases are not necessary for those platforms. >>> >>> http://sac.eng/Archives/CaseLog/arc/FWARC/2007/605/materials/sun4v_vbsc_post_interface.txt >>> >>> >>> I've extended the case timer by one day so the case now times out on >>> 12/5/2007. >>> >>> Steve >>> >> From sacadmin Thu Nov 29 13:22:30 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lATLMUca014587 for ; Thu, 29 Nov 2007 13:22:30 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lATLMUOr000975 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Thu, 29 Nov 2007 13:22:30 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSA00709E1G4N00@nwk-avmta-1.sfbay.Sun.COM> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 29 Nov 2007 13:22:28 -0800 (PST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSA002TPE1FXVA0@nwk-avmta-1.sfbay.Sun.COM> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 29 Nov 2007 13:22:27 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lATLMRLd027997 for ; Thu, 29 Nov 2007 21:22:27 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSA00201BG4IS00@mail-amer.sun.com> (original mail from Stephen.Ehring@Sun.COM) for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 29 Nov 2007 14:22:27 -0700 (MST) Received: from [129.148.131.33] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSA00DYLE140HF0@mail-amer.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 29 Nov 2007 14:22:17 -0700 (MST) Date: Thu, 29 Nov 2007 16:22:16 -0500 From: Stephen Ehring Subject: Re: [Fwd: Re: FWARC 2007/605 Sun4v VBSC to POST interface] In-reply-to: <474F2C2B.5070307@Sun.COM> Sender: Stephen.Ehring@sun.com To: Mehrdad.Mojgani@sun.com Cc: William.Clemence@sun.com, Cindy Wang , fwarc@sun.com, Anand.Misra@sun.com, yukong Message-id: <474F2D88.5030903@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <474DEEF8.7030801@Sun.COM> <474E0151.30806@Sun.COM> <474E08B3.90803@Sun.COM> <474F2C2B.5070307@Sun.COM> User-Agent: Thunderbird 2.0.0.10pre (X11/20071125) Status: RO Content-Length: 319 Mehrdad Mojgani wrote: > Can we change this to avoid any incompatibility right now? > I've asked the project team off-line, and they've decided not to make any changes to the spec the way it is currently defined. If there are any other modifications requested for this document, let's discuss them off-line. Steve From sacadmin Thu Nov 29 13:37:48 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lATLbmgW014624 for ; Thu, 29 Nov 2007 13:37:48 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lATLblbm006079 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Thu, 29 Nov 2007 13:37:48 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSA00B1OEQZ1G00@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 29 Nov 2007 13:37:47 -0800 (PST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSA002M2EQY8NC0@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 29 Nov 2007 13:37:46 -0800 (PST) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lATLbkwU028151; Thu, 29 Nov 2007 13:37:46 -0800 (PST) Received: from [192.168.0.3] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lATLbjm8054765; Thu, 29 Nov 2007 13:37:45 -0800 (PST) Date: Thu, 29 Nov 2007 13:37:44 -0800 From: David Kahn Subject: Re: [Fwd: Re: FWARC 2007/605 Sun4v VBSC to POST interface] To: Stephen Ehring Cc: Mehrdad.Mojgani@sun.com, William.Clemence@sun.com, Cindy Wang , fwarc@sun.com, Anand.Misra@sun.com, yukong Message-id: <474F3128.7060709@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 772 I would rather take the time to get it right up front, so all the potential platforms that want to use the interface, can use it. If that means stopping the clock, working offline to get it done, and get the prototyping done, then perhaps that's the right thing to do? (Are we holding any platform up by doing it once, rather than having to do it and then modify it two or three more times later?) -David Stephen Ehring wrote: > Mehrdad Mojgani wrote: >> Can we change this to avoid any incompatibility right now? >> > I've asked the project team off-line, and they've decided not to make > any changes to the spec the way it is currently defined. > > If there are any other modifications requested for this document, let's > discuss them off-line. > > Steve > From sacadmin Fri Nov 30 08:22:37 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lAUGMagK008777 for ; Fri, 30 Nov 2007 08:22:36 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lAUGMS8U023261 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Fri, 30 Nov 2007 16:22:35 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSB0040BUTM3I00@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Fri, 30 Nov 2007 08:22:34 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSB001O0UTLP640@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Fri, 30 Nov 2007 08:22:33 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lAUGMX4F019031 for ; Fri, 30 Nov 2007 08:22:33 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSB00301UNLS100@fe-sfbay-09.sun.com> (original mail from Eric.Blanchard@Sun.COM) for fwarc@sun.com (ORCPT fwarc@sun.com); Fri, 30 Nov 2007 08:22:33 -0800 (PST) Received: from [129.148.9.86] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSB008CJUTJ1P90@fe-sfbay-09.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Fri, 30 Nov 2007 08:22:33 -0800 (PST) Date: Fri, 30 Nov 2007 11:22:31 -0500 From: Eric.Blanchard@sun.com Subject: Re: [Fwd: Re: FWARC 2007/605 Sun4v VBSC to POST interface] In-reply-to: <474F2C2B.5070307@Sun.COM> Sender: Eric.Blanchard@sun.com To: Mehrdad.Mojgani@sun.com Cc: William.Clemence@sun.com, Cindy Wang , Stephen Ehring , fwarc@sun.com, Anand.Misra@sun.com, yukong Message-id: <475038C7.5050101@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <474DEEF8.7030801@Sun.COM> <474E0151.30806@Sun.COM> <474E08B3.90803@Sun.COM> <474F2C2B.5070307@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4v; en-US; rv:1.7) Gecko/20070109 Status: RO Content-Length: 2196 The way the specification was written is we will have to change some incompatitilities now, but it will make implementing the interface cleaner and easier for the current platforms and any platforms in the future. If you want to discuss this more can we take it off-line. -Eric Mehrdad Mojgani wrote: > Can we change this to avoid any incompatibility right now? > Regards, > Mehrdad > > william clemence - Sun Microsystems - Burlington United States wrote: > >> Sorry I mis-read the bit in your putback and thought I saw bit 15. >> We'll update it when this new interface is incorperated in 7.1. We >> need to move a Monza bit too at that time. >> >> If it gets pushed to go back into the 7.0, which I don't think it we >> will need do the adjustment all at once in that gate too. >> >> >> Cindy Wang wrote: >> >>> >>> >>> Turgo uses bit 10 for pci bridge on PCI tray, >>> In 6.4.1, PCIE-BRIDGE2 should be on bit 10 not bit 15 as in the >>> one-pager. Or should the code be changed? >>> >>> Thanks >>> >>> cindy >>> >>> >>> Anand Misra wrote: >>> >>>> Hello: >>>> >>>> Please make sure the Turgo specific information is correct in this >>>> FWARC case. >>>> >>>> Regards, >>>> Anand. >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> Subject: >>>> Re: FWARC 2007/605 Sun4v VBSC to POST interface >>>> From: >>>> Stephen Ehring >>>> Date: >>>> Wed, 28 Nov 2007 16:07:01 -0500 >>>> To: >>>> Firmware Arch >>>> >>>> To: >>>> Firmware Arch >>>> >>>> >>>> william clemence - Sun Microsystems - Burlington United States wrote: >>>> >>>>> Section 4 for Glendale is incorrect. The REM should be on bit 9 >>>>> not bit 15 as in the one-pager >>>>> >>>>> >>>> The project team has implemented this change. They have also added >>>> Turgo and Batoka platforms to the interface document so that >>>> follow-on cases are not necessary for those platforms. >>>> >>>> http://sac.eng/Archives/CaseLog/arc/FWARC/2007/605/materials/sun4v_vbsc_post_interface.txt >>>> >>>> >>>> I've extended the case timer by one day so the case now times out >>>> on 12/5/2007. >>>> >>>> Steve >>>> >>> From sacadmin Fri Nov 30 08:29:59 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lAUGTwgV009084 for ; Fri, 30 Nov 2007 08:29:59 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lAUGTubs027316 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Fri, 30 Nov 2007 16:29:58 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSB00403V5XD400@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Fri, 30 Nov 2007 08:29:57 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSB001Y6V5WP940@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Fri, 30 Nov 2007 08:29:56 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lAUGTuSv014625 for ; Fri, 30 Nov 2007 08:29:56 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSB00601V1NJX00@fe-sfbay-10.sun.com> (original mail from Eric.Blanchard@Sun.COM) for fwarc@sun.com (ORCPT fwarc@sun.com); Fri, 30 Nov 2007 08:29:56 -0800 (PST) Received: from [129.148.9.86] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSB00J96V5U9MB0@fe-sfbay-10.sun.com>; Fri, 30 Nov 2007 08:29:56 -0800 (PST) Date: Fri, 30 Nov 2007 11:29:54 -0500 From: Eric.Blanchard@sun.com Subject: Re: [Fwd: Re: FWARC 2007/605 Sun4v VBSC to POST interface] In-reply-to: <474F3128.7060709@sun.com> Sender: Eric.Blanchard@sun.com To: David Kahn Cc: Stephen Ehring , Mehrdad.Mojgani@sun.com, William.Clemence@sun.com, Cindy Wang , fwarc@sun.com, Anand.Misra@sun.com, yukong Message-id: <47503A82.9080505@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <474F3128.7060709@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4v; en-US; rv:1.7) Gecko/20070109 Status: RO Content-Length: 1228 David Kahn wrote: > > I would rather take the time to get it right > up front, so all the potential platforms that want > to use the interface, can use it. > > If that means stopping the clock, working offline > to get it done, and get the prototyping done, > then perhaps that's the right thing to do? I don't think stoping the clock right now is the best idea. Right now the project team thinks the current specification is the best way to move forward with the POST interface. I don't think the case timer should stop unless the project team agrees we want to change the specification. > > (Are we holding any platform up by doing it once, > rather than having to do it and then modify it > two or three more times later?) Maramba is POST is waiting for the case to be approved so it can putback to the 4.x gate. -Eric > > -David > > > Stephen Ehring wrote: > >> Mehrdad Mojgani wrote: >> >>> Can we change this to avoid any incompatibility right now? >>> >> I've asked the project team off-line, and they've decided not to make >> any changes to the spec the way it is currently defined. >> >> If there are any other modifications requested for this document, >> let's discuss them off-line. >> >> Steve >> From sacadmin Fri Nov 30 11:32:36 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lAUJWZg0015919 for ; Fri, 30 Nov 2007 11:32:36 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lAUJWZc4020138 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Fri, 30 Nov 2007 19:32:35 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSC00C013MAJP00@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Fri, 30 Nov 2007 11:32:34 -0800 (PST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSC00BZQ3MA9530@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Fri, 30 Nov 2007 11:32:34 -0800 (PST) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lAUJWX6B001675; Fri, 30 Nov 2007 11:32:33 -0800 (PST) Received: from [192.168.0.3] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lAUJWWb5082832; Fri, 30 Nov 2007 11:32:32 -0800 (PST) Date: Fri, 30 Nov 2007 11:32:31 -0800 From: David Kahn Subject: Re: [Fwd: Re: FWARC 2007/605 Sun4v VBSC to POST interface] In-reply-to: <47503A82.9080505@Sun.COM> To: Eric.Blanchard@sun.com Cc: Stephen Ehring , Mehrdad.Mojgani@sun.com, William.Clemence@sun.com, Cindy Wang , fwarc@sun.com, Anand.Misra@sun.com, yukong Message-id: <4750654F.5050100@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <474F3128.7060709@sun.com> <47503A82.9080505@Sun.COM> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 2154 Eric.Blanchard@sun.com wrote: > I don't think stoping the clock right now is the best idea. Right now > the project team thinks the current specification is the best way to > move forward with the POST interface. I don't think the case timer > should stop unless the project team agrees we want to change the > specification. > >> >> (Are we holding any platform up by doing it once, >> rather than having to do it and then modify it >> two or three more times later?) > > > Maramba is POST is waiting for the case to be approved so it can putback > to the 4.x gate. I'm fine with Stephen sorting this out, but there were some changes that I don't think are reflected in the document and some people (not ARC members, I assumed they were either project members or stakeholders) had objected and pointed out that some bits specified needed to be moved for compatibility with other platforms. The question is, should FWARC insist that you deal with these issues before approval or not? Typically we expect the project teams to have done this sort of thing before the project is submitted for fast-track review. fast-track review is used when there's no need for TCRs/TCAs or an opinion. Personally, I'd prefer that the project team deal with it themselves rather than the ARC having to derail the case and insist on it. That's why I suggested stopping the clock. To give you time to sort this out, update the materials and then we can simply restart the fast-track timeout clock. The timeout is currently set to Dec 5. Before we get to Dec 5, we need to know that everything has been updated and sorted out between the project team and other people that intend to build on this project. One way to deal with it is to just accept this the way it is and then make incompatible changes in the future, I suppose. (and that can be done, it just requires a sysfw flag day, I suppose) but it might be better to do what can be done now (knowing what we know now) so that changes and additions can be done in a more compatible manner for newer platforms. I'll leave it up to Stephen to sort this out. (I'll be on vacation from Dec 4 - 11.) -David From sacadmin Fri Nov 30 11:55:27 2007 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lAUJtQRT016769 for ; Fri, 30 Nov 2007 11:55:27 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lAUJtO2H000687 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Sat, 1 Dec 2007 03:55:25 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSC00D034OCOW00@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Fri, 30 Nov 2007 11:55:24 -0800 (PST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSC00BGZ4OC9380@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Fri, 30 Nov 2007 11:55:24 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAUJtO1Y025639 for ; Fri, 30 Nov 2007 19:55:24 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSC00A013CYSV00@mail-amer.sun.com> (original mail from William.Clemence@Sun.COM) for fwarc@sun.com (ORCPT fwarc@sun.com); Fri, 30 Nov 2007 12:55:24 -0700 (MST) Received: from [129.148.9.176] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSC004MA4NXUD80@mail-amer.sun.com>; Fri, 30 Nov 2007 12:55:15 -0700 (MST) Date: Fri, 30 Nov 2007 14:55:09 -0500 From: william clemence - Sun Microsystems - Burlington United States Subject: Re: [Fwd: Re: FWARC 2007/605 Sun4v VBSC to POST interface] In-reply-to: <4750654F.5050100@sun.com> Sender: William.Clemence@sun.com To: David Kahn Cc: Eric.Blanchard@sun.com, Stephen Ehring , Mehrdad.Mojgani@sun.com, Cindy Wang , fwarc@sun.com, Anand.Misra@sun.com, yukong Reply-to: William.Clemence@sun.com Message-id: <47506A9D.30309@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <474F3128.7060709@sun.com> <47503A82.9080505@Sun.COM> <4750654F.5050100@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4v; en-US; rv:1.7) Gecko/20070606 Status: RO Content-Length: 2708 David, I am sorry that I derailed this fast track.... I was wrong to do so and the document as it stands is fine by me and fine by Cindy. Maramba is waiting for this FWARC for the putbacks to 7.1 (I forgot that they were) and I don't want that derailed or delayed anymore. As I have noted before we need to be doing an RTI to put this back to 7.0 and at that time we will adjust the extra different bits then to fit this FWARC. Bill David Kahn wrote: > > > Eric.Blanchard@sun.com wrote: > >> I don't think stoping the clock right now is the best idea. Right now >> the project team thinks the current specification is the best way to >> move forward with the POST interface. I don't think the case timer >> should stop unless the project team agrees we want to change the >> specification. >> >>> >>> (Are we holding any platform up by doing it once, >>> rather than having to do it and then modify it >>> two or three more times later?) >> >> >> >> Maramba is POST is waiting for the case to be approved so it can >> putback to the 4.x gate. > > > I'm fine with Stephen sorting this out, but there were some > changes that I don't think are reflected in the document and > some people (not ARC members, I assumed they were either > project members or stakeholders) had objected and pointed out > that some bits specified needed to be moved for compatibility > with other platforms. > > The question is, should FWARC insist that you deal with these > issues before approval or not? Typically we expect the project > teams to have done this sort of thing before the project is > submitted for fast-track review. fast-track review is used > when there's no need for TCRs/TCAs or an opinion. > > Personally, I'd prefer that the project team deal with it > themselves rather than the ARC having to derail the case and > insist on it. That's why I suggested stopping the clock. > To give you time to sort this out, update the materials and > then we can simply restart the fast-track timeout clock. > > The timeout is currently set to Dec 5. Before we get > to Dec 5, we need to know that everything has been updated > and sorted out between the project team and other people > that intend to build on this project. One way to deal > with it is to just accept this the way it is and then > make incompatible changes in the future, I suppose. > (and that can be done, it just requires a sysfw flag > day, I suppose) but it might be better to do what can > be done now (knowing what we know now) so that changes > and additions can be done in a more compatible manner > for newer platforms. > > I'll leave it up to Stephen to sort this out. > (I'll be on vacation from Dec 4 - 11.) > > -David > From sacadmin Mon Dec 3 18:23:30 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lB42NTt4015479 for ; Mon, 3 Dec 2007 18:23:29 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lB42NQ1a027550 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Tue, 4 Dec 2007 02:23:28 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSI00A0B6N17P00@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Mon, 03 Dec 2007 18:23:25 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSI001ZB6N1DC90@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Mon, 03 Dec 2007 18:23:25 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lB42NPAh012631 for ; Mon, 03 Dec 2007 18:23:25 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSI00J016L8MP00@fe-sfbay-10.sun.com> (original mail from Hitendra.Zhangada@Sun.COM) for fwarc@sun.com (ORCPT fwarc@sun.com); Mon, 03 Dec 2007 18:23:25 -0800 (PST) Received: from [129.153.85.10] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSI00JMB6N0KFE0@fe-sfbay-10.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Mon, 03 Dec 2007 18:23:25 -0800 (PST) Date: Mon, 03 Dec 2007 18:23:24 -0800 From: Hitendra Zhangada Subject: Re: FWARC 2007/605 Sun4v VBSC to POST interface In-reply-to: <474C7713.30303@sun.com> Sender: Hitendra.Zhangada@Sun.COM To: Firmware Arch Message-id: <4754BA1C.8080102@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47193117.4070805@sun.com> <474C7713.30303@sun.com> User-Agent: Thunderbird 2.0.0.10pre (X11/20071125) Status: RO Content-Length: 3385 Stephen Ehring wrote: > David Kahn wrote: >> >> >> Hitendra Zhangada wrote: >> >> >>> Note that changing an interface is not the same as deprecating it. >>> If you are changing how an existing interface works then the original >>> interface is NOT deprecated but rather modified by your case. >> >> My understanding is that the old interface will be replaced >> by the new one. In ARC terms, they are deprecating the old >> interface and creating a new interface to replace the old >> one, and that this case will fully describe that interface >> and the old materials in the old cases will effectively be >> obsolete except as they pertain to older firmware already >> released. Any newer releases will use the new interfaces >> defined by this case (after approval and integration.) > That is correct. The project team is requesting we deprecate the old > interfaces (specified by the cases called out in section 4 of the > onepager). These interfaces were never fully implemented and were > insufficient for the data that needed to be communicated between POST > and VBSC. > > The project team has updated the specification based on feedback from > DavidK and Hitendra. I'm re-starting the timer which will time out on > 12/4 unless there are other issues raised that need to be resolved. > > http://sac.eng/Archives/CaseLog/arc/FWARC/2007/605/materials/onepager.txt > > Updated spec here: > > http://sac.eng/Archives/CaseLog/arc/FWARC/2007/605/materials/sun4v_vbsc_post_interface.txt > Is there a reason to not put the platform specific constants in one structure? It seems like information such as, # of nodes, # of thread status/result words, # of XAUI etc. is hard coded on each platform. If we have two flavors of the same system, e.g. Maramba with 1 node, or Monza/Huron with 32 threads, then it seems like post will have to change too. I am just trying to understand downside of having a structure which spells out all of these platforms specific information. vBSC can copy this information and POST can use it. Does the order of all of the structures part of POST interface data (section 2) match the order in the specification? I am trying to see over all data structure and also thinking about how this structure can be extended for future. If I were to add some device info in addition to XAUI where can it go? I think it will go at the tail-end of the current structure, past POST exit info (in section 2.2), right? Deprecation of earlier structures needs to be listed in the interface table section of the one-pager. This will be section 4.4 of the one-pager. I thought the structures shared by N1 platforms are not modified (the new interfaces applies to N2 and VF based platforms only). If this is true then does the deprecated structures still valid for N1 systems? If this is the case then that needs to be clarified (that interfaces for N2 based platforms are deprecated and replaced with new interfaces but N1 based platforms will continue to use the structures). I am little unclear in this area, please clarify. Sorry for late review/reply on this case. I don't expect any of my questions to delay this case. Thanks. -- Hitendra Zhangada ==================================== SPS Common SW Features Engineering Software Group, Sun Microsystems, Inc. From sacadmin Tue Dec 4 08:28:49 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lB4GSn3d029258 for ; Tue, 4 Dec 2007 08:28:49 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lB4GSn9r023143 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Tue, 4 Dec 2007 08:28:49 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSJ0090L9RZUF00@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 04 Dec 2007 09:28:47 -0700 (MST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSJ006N89RYC330@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 04 Dec 2007 09:28:46 -0700 (MST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lB4GSklB003834 for ; Tue, 04 Dec 2007 16:28:46 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSJ00601865CI00@mail-amer.sun.com> (original mail from Stephen.Ehring@Sun.COM) for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 04 Dec 2007 09:28:46 -0700 (MST) Received: from [129.148.131.33] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSJ008Y49RPKXC0@mail-amer.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 04 Dec 2007 09:28:38 -0700 (MST) Date: Tue, 04 Dec 2007 11:28:37 -0500 From: Stephen Ehring Subject: Re: FWARC 2007/605 Sun4v VBSC to POST interface In-reply-to: <4754BA1C.8080102@sun.com> Sender: Stephen.Ehring@sun.com To: Firmware Arch Message-id: <47558035.7070006@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47193117.4070805@sun.com> <474C7713.30303@sun.com> <4754BA1C.8080102@sun.com> User-Agent: Thunderbird 2.0.0.10pre (X11/20071202) Status: RO Content-Length: 4063 Hitendra Zhangada wrote: > Is there a reason to not put the platform specific constants > in one structure? It seems like information such as, > # of nodes, # of thread status/result words, # of XAUI etc. > is hard coded on each platform. If we have two flavors > of the same system, e.g. Maramba with 1 node, or > Monza/Huron with 32 threads, then it seems like post > will have to change too. I am just trying to understand > downside of having a structure which spells out all of > these platforms specific information. vBSC can copy > this information and POST can use it. > The # nodes, threads, IO devices, etc is hard coded since that information is platform-specific. We cannot predict what type of information POST may need in the future so having a platform-specific structure allows us to change what info we give POST on a per-platform basis. If the hardware changes, POST will have to change, too. POST knows what the structure format is based on the Host Type we pass in. > Does the order of all of the structures part of POST interface > data (section 2) match the order in the specification? I am > trying to see over all data structure and also thinking about > how this structure can be extended for future. If I were > to add some device info in addition to XAUI where can > it go? I think it will go at the tail-end of the current structure, > past POST exit info (in section 2.2), right? New elements can be added to section 2, and then the per-platform data in section 3 can add them to the structure. Where the elements get added in section 2 depends on what the elements are. For example, section 2.2 outlines the POST exit info, so if we add any information communicated from POST to the vbsc, it would go in section 2.2. Section 2.1 outlines the POST entry info, so if we were to pass POST any additional information from the vbsc it would go in section 2.1. Each subsection of 2.1 outlines a different type of information which vbsc communicates to POST. If you were to add additional machine information field such as XAUI info, it would go in section 2.1.1 > > Deprecation of earlier structures needs to be listed in > the interface table section of the one-pager. This will be > section 4.4 of the one-pager. > Updated the interface table to import the depreciated interfaces as 'obsolete uncommitted'. > > I thought the structures shared by N1 platforms are > not modified (the new interfaces applies to N2 and > VF based platforms only). If this is true then does > the deprecated structures still valid for N1 systems? > If this is the case then that needs to be clarified (that > interfaces for N2 based platforms are deprecated and > replaced with new interfaces but N1 based platforms > will continue to use the structures). I am little unclear > in this area, please clarify. I've updated to onepager to explicitly state that we are only obsoleting the interfaces for Niagara2 and VF based platforms. There are no plans to back port these changes to N1 based systems. Updated onepager and diffs: http://sac.eng/Archives/CaseLog/arc/FWARC/2007/605/materials/onepager.txt sac: /export/sac/FWARC/2007/605 50> diff materials/onepager.txt old.materials/o nepager.txt-v2 51,52c51 < 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 s ystems. --- > and [5]. 76,85d74 < Imported 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 < From sacadmin Tue Dec 4 17:45:19 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lB51jJeP018695 for ; Tue, 4 Dec 2007 17:45:19 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lB51jJpU029948 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Tue, 4 Dec 2007 17:45:19 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSJ00503ZJI1A00@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 04 Dec 2007 17:45:18 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSJ00M9ZZJHIN50@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 04 Dec 2007 17:45:17 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lB51jHrq010255 for ; Tue, 04 Dec 2007 17:45:17 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSJ00801ZELAT00@fe-sfbay-09.sun.com> (original mail from Hitendra.Zhangada@Sun.COM) for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 04 Dec 2007 17:45:17 -0800 (PST) Received: from [129.153.85.10] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSJ00204ZJFTA60@fe-sfbay-09.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 04 Dec 2007 17:45:16 -0800 (PST) Date: Tue, 04 Dec 2007 17:45:15 -0800 From: Hitendra Zhangada Subject: Re: FWARC 2007/605 Sun4v VBSC to POST interface In-reply-to: <47558035.7070006@sun.com> Sender: Hitendra.Zhangada@Sun.COM To: Firmware Arch Message-id: <475602AB.70100@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47193117.4070805@sun.com> <474C7713.30303@sun.com> <4754BA1C.8080102@sun.com> <47558035.7070006@sun.com> User-Agent: Thunderbird 2.0.0.10pre (X11/20071202) Status: RO Content-Length: 7487 Stephen Ehring wrote: > Hitendra Zhangada wrote: >> Is there a reason to not put the platform specific constants >> in one structure? It seems like information such as, >> # of nodes, # of thread status/result words, # of XAUI etc. >> is hard coded on each platform. If we have two flavors >> of the same system, e.g. Maramba with 1 node, or >> Monza/Huron with 32 threads, then it seems like post >> will have to change too. I am just trying to understand >> downside of having a structure which spells out all of >> these platforms specific information. vBSC can copy >> this information and POST can use it. >> > > The # nodes, threads, IO devices, etc is hard coded since that > information is platform-specific. We cannot predict what type of > information POST may need in the future so having a platform-specific > structure allows us to change what info we give POST on a per-platform > basis. That works but I think a better thing to do would be to have a structure defined fields for these sort of information. This way, vBSC passes this on to POST based on Host Type. If new devices are added then that structures gets updated along with other structures. This is something we can look in future to implement, for now I am fine the way it is. > > If the hardware changes, POST will have to change, too. POST knows > what the structure format is based on the Host Type we pass in. > >> Does the order of all of the structures part of POST interface >> data (section 2) match the order in the specification? I am >> trying to see over all data structure and also thinking about >> how this structure can be extended for future. If I were >> to add some device info in addition to XAUI where can >> it go? I think it will go at the tail-end of the current structure, >> past POST exit info (in section 2.2), right? > > New elements can be added to section 2, and then the per-platform data > in section 3 can add them to the structure. Where the elements get > added in section 2 depends on what the elements are. > I am not concerned with where in the document they gets added but I am more concerned with the data structure, e.g., "C" structure, POST and/or vBSC is going to consume. The specification does not have that structure. So, my assumption is that the order of information in the specification will be the same in the data structure as well. Otherwise, the specification describes elements of the structure and not the structure itself. The interface between POST and vBSC is the overall data structures each side consumes. If the flow of the information matches that of data structure then please add that to the specification so that in future someone do not add a section and not add the element in the data structure at the same location as the specification. If the flow of information does not match then we have problem with the interface definition. The interface is the "POST interface structure data format" not the individual elements. > For example, section 2.2 outlines the POST exit info, so if we add any > information communicated from POST to the vbsc, it would go in section > 2.2. Section 2.1 outlines the POST entry info, so if we were to pass > POST any additional information from the vbsc it would go in section > 2.1. Each subsection of 2.1 outlines a different type of information > which vbsc communicates to POST. If you were to add additional machine > information field such as XAUI info, it would go in section 2.1.1 > >> >> Deprecation of earlier structures needs to be listed in >> the interface table section of the one-pager. This will be >> section 4.4 of the one-pager. >> > > Updated the interface table to import the depreciated interfaces as > 'obsolete uncommitted'. FYI. This case obsoletes set of previous interfaces and so those will need to go into exported interfaces. There are two interfaces we need to list. First one is "POST Entry Info" (section 2.1) and other is "POST Exit Info" (section 2.2). I think we should separate them as two interfaces. This way either one can change independent of the other. Further, there are two interfaces here since one is consumed by POST and other by vBSC. Lets put that detail in the comments section along with section number. Something like the followings, 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 Info uncommitted Data structure generated by vBSC data structure and consumed by POST, section 2.1 POST Exit Info uncommitted Data structure generated by POST data structure and consumed by vBSC, section 2.2 > >> >> I thought the structures shared by N1 platforms are >> not modified (the new interfaces applies to N2 and >> VF based platforms only). If this is true then does >> the deprecated structures still valid for N1 systems? >> If this is the case then that needs to be clarified (that >> interfaces for N2 based platforms are deprecated and >> replaced with new interfaces but N1 based platforms >> will continue to use the structures). I am little unclear >> in this area, please clarify. > > I've updated to onepager to explicitly state that we are only > obsoleting the interfaces for Niagara2 and VF based platforms. There > are no plans to back port these changes to N1 based systems. > > Updated onepager and diffs: > > http://sac.eng/Archives/CaseLog/arc/FWARC/2007/605/materials/onepager.txt > > sac: /export/sac/FWARC/2007/605 50> diff materials/onepager.txt > old.materials/o nepager.txt-v2 > 51,52c51 > < 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 s ystems. > --- > > and [5]. > 76,85d74 > < Imported 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 > < > -- Hitendra Zhangada ==================================== SPS Common SW Features Engineering Software Group, Sun Microsystems, Inc. From sacadmin Wed Dec 5 08:31:55 2007 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lB5GVsOK002986 for ; Wed, 5 Dec 2007 08:31:55 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lB5GVlOF000187 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Thu, 6 Dec 2007 00:31:53 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSL00L0X4L3VK00@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@Sun.com); Wed, 05 Dec 2007 08:31:51 -0800 (PST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSL00IIX4L0RO60@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@Sun.com); Wed, 05 Dec 2007 08:31:48 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lB5GVlZB001552 for ; Wed, 05 Dec 2007 16:31:47 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSL00M0123LYF00@mail-amer.sun.com> (original mail from Stephen.Ehring@Sun.COM) for fwarc@Sun.com (ORCPT fwarc@Sun.com); Wed, 05 Dec 2007 09:31:47 -0700 (MST) Received: from [129.148.131.33] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSL009QT4KNT950@mail-amer.sun.com> for fwarc@Sun.com (ORCPT fwarc@Sun.com); Wed, 05 Dec 2007 09:31:36 -0700 (MST) Date: Wed, 05 Dec 2007 11:31:35 -0500 From: Stephen Ehring Subject: Re: FWARC 2007/605 Sun4v VBSC to POST interface In-reply-to: <475602AB.70100@sun.com> Sender: Stephen.Ehring@sun.com To: Firmware Arch Message-id: <4756D267.9060500@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47193117.4070805@sun.com> <474C7713.30303@sun.com> <4754BA1C.8080102@sun.com> <47558035.7070006@sun.com> <475602AB.70100@sun.com> User-Agent: Thunderbird 2.0.0.10pre (X11/20071202) Status: RO Content-Length: 8825 Hitendra Zhangada wrote: > > I am not concerned with where in the document they gets added but > I am more concerned with the data structure, e.g., "C" structure, > POST and/or vBSC is going to consume. The specification does > not have that structure. This was intentional: we are defining a bit array in the sram, and not a "C" structure. The fact that both consumers of the interface are implemented in "C" does not matter. > So, my assumption is that the order of > information in the specification will be the same in the data structure > as well. Otherwise, the specification describes elements of the > structure and not the structure itself. The interface between POST > and vBSC is the overall data structures each side consumes. > You don't need to make any assumptions. The elements are defined in section 2, then section 3 and onward shows the order and number of each of the elements on a per-platform basis. > If the flow of the information matches that of data structure > then please add that to the specification so that in future someone > do not add a section and not add the element in the data structure > at the same location as the specification. > If the flow of information does not match then we have problem > with the interface definition. The interface is the "POST interface > structure data format" not the individual elements. I think the flow of information you are talking about is what is defined in sections 3+. The reason we are writing the spec like this is because not all platforms will want to use all of the elements, and different platforms will have different quantities of the elements. Therefore we describe the elements and their meaning, then for each platform, we define the bit layout and where the elements can be found. >> >> Updated the interface table to import the depreciated interfaces as >> 'obsolete uncommitted'. > > FYI. This case obsoletes set of previous interfaces and so those will > need to go into exported interfaces. > > There are two interfaces we need to list. First one is "POST Entry Info" > (section 2.1) and other is "POST Exit Info" (section 2.2). I think we > should separate them as two interfaces. This way either one can change > independent of the other. Further, there are two interfaces here > since one > is consumed by POST and other by vBSC. Lets put that detail in the > comments section along with section number. Something like the > followings, I've moved the obsoleting interface to exported. I've also updated section 4 to better clarify that the per-platform array is actually defined in the following sections, and not in the section that describes each element in detail (I think that's the confusion we have here). Let me know if this is okay, or if I should extend the timer to give more time for review. Steve http://sac.eng/Archives/CaseLog/arc/FWARC/2007/605/materials/onepager.txt 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/ From sacadmin Wed Dec 5 10:47:29 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lB5IlSUp009853 for ; Wed, 5 Dec 2007 10:47:28 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lB5IlK6R014052 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Wed, 5 Dec 2007 18:47:27 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSL00L07AV1W000@nwk-avmta-1.sfbay.Sun.COM> for fwarc@sun.com (ORCPT fwarc@sun.com); Wed, 05 Dec 2007 10:47:25 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSL00ICZAV0UJ10@nwk-avmta-1.sfbay.Sun.COM> for fwarc@sun.com (ORCPT fwarc@sun.com); Wed, 05 Dec 2007 10:47:24 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lB5IlOjQ029296 for ; Wed, 05 Dec 2007 10:47:24 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSL00D01ANDR500@fe-sfbay-09.sun.com> (original mail from Hitendra.Zhangada@Sun.COM) for fwarc@sun.com (ORCPT fwarc@sun.com); Wed, 05 Dec 2007 10:47:24 -0800 (PST) Received: from [129.150.34.246] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSL00JE9AUPPS00@fe-sfbay-09.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Wed, 05 Dec 2007 10:47:14 -0800 (PST) Date: Wed, 05 Dec 2007 10:48:54 -0800 From: Hitendra Zhangada Subject: Re: FWARC 2007/605 Sun4v VBSC to POST interface In-reply-to: <4756D267.9060500@sun.com> Sender: Hitendra.Zhangada@Sun.COM To: Firmware Arch Message-id: <4756F296.3000907@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47193117.4070805@sun.com> <474C7713.30303@sun.com> <4754BA1C.8080102@sun.com> <47558035.7070006@sun.com> <475602AB.70100@sun.com> <4756D267.9060500@sun.com> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 9691 Stephen Ehring wrote: > Hitendra Zhangada wrote: >> >> I am not concerned with where in the document they gets added but >> I am more concerned with the data structure, e.g., "C" structure, >> POST and/or vBSC is going to consume. The specification does >> not have that structure. > This was intentional: we are defining a bit array in the sram, and not > a "C" structure. The fact that both consumers of the interface are > implemented in "C" does not matter. > >> So, my assumption is that the order of >> information in the specification will be the same in the data structure >> as well. Otherwise, the specification describes elements of the >> structure and not the structure itself. The interface between POST >> and vBSC is the overall data structures each side consumes. >> > > You don't need to make any assumptions. The elements are defined in > section 2, then section 3 and onward shows the order and number of > each of the elements on a per-platform basis. Yes, that's what I was missing. Thanks for the clarification. I also like additions to the interface table for each platform. This way we can add more platforms as long as general post entry/exit data element definition is the same. This case is a go from my stand point, it can time out today. Thanks. > >> If the flow of the information matches that of data structure >> then please add that to the specification so that in future someone >> do not add a section and not add the element in the data structure >> at the same location as the specification. >> If the flow of information does not match then we have problem >> with the interface definition. The interface is the "POST interface >> structure data format" not the individual elements. > > I think the flow of information you are talking about is what is > defined in sections 3+. > > The reason we are writing the spec like this is because not all > platforms will want to use all of the elements, and different > platforms will have different quantities of the elements. Therefore we > describe the elements and their meaning, then for each platform, we > define the bit layout and where the elements can be found. > >>> >>> Updated the interface table to import the depreciated interfaces as >>> 'obsolete uncommitted'. >> >> FYI. This case obsoletes set of previous interfaces and so those will >> need to go into exported interfaces. >> >> There are two interfaces we need to list. First one is "POST Entry >> Info" >> (section 2.1) and other is "POST Exit Info" (section 2.2). I think we >> should separate them as two interfaces. This way either one can change >> independent of the other. Further, there are two interfaces here >> since one >> is consumed by POST and other by vBSC. Lets put that detail in the >> comments section along with section number. Something like the >> followings, > > I've moved the obsoleting interface to exported. I've also updated > section 4 to better clarify that the per-platform array is actually > defined in the following sections, and not in the section that > describes each element in detail (I think that's the confusion we have > here). Let me know if this is okay, or if I should extend the timer to > give more time for review. > > Steve > > http://sac.eng/Archives/CaseLog/arc/FWARC/2007/605/materials/onepager.txt > > 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/ > > > -- Hitendra Zhangada ============================================= SPS Common SW Features Engineering Software Group, Sun Microsystems, Inc. From sacadmin Thu Dec 6 07:08:47 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lB6F8ktD002524 for ; Thu, 6 Dec 2007 07:08:46 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lB6F8jl1017017 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Thu, 6 Dec 2007 07:08:46 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSM00107VEMSY00@nwk-avmta-1.sfbay.Sun.COM> for fwarc@sun.com (ORCPT fwarc@Sun.com); Thu, 06 Dec 2007 07:08:46 -0800 (PST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSM000Z0VELEK00@nwk-avmta-1.sfbay.Sun.COM> for fwarc@sun.com (ORCPT fwarc@Sun.com); Thu, 06 Dec 2007 07:08:45 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lB6F8jZd015993 for ; Thu, 06 Dec 2007 15:08:45 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSM00501UJV8A00@mail-amer.sun.com> (original mail from Stephen.Ehring@Sun.COM) for fwarc@Sun.com (ORCPT fwarc@Sun.com); Thu, 06 Dec 2007 08:08:45 -0700 (MST) Received: from [129.148.131.33] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSM00KCLVE9YY90@mail-amer.sun.com> for fwarc@Sun.com (ORCPT fwarc@Sun.com); Thu, 06 Dec 2007 08:08:34 -0700 (MST) Date: Thu, 06 Dec 2007 10:08:33 -0500 From: Stephen Ehring Subject: Re: FWARC 2007/605 Sun4v VBSC to POST interface In-reply-to: <4756D267.9060500@sun.com> Sender: Stephen.Ehring@sun.com To: Firmware Arch Message-id: <47581071.2000904@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47193117.4070805@sun.com> <474C7713.30303@sun.com> <4754BA1C.8080102@sun.com> <47558035.7070006@sun.com> <475602AB.70100@sun.com> <4756D267.9060500@sun.com> User-Agent: Thunderbird 2.0.0.10pre (X11/20071202) Status: RO Content-Length: 144 The timer for this case has expired, it is closed as approved. The interfaces can be released in a micro/minor version of the firmware. Steve