- Problem Statement: 

Explanation of LPOST versioning policy.  NOTE: Mixed Minor numbers, 5.13.2 vs. 5.13.1
 

There are two types of LPOST images: 

1.  FPROM (Flash Programmable Read-Only Memory) images:  CPU LPOST is located in the FPROMs on
System Boards and Dual-CPU Boards. FPROM images contain several segments. Each segment contains
a segment name which identifies the segment contents as well as version information:

            Architecture number
            Major number
            Minor number
            Day and Date information

2.  ELF (Executable and Linking Format) images:  All I/O LPOST images (PCI, WCI, and EXB LPOST)
are ELF files which are stored on the SC's disk and downloaded to memory (DRAM) for execution
as needed.

Version Policy
--------------

Policies have been established according to developmental restrictions, qualification restrictions,
and best practices which dictate what versions are accepted and what mixes of versions are allowed.
The following are the policies as enforced by hpost.

In most cases, the basis from which these policies operate are tables within hpost which enumerate
every known, tested, supported version of the particular LPOST image to which it corresponds. These
tables are up-to-date at the time that the hpost image is built and released. New versions of LPOST 
an always be released between hpost releases, and thus those new LPOST versions would not be found
in the tables. Policies exist to handle these circumstances as indicated below. 

There are three principal numbers which comprise the version number of a particular LPOST image: 

        architecture_number.major_number.minor_number e.g.  5.13.0

Starting with FPROM version 5.13.0, there are additional pieces of information which are placed
in the version segment of the FPROM image. The most interesting of this information is: 

        main build.variant_build interface number     e.g.    5.13.0 Build 37.0 I/F 12

Architecture Number
-------------------

        The Architecture Number must, for the life of the product, be five (5). 
        Any version with an Architecture Number other than five (5) is rejected.
        There is no .postrc command which will allow this to be overridden. 

Major Number
------------

        If the Major Number is a supported value (i.e., is in hpost's version table for the
        corresponding LPOST image), then it is accepted. Uprev'd and Downrev'd Major Numbers
        are rejected.  The .postrc lpost_version_allow can be used to force acceptance of an
        otherwise rejected version. 

Minor Number
------------

        If the Minor Number is a supported value (i.e., is in hpost's version table for the
        corresponding LPOST image) then it is accepted. Uprev'd versions are accepted with
        a "NOTE" message printed. Downrev'd version are rejected. 

Build Number
------------

        Build numbers are checked against hpost's table as well but only for two explicit cases:

        1.  To determine if the particular build is known to be bad
        2.  To see if the build is an Uprev'd version from the the table's known supported versions.

        In the first case the version is explicitly failed (though it can be overridden via .postrc).
        In the second case the version will be allowed with a "NOTE" indicating it is Uprev'd. 

Variant Number
--------------

        No checks are performed against the Variant Build number, and the Variant Build cannot
        be specified in via any of the .postrc commands. 

Interface Number
----------------

        The Interface Number is checked against hpost's version table for the corresponding
        LPOST image and is only accepted if there is an exact match. Uprev'd and Downrev'd
        versions are rejected. 

Mixing Major Numbers
--------------------

        While not recommended, mixing Major numbers amongst the various LPOST images is
        accepted. By default the policy is to output "WARNING" messages for these situations. 

Mixing Minor Numbers
--------------------

        While not preferred, mixing Minor numbers amongst the various LPOST images is accepted.
        By default the policy is to output "NOTE" messages for these situations. 

Mixing Interface Numbers
------------------------

        Mixing of Interface numbers is not allowed under any circumstances. If Interface numbers
        are mixed amongst the various LPOST images, the image is rejected. 

Mixing Build/Variant Numbers
----------------------------

        There are no restrictions on mixing Build and Variant numbers. All mixtures will be
        accepted.             

- Troubleshooting:

You can determine version information by two methods for FPROMs: 

        1.  Via flashupdate (1M)
        2.  Via redx

You can determine version information for ELF images:
 
        1.  Via mcs
   
Here is an example which shows the intial output from flashupdate:

mufasa-sc0:sms-svc:7> flashupdate -f /opt/SUNWSMS/hostobjs/sgcpu.flash SB0/FP0

Current System Board FPROM Information 
======================================
CPU at SB0, FPROM 0:
POST   05/31/02 04:36:00 PM  Release 5.13.1  Build 2.0 I/F 12
OBP    05/31/02 04:36:00 PM  Release 5.13.1  Build 2.0 
Ver    05/31/02 04:36:00 PM  Release 5.13.1  Build 2.0 

Flash Image Information 
========================
POST   05/31/02 04:36:00 PM  Release 5.13.1 Build 2.0 I/F 12
OBP    05/31/02 04:36:00 PM  Release 5.13.1 Build 2.0 
Ver    05/31/02 04:36:00 PM  Release 5.13.1 Build 2.0 

Do you wish to update the FPROM (yes/no)? n

Here is an example which shows the intial output from redx:

redx> port 0 0 0       
Current port set to SB0/P0 (0.0.0).  SafariID = 00.00 = 0.   Type cpu.
redx> fprom info
Fprom SB0/F0 (local ports 0 & 1) segments:
POST     05/31/2002 16:36   Release 5.13.1 Build 2.0 I/F 12  Checksum: Good
OBP      05/31/2002 16:36   Release 5.13.1 Build 2.0  Checksum: Good
Ver      05/31/2002 16:36   Release 5.13.1 Build 2.0  Checksum: Good


mufasa-sc0:sms-svc:9> mcs -p /opt/SUNWSMS/hostobjs/pcilpost.elf
/opt/SUNWSMS/hostobjs/pcilpost.elf:

SMI sun4u_Sun_Fire_15K pcilpost.elf 5.13.1 Fri May 31 23:38:17 GMT 2002 
Workspace: /ws/sg-firmware/weekly_builds/5.13.1-Build_02   User: 5.13.1-Build_02
VERSION_SEGMENT BEGIN
BUILD-TIME              1022888297
BUILD-USER              5.13.1-Build_02
BUILD-HOST              lightside
BUILD-PATH              /ws/sg-firmware/weekly_builds/5.13.1-Build_02
BUILD-STRING            Build_02
MAIN-BUILD              2
VARIANT-BUILD           0
SC2LPOST-INTERFACE      12
SMS-BUILD               
IMAGE-DESCRIPTION       Io image
US-III                  YES
US-III+                 YES
PCI-IO-CONTROLLER       YES
VERSION_SEGMENT END

- Resolution:

stage exp_lpost: Domain-level board and system tests...
explpost.elf NOTE: lpost_vercheck(): Using up-rev LPOST version 5.13.1 Build 2.0 I/F 12
(from: 5.13.0 Build 0 I/F 12)
NOTE: Mixed Minor numbers: 4 All LPOSTs in a domain should use the same version.
Table of version comparisons: Fprom SB04/F0: 5.13.2 Build 2.0 I/F 12 vs explpost.elf: 5.13.1 Build 

The NOTE for mixed LPOST minor levels can be ignored,  although it is recommended to execute
flashupdate which in turn will utilize the existing flash image installed on the system. 

- Summary of part number and patch ID's 

http://cpre-amer.west.sun.com/esg/hsg/starcat/xctt/sms_firmware.html
______________________________________________________   
              SMS 1.1                SMS 1.2
              
LPOST         5.12.5             5.12.56 (w/ 112241-02)
              5.12.56            5.13.1  (w/ 112829-03)
______________________________________________________                             

- References and bug IDs

http://cpre-amer.west.sun.com/esg/hsg/starcat/xctt/sms_firmware.html

- Additional background information:

http://esp.west.sun.com/starcat/post/versioning.htm

- Meta-Data/Problem categorization:

Product/Platform: SF15K
Category:

- Keywords

Sun Fire 15K LPOST Versions, Notes, 5.13.0 Schema, 15K, 12K, SF15K, SF12K, starcat