
#
# Install.info for Sun Fire(TM) Midrange Systems Firmware 5.18.0
#
#
# Copyright 2001-2004 by Sun Microsystems, Inc.  All rights reserved.
# Use is subject to license terms.
#
#


1.0 Introduction
-----------------------------------------------------------------
This file contains firmware upgrade and downgrade information
for Sun Fire E6900/E4900/6800/4810/4800/3800 midrange systems
only.

For firmware upgrade and downgrade information on Sun
Fire E2900/V1280/Netra 1280 entry-level midrange systems,
refer to the Sun Fire Entry-Level Midrange System
Administration Guide included with the 5.18.0 firmware.

If you are upgrading from a firmware release before 5.18.0,
you may wish to upgrade the firmware on your existing system
controllers, CPU/Memory boards, or I/O assemblies to keep
them up-to-date with the latest features.  Or, you may need
to change firmware when one such component is replaced or
added. For example, if you replace your CPU/Memory board
with one running 5.18.0, you must ensure that the SCs and
components are running a compatible level of firmware. See
Section 7.0 for a compatibility table.

Note: Starting with the 5.13.x release, the main SC
      displays the SC portion of the schostname:SC>
      prompt in uppercase, while the spare SC prompt
      is in lowercase (schostname:sc>). All SCs (main
      and spare) running a firmware version before
      5.13.x display the SC portion of the prompt in
      uppercase, as do all examples in this file.


1.1 List of Sections
-----------------------------------------------------------------
This file contains the following sections:

  1.0 Introduction
      1.1 List of Sections
      1.2 Using FTP URLs
      1.3 Verifying Firmware Versions (showboards Sample Output)

  2.0 Checking Firmware on a Replacement SC Board

  3.0 Upgrading SC Firmware From Version 5.11.x

  4.0 Upgrading SC Firmware From Version 5.12.x, 5.13.x,
          5.14.x, 5.15.x, 5.16.x, 5.17.x
      4.1 Full Upgrade
      4.2 Partial Upgrade (Upgrading ScApp and RTOS Only)

  5.0 Downgrading SC Firmware

  6.0 Upgrading to an UltraSPARC IV 1050/1200 MHz CPU/Memory Board

  7.0 Checking/Changing Firmware When Replacing CPU/Memory
        Boards and I/O Assemblies (in Domains)
      7.1 Checking SC and Domain Firmware Versions
      7.2 Upgrading or Downgrading the Firmware on a Board.

  8.0 Synchronizing Date and Time on SCs


1.2 Using FTP URLs
-----------------------------------------------------------------
When you run certain SC commands, such as flashupdate,
dumpconfig, or restoreconfig, where the URL uses the FTP
protocol, specify absolute paths by typing a double slash
(//) after the hostname. Otherwise, the path is interpreted
relative to the home directory of the current user.

The following examples show the various ways to specify
a FTP URL:

  o URL that uses an absolute path name (/tmp/directory):

        ftp://user:password@hostname//tmp/directory

  o URL that uses a relative path name (/home/user/tmp/directory):

        ftp://user:password@hostname/tmp/directory

  o URL with anonymous FTP; that is, no user name or
     password (/home/ftp/tmp/directory):

        ftp://hostname/tmp/directory


1.3 Verifying Firmware Versions (showboards Sample Output)
-----------------------------------------------------------------
To check the firmware of the System Controller boards, run the
showsc command. Running this command on a board running 5.18.0,
for example, produces output similar to the following:

        schostname:SC> showsc -v

        SC: SSC0
        Main System Controller
        SC Failover: enabled and active.
        Clock failover enabled.

        SC date: Wed Oct 13 10:13:07 PDT 2004
        PST  GMT-08:00 Pacific Standard Time
        SC uptime: 2 days 6 hours 19 minutes 34 seconds

        ScApp version: 5.18.0
        Version build: 14.1
        Version String: 5.18.0 
        RTOS version: 41

        SC POST diag level: off

        Clock source is: 75MHz

To check the firmware compatibility between boards in
your system, run the showboards -p version command.
Output similar to the following is displayed:

        schostname:SC> showboards -p version

        Component   Compatible Version
        ---------   ---------- -------
        SSC0        Reference  5.18.0
        /N0/IB6     Yes        5.18.0
        /N0/IB7     Yes        5.18.0
        /N0/IB8     Yes        5.18.0
        /N0/IB9     Yes        5.18.0
        /N0/SB0     Yes        5.18.0
        /N0/SB1     Yes        5.18.0
        /N0/SB2     Yes        5.18.0
        /N0/SB3     Yes        5.18.0
        /N0/SB4     Yes        5.18.0
        /N0/SB5     Yes        5.18.0

The Compatible column indicates whether the component firmware
is compatible with the ScApp version listed in the Version
column.  Possible Compatible values are Yes, No, and - (dash).
The dash indicates that firmware compatibility does not apply
to the given component. For SCs, the Reference value in the
Compatible column indicates the firmware version listed in
the Version column is the baseline used to determine firmware
compatibility.

To obtain more detailed information on firmware compatibility,
run the showboards -p version -v command.  Output similar to
the following is displayed:

        schostname:SC> showboards -p version -v   


Component       Segment Compatible In Date       Time  Build Version
---------       ------- ---------- -- ----       ----  ----- -------
SSC0/FP0        -       -          -  -          -     -     RTOS version: 41 
SSC0/FP1        ScApp   Reference  12 09/20/2004 12:55 14.1      
SSC0/FP1        Ver     -          -  09/20/2004 12:55 14.1   5.18.0
/N0/IB6/FP0     iPOST   Yes        12 09/20/2004 12:52 14.1   
/N0/IB6/FP0     Ver     -          -  09/20/2004 12:53 14.1   5.18.0
/N0/IB7/FP0     iPOST   Yes        12 09/20/2004 12:52 14.1   
/N0/IB7/FP0     Ver     -          -  09/20/2004 12:53 14.1   5.18.0
/N0/IB8/FP0     iPOST   Yes        12 09/20/2004 12:52 14.1   
/N0/IB8/FP0     Ver     -          -  09/20/2004 12:53 14.1   5.18.0
/N0/IB9/FP0     iPOST   Yes        12 09/20/2004 12:52 14.1   
/N0/IB9/FP0     Ver     -          -  09/20/2004 12:53 14.1   5.18.0
/N0/SB0/FP0     POST    Yes        12 09/20/2004 12:51 14.1   
/N0/SB0/FP0     OBP     Yes        12 09/20/2004 12:50 14.1   
/N0/SB0/FP0     Ver     -          -  09/20/2004 12:51 14.1   5.18.0
/N0/SB0/FP1     POST    Yes        12 09/20/2004 12:51 14.1   
/N0/SB0/FP1     OBP     Yes        12 09/20/2004 12:50 14.1   
/N0/SB0/FP1     Ver     -          -  09/20/2004 12:51 14.1   5.18.0
/N0/SB1/FP0     POST    Yes        12 09/20/2004 12:51 14.1   
/N0/SB1/FP0     OBP     Yes        12 09/20/2004 12:50 14.1   
/N0/SB1/FP0     Ver     -          -  09/20/2004 12:51 14.1   5.18.0
/N0/SB1/FP1     POST    Yes        12 09/20/2004 12:51 14.1   
/N0/SB1/FP1     OBP     Yes        12 09/20/2004 12:50 14.1   
/N0/SB1/FP1     Ver     -          -  09/20/2004 12:51 14.1   5.18.0
/N0/SB2/FP0     POST    Yes        12 09/20/2004 12:51 14.1  
/N0/SB2/FP0     OBP     Yes        12 09/20/2004 12:50 14.1   
/N0/SB2/FP0     Ver     -          -  09/20/2004 12:51 14.1   5.18.0
/N0/SB2/FP1     POST    Yes        12 09/20/2004 12:51 14.1  
/N0/SB2/FP1     OBP     Yes        12 09/20/2004 12:50 14.1   
/N0/SB2/FP1     Ver     -          -  09/20/2004 12:51 14.1   5.18.0
/N0/SB3/FP0     POST    Yes        12 09/20/2004 12:51 14.1   
/N0/SB3/FP0     OBP     Yes        12 09/20/2004 12:50 14.1   
/N0/SB3/FP0     Ver     -          -  09/20/2004 12:51 14.1   5.18.0
/N0/SB3/FP1     POST    Yes        12 09/20/2004 12:51 14.1   
/N0/SB3/FP1     OBP     Yes        12 09/20/2004 12:50 14.1   
/N0/SB3/FP1     Ver     -          -  09/20/2004 12:51 14.1   5.18.0
/N0/SB4/FP0     POST    Yes        12 09/20/2004 12:51 14.1   
/N0/SB4/FP0     OBP     Yes        12 09/20/2004 12:50 14.1   
/N0/SB4/FP0     Ver     -          -  09/20/2004 12:51 14.1   5.18.0
/N0/SB4/FP1     POST    Yes        12 09/20/2004 12:51 14.1   
/N0/SB4/FP1     OBP     Yes        12 09/20/2004 12:50 14.1   
/N0/SB4/FP1     Ver     -          -  09/20/2004 12:51 14.1   5.18.0
/N0/SB5/FP0     POST    Yes        12 09/20/2004 12:51 14.1   
/N0/SB5/FP0     OBP     Yes        12 09/20/2004 12:50 14.1   
/N0/SB5/FP0     Ver     -          -  09/20/2004 12:51 14.1   5.18.0
/N0/SB5/FP1     POST    Yes        12 09/20/2004 12:51 14.1   
/N0/SB5/FP1     OBP     Yes        12 09/20/2004 12:50 14.1   
/N0/SB5/FP1     Ver     -          -  09/20/2004 12:51 14.1   5.18.0




To obtain detailed information on processors in your your
system, run the showboards -p cpu -v command. Output similar
to the following is displayed:

        schostname:SC> showboards -p cpu -v

Component       Cpu Mask   Description
---------       --------   -----------
/N0/SB0/P0      2.3        UltraSPARC-IV, 1200MHz, 16M ECache
/N0/SB0/P1      2.3        UltraSPARC-IV, 1200MHz, 16M ECache
/N0/SB0/P2      2.3        UltraSPARC-IV, 1200MHz, 16M ECache
/N0/SB0/P3      2.3        UltraSPARC-IV, 1200MHz, 16M ECache
/N0/SB1/P0      2.3        UltraSPARC-IV, 1200MHz, 16M ECache
/N0/SB1/P1      2.3        UltraSPARC-IV, 1200MHz, 16M ECache
/N0/SB1/P2      2.3        UltraSPARC-IV, 1200MHz, 16M ECache
/N0/SB1/P3      2.3        UltraSPARC-IV, 1200MHz, 16M ECache
/N0/SB2/P0      2.3        UltraSPARC-IV, 1200MHz, 16M ECache
/N0/SB2/P1      2.3        UltraSPARC-IV, 1200MHz, 16M ECache
/N0/SB2/P2      2.3        UltraSPARC-IV, 1200MHz, 16M ECache
/N0/SB2/P3      2.3        UltraSPARC-IV, 1200MHz, 16M ECache
/N0/SB3/P0      2.3        UltraSPARC-IV, 1200MHz, 16M ECache
/N0/SB3/P1      2.3        UltraSPARC-IV, 1200MHz, 16M ECache
/N0/SB3/P3      2.3        UltraSPARC-IV, 1200MHz, 16M ECache
/N0/SB4/P0      2.3        UltraSPARC-IV, 1200MHz, 16M ECache
/N0/SB4/P1      2.3        UltraSPARC-IV, 1200MHz, 16M ECache
/N0/SB4/P2      2.3        UltraSPARC-IV, 1200MHz, 16M ECache
/N0/SB4/P3      2.3        UltraSPARC-IV, 1200MHz, 16M ECache
/N0/SB5/P0      2.3        UltraSPARC-IV, 1200MHz, 16M ECache
/N0/SB5/P1      2.3        UltraSPARC-IV, 1200MHz, 16M ECache
/N0/SB5/P2      2.3        UltraSPARC-IV, 1200MHz, 16M ECache
/N0/SB5/P3      2.3        UltraSPARC-IV, 1200MHz, 16M ECache


2.0 Firmware on a Replacement SC Board
-----------------------------------------------------------------
Starting with the 5.13.0 release, both the main and spare
SC must run the same firmware version. This is particularly
important if SC failover is enabled, since that feature
requires ScApp version 5.13.x, 5.14.x, 5.15.x, 5.16.x, or 5.17.x.


3.0 Upgrading SC Firmware From Version 5.11.x
-----------------------------------------------------------------
Use the following procedure to upgrade the firmware from
5.11.x. This procedure assumes that the firmware update is
available on a ftp or http server. For more information, refer
to the Sun Fire Midrange Systems Platform Administration Manual.

This upgrade process involves shutting down your domains
before updating the firmware.

NOTE: If you have two system controllers (SCs) you must
      upgrade the firmware on the spare SC first.

      If you have a single SC configuration, skip steps
      5, 6, and 9 in the following procedure.

      If your SCs are connected to a network switch with
      spanning tree protocol (STP) enabled, you must set
      up a temporary hub between the SCs and the network
      switch before upgrading the firmware, then remove
      the hub after you complete the upgrade.

1. Connect to the main SC console using the serial port
   to monitor the system when you upgrade the firmware.

2. Shut down all the domains by halting the Solaris
   operating environment.

3. Verify that all CPU/Memory boards and I/O assemblies
   are powered on by running the showboards command on
   the SC in the platform shell:

        schostname:SC> showboards

4. If any CPU/Memory boards or I/O assemblies are not powered
   on, run the poweron command on the SC in the platform shell
   to power on those components:

        schostname:SC> poweron all

   If you have a single SC configuration, proceed to Step 7.

5. If you have a redundant SC configuration, connect to the
   spare SC console using the serial port.

6. Upgrade the firmware on the spare SC by running the
   flashupdate command on the spare SC.

   Use the command syntax appropriate to the URL protocol:

        schostname:SC> flashupdate -f <URL> scapp rtos

   where <URL> is the URL to the directory containing the
   new flash images.

   The flashupdate command updates ScApp and RTOS on the
   spare SC.  The spare SC is automatically rebooted.

7. Upgrade the firmware on the main SC by running the
   flashupdate command on the main SC in the platform shell.

   CAUTION: When performing this step, do NOT:

        o Power down any part of the system
        o Reset any part of the system

   Use the command syntax appropriate to the URL protocol:

        schostname:SC> flashupdate -f <URL> all rtos

   where <URL> is the URL to the directory containing the
   new flash images.

   The flashupdate command upgrades the CPU/Memory boards
   and I/O assemblies, then reboots the SC. ScApp and RTOS
   are upgraded during the reboot.

   NOTE: The first SC reboot after a successful update from
         5.11.x or 5.12.x firmware may take up to 20 minutes
         to complete due in part to updating of internal
         system records. Other factors include POST level
         setting and configuration. While these factors
         may affect the speed of subsequent reboots, the
         updating of system records occurs only once.

8. Verify that the firmware has been upgraded:

   o Run the showsc command on the main and spare SCs to
     verify that ScApp and RTOS have been upgraded.

     For 5.18.0, the output should indicate that the ScApp
     version is 5.18.0 and the RTOS version is 41.

   o Run the showboards -p version command to verify that the
     CPU/Memory boards and I/O assemblies have been upgraded.

9. If you have main and spare SCs, synchronize their date
   and time settings. The date and time must be the same on
   both SCs for failover purposes. For more information, see
   Section 8.0, Synchronizing Date and Time on SCs, then
   proceed to the next step in this procedure.

   After you have verified the firmware upgrade and synchronized
   the SCs, connect to each domain console and, one at a time,
   execute the following steps in all of them.

10. Power off all CPU/Memory boards and I/O assemblies in
    each domain by setting the keyswitch position to off:

        schostname:A> setkeyswitch off

11. Verify that all the CPU/Memory boards and I/O assemblies
    are powered off by running the showboards command on the
    SC in the platform shell:

        schostname:SC> showboards

12. If any CPU/Memory boards or I/O assemblies are not powered
    off, run the poweroff command on the SC in the platform
    shell to power off those components:

        schostname:SC> poweroff <component_names>

13. Update the configuration backup of the SC by running the
    dumpconfig command:

        schostname:SC> dumpconfig -f <URL>

    where <URL> is the URL to the directory in which the
    configuration is to be saved.

14. Bring up each domain by setting the keyswitch position to on:

        schostname:A> setkeyswitch on

15. Boot Solaris on each domain (if the domain did not automatically
    boot).


 4.0 Upgrading SC Firmware From Version 5.12.x, 5.13.x, 5.14.x,
        5.15.x, 5.16.x, or 5.17.x
-----------------------------------------------------------------
You can do a full upgrade of the system firmware, or a partial
upgrade of just ScApp and RTOS on the SCs. The partial upgrade,
described in Section 4.2, is faster and may be useful if, for
example, your system is running 5.12.x and you want access to the
failover feature of 5.18.x without flashupdating and rebooting
domains. Of course, you should then follow up with a full upgrade
of the SCs and domains, as described in Section 4.1, the next
time you reboot the system, to simplify system administration
and take advantage of the latest features and bug fixes.

After flashupdating the domains, the new firmware version
takes full effect only after you have done a shut down, run
the setkeyswitch off and setkeyswitch on commands, and booted
Solaris on each domain.

NOTE: If you have two system controllers (SCs) you must
      upgrade the firmware on the spare SC first.


4.1 Full Upgrade
-----------------------------------------------------------------
Use the following procedure to upgrade the firmware from
5.12.x, 5.13.x, 5.14.x, 5.15.x, 5.16.x, or 5.17.x. This
procedure assumes that the firmware update is available
on a ftp or http server. For more information, refer to
the Sun Fire Midrange Systems Platform Administration
Manual.

NOTE: If you have a single SC configuration, skip steps
      4, 5, and 8 in the following procedure.

      If your SCs are connected to a network switch with
      spanning tree protocol (STP) enabled, you must set
      up a temporary hub between the SCs and the network
      switch before upgrading the firmware, then remove
      the hub after you complete the upgrade. If you have
      questions regarding the hub, contact your service
      provider.


1. Connect to the main SC console using the serial port,
   to monitor the system when you upgrade the firmware.

2. Verify that all CPU/Memory boards and I/O assemblies
   are powered on by running the showboards command on
   the SC in the platform shell:

        schostname:SC> showboards

3. If any CPU/Memory boards or I/O assemblies are not powered
   on, run the poweron command on the SC in the platform shell
   to power on those components:

        schostname:SC> poweron <component names>

   If you have a single SC configuration, proceed to Step 6.

4. If you have a redundant SC configuration, connect to the
   spare SC console using the serial port.
   
5. Upgrade the firmware on the spare SC by running the
   flashupdate command on the spare SC.

   Use the command syntax appropriate to the URL protocol:

        schostname:SC> flashupdate -f <URL> scapp rtos

   where <URL> is the URL to the directory containing the
   new flash images.

   The flashupdate command updates ScApp and RTOS on the spare SC.

6. Upgrade the firmware on the main SC by running the flashupdate
   command on the main SC in the platform shell.

   CAUTION: When performing this step, do NOT:

        o Power down any part of the system
        o Reset any part of the system
        o Perform any DR operation

   Use the command syntax appropriate to the URL protocol:

        schostname:SC> flashupdate -f <URL> all rtos

   where <URL> is the URL to the directory containing the
   new flash images. The flashupdate command upgrades the
   CPU/Memory boards and I/O assemblies, then it reboots
   the SC. ScApp and RTOS are upgraded during the reboot.

   NOTE: The first SC reboot after a successful update from
         5.11.x or 5.12.x firmware may take up to 20 minutes
         to complete due in part to updating of internal
         system records. Other factors include POST level
         setting and configuration. While these factors may
         affect the speed of subsequent reboots, the
         updating of system records occurs only once.

7. Verify that the firmware has been upgraded:

   o Run the showsc command on the main and spare SCs to
     verify that ScApp and RTOS have been upgraded.

     For 5.18.0, the output should indicate that the ScApp
     version is 5.18.0 and the RTOS version is 41.

   o Run the showboards -p version command to verify that the
     CPU/Memory boards and I/O assemblies have been upgraded.

8. If you have main and spare SCs, synchronize their date and
   time settings. The date and time must be the same on both
   SCs for failover purposes. For more information, see
   Section 8.0, Synchronizing Date and Time on SCs, then
   proceed to the next step in this procedure.

   After you have verified the firmware upgrade and synchronized
   the SCs, connect to each domain console and, one at a time,
   execute the following steps on all of them.

   NOTE: The following steps involve domain setkeyswitch
         operations that can be performed later, at your
         convenience. However, note that the new firmware
         does not take full effect until they are completed,
         so execute the remaining steps as soon as possible
         after the flashupdate. Also, do not reboot the
         Solaris operating environment until the remaining
         steps are completed.

9. Shut down all the domains by halting the Solaris operating
   environment on each domain.

10. Power off all CPU/Memory boards and I/O assemblies by
    setting the keyswitch position to off:

        schostname:A> setkeyswitch off

11. Verify that all the CPU/Memory boards and I/O assemblies
    are powered off by running the showboards command on the
    SC in the platform shell:

        schostname:SC> showboards

12. If any CPU/Memory boards or I/O assemblies are not powered
    off, run the poweroff command on the SC in the platform
    shell to power off those components:

        schostname:SC> poweroff <component_names>

13. Update the configuration backup of the SC by running the
    dumpconfig command:

        schostname:SC> dumpconfig -f <URL>

    where <URL> is the URL to the directory in which the
    configuration is to be saved.

14. Bring up each domain by setting the keyswitch position to on:

        schostname:A> setkeyswitch on

15. Boot Solaris on each domain (if it did not automatically
    boot).


4.2 Partial Upgrade (Upgrading ScApp and RTOS Only)
-----------------------------------------------------------------
If you are upgrading from firmware version 5.12.x, 5.13.x,
5.14.x, 5.15.x, 5.16.x, or 5.17.x, you can minimize system
downtime by doing a partial firmware upgrade.

NOTE: If you have a single SC configuration, skip steps
      1, 2, and 6 in the following procedure.

1. If you have a redundant SC configuration, connect to
   the spare SC console using the serial port.

2. Update ScApp and RTOS on the spare SC by running the
   flashupdate command on the spare SC.

   Use the command syntax appropriate to the URL protocol:

        schostname:SC> flashupdate -f <URL> scapp rtos

   where <URL> is the URL to the directory containing the
   new flash images.

3. Connect to the main SC console using the serial port, to monitor
   the system when you upgrade the firmware on the main SC (Step 4).

4. Upgrade ScApp and RTOS on the main SC by running the flashupdate
   command on the main SC in the platform shell.

   Use the command syntax appropriate to the URL protocol:

        schostname:SC> flashupdate -f <URL> scapp rtos

   where <URL> is the URL to the directory containing the new
   flash images.

5. Run the showsc command on the main and spare SCs to verify
   that ScApp and RTOS have been upgraded. For 5.18.0, the
   output should indicate that the ScApp version is 5.18.0 and
   the RTOS version is 41.

   NOTE: After completion of the partial upgrade, do a full
         upgrade of SCs and domains to the latest firmware
         release at the next convenient opportunity when
         you bring the domain down to take advantage of the
         latest bug fixes and POST and OBP enhancements.

6. If you have main and spare SCs, synchronize their date
   and time settings. The date and time must be the same
   on both SCs for failover purposes. For more information,
   see Section 8.0, Synchronizing Date and Time on SCs.


5.0 Downgrading SC Firmware
-----------------------------------------------------------------
Use the following procedure to downgrade the SCs to an
earlier version of the firmware. This procedure assumes
that the firmware is available on a ftp or http server.
Refer to the Sun Fire Midrange Systems Platform Administration
Manual for more information.
      
Note the following:

o Systems that have UltraSPARC IV(TM) 1050/1200
  MHz CPU/Memory boards require 5.16.0 firmware or
  greater and cannot be downgraded to a firmware release
  earlier than 5.16.0. The downgraded firmware will not
  recognize UltraSPARC IV CPU/Memory boards.
  
o If your system has SC V2s (enhanced memory), you can
  downgrade from 5.18.0 to earlier firmware releases, but 
  the firmware will not support the features and fixes
  introduced in 5.18.0. If you downgrade to 5.15.x
  or earlier, the firmware will not recognize the available
  enhanced memory, nor the features introduced in 5.16.0
  and subsequent releases.

o If you have a single SC configuration, skip steps 7,
  8, and 11 in the following procedure (but do read the
  NOTE that appears in Step 7). If you have a redundant
  SC configuration, be sure that SSC0 is the main SC and
  SSC1 is the spare before you begin the downgrade process.

o If you have COD CPU/Memory boards, any such boards in a
  domain will be unusable if you downgrade the main SC
  to a release earlier than 5.14.0.

o If you are running 5.18.x and swapped HostID/MAC addresses
  between domains, you must restore any swapped HostID/MAC
  addresses to their original domains before starting the
  downgrade procedure. Otherwise, the affected domains may
  compete for the same HostID/MAC address. For details on
  restoring the original HostID/MAC addresses, refer to the
  "General Administration" chapter of the Sun Fire
  Midrange Systems Platform Administration Manual.
  
o If you are downgrading to 5.15.x from 5.18.x, set the
  the connection type to none (through the setupplatform
  command) before downgrading the SCs. If you do not disable
  the connection type before downgrading, the connection type
  set in 5.18.x will be restored automatically if you upgrade
  again to 5.18.x.

1. Connect to the main SC console using the serial port, to
   monitor the system when you downgrade the firmware.

2. Shut down all the domains by halting the Solaris operating
   environment.

3. For each domain, set the keyswitch position to off:

        schostname:A> setkeyswitch off

4. Power off CPU/Memory boards and I/O assemblies that are
   currently powered on by running the poweroff command on
   the SC in the platform shell:

        schostname:SC> poweroff <component names>

5. Run the poweron command on the SC in the platform shell
   to power on all components:

        schostname:SC> poweron all

6. Verify that all CPU/Memory boards and I/O assemblies are
   powered on by running the showboards command on the SC
   in the platform shell:

        schostname:SC> showboards

   If you have a single SC configuration, proceed to Step 9.

7. If you have a redundant SC configuration, connect to the
   spare SC console using the serial port.

   NOTE: If you are downgrading to 5.11.x or 5.12.x, the system
         will display a message as you execute each of the next
         two steps warning that "the upgrade will likely result
         in an unbootable system" and ask if you wish to
         continue. This message emphasizes the importance of
         of power cycling as part of the downgrade process. As
         long as you execute all the procedures in this section
         as instructed, including the power cycle, the downgrade
         should not result in an unbootable system.

8. Downgrade the firmware on the spare SC by running the
   flashupdate command on the spare SC.

   Use the command syntax appropriate to the URL protocol:

        schostname:SC> flashupdate -f <URL> scapp rtos

   where <URL> is the URL to the directory containing the older
   flash images.

   The flashupdate command updates ScApp and RTOS on the spare SC.

9. Downgrade the firmware on the main SC by running the
   flashupdate command on the main SC in the platform shell.

   CAUTION: When performing this step, do NOT:

        o Power down any part of the system
        o Reset any part of the system
        o Perform any DR operation

   Use the command syntax appropriate to the URL protocol:

        schostname:SC> flashupdate -f <URL> all rtos

   where <URL> is the URL to the directory containing the
   older flash images.

   The flashupdate command downgrades the CPU/Memory boards
   and I/O assemblies, then reboots the SC. ScApp and RTOS
   are downgraded during the reboot.

10. Verify that the firmware has been downgraded:

    o Run the showsc command on the main and spare SCs to
      verify that ScApp and RTOS have been downgraded.

    o Do one of the following:

      - If you downgraded to 5.11.x, run the showboards -p prom
        command to verify that the CPU/Memory boards and I/O
        have been downgraded.

      - If you downgraded to 5.12.x, 5.13.x, 5.14.x, 5.15.x,
        5.16.x, or 5.17.x, run the showboards -p version command
        to verify that the CPU/Memory boards and I/O assemblies
        have been downgraded.

11. If you have main and spare SCs, synchronize their date and
    time settings. The date and time on both SCs must be the
    same for failover purposes. For more information, see
    Section 8.0, Synchronizing Date and Time on SCs, then
    proceed to the next step in this procedure.

12. If any CPU/Memory boards and I/O assemblies are not powered
    off, run the poweroff command on the SC in the platform
    shell to power off all components:

        schostname:SC> poweroff all

13. Verify that all the CPU/Memory boards and I/O assemblies
    are powered off by running the showboards command on the
    SC in the platform shell:

        schostname:SC> showboards

14. Power cycle the chassis (manually turn the power off,
    then on).

    After you power off the chassis, wait one minute before
    turning the power on, to ensure that the electrical
    current to the components has stopped.

15. Power on all power supplies, fan trays, and system boards by
    running the poweron command on the SC in the platform shell:

        schostname:SC> poweron all

16. Update the configuration backup of the SC by running the
    dumpconfig command:

        schostname:SC> dumpconfig -f <URL>

    where <URL> is the URL to the directory in which the
    configuration is to be saved.

17. Bring up each domain by setting the keyswitch position to on:

        schostname:A> setkeyswitch on

18. Boot Solaris on each domain (if it did not automatically
    boot).


6.0 Upgrading to an UltraSPARC IV 1050/1200 MHz CPU/Memory Board
-----------------------------------------------------------------
If you are adding an UltraSPARC IV CPU/Memory board to your
system, review the following documents before upgrading:

-  Sun Fire High-End and Midrange Systems UltraSPARC IV
   CPU/Memory Board Upgrade Requirements 
-  Sun Fire High-End and Midrange Systems CPU/Memory Board
   Installation Guide

NOTE: For general information about physically adding
      and removing system boards, refer to the Sun Fire
      Midrange Systems Platform Administration Manual.


7.0 Changing Firmware When Replacing CPU/Memory Boards and
      I/O assemblies (in Domains)
-----------------------------------------------------------------
When replacing a CPU/Memory board or I/O assembly in a
domain, you must make certain the firmware for the board
is compatible with the SC firmware. If it is not, you
must change the firmware on the board, the SCs, or both;
and, possibly, the firmware on other boards.

The following compatibility requirements apply:

  1. All CPU/Memory and I/O boards in a domain must run
     the same firmware release.

  2. Different domains in the system can run different
     firmware releases if the SC is running firmware
     release 5.13.x, 5.14.x, 5.15.x, 5.16.x, 5.17.x,
     or 5.18.0.

  3. The firmware running on the boards in a domain must
     be compatible with that running on the SC.

     Use the following table to verify compatibility.

     Note:

     SC Firmware   CPU (MHz)               Domain Firmware
     -----------   ---------               ---------------
       5.11.x      750                     5.11.x
       5.12.5      750/900 (Masks
                    2.1/2.2 only)          5.12.x
       5.12.6      750/900 (Masks
                    2.1/2.2 only)          5.12.x
       5.12.7      750/All 900             5.12.x
       5.13.0      750/All 900             5.12.x or 5.13.x
       5.13.1      750/All 900             5.12.x or 5.13.x
       5.13.2      750/All 900/1050        5.12.x or 5.13.x
       5.13.3      750/All 900/1050        5.12.x or 5.13.x
       5.13.4      750/All 900/1050        5.12.x or 5.13.x
       5.13.5      750/All 900/1050        5.12.x or 5.13.x
       5.14.0      750/All 900/1050        5.12.x, 5.13.x, or 5.14.0
       5.14.2      750/All 900/1050        5.12.x, 5.13.x, or 5.14.x
       5.14.3      750/All 900/1050        5.12.x, 5.13.x, or 5.14.x
       5.14.4      750/All 900/1050/1200*  5.12.x, 5.13.x, or 5.14.x
       5.14.5      750/All 900/1050/1200*  5.12.x, 5.13.x, or 5.14.x
       5.14.6      750/All 900/1050/1200*  5.12.x, 5.13.x, or 5.14.x
       5.15.0      750/All 900/1050/1200*  5.12.x, 5.13.x, 5.14.x,
                                             or 5.15.0
       5.15.1      750/All 900/1050/1200*  5.12.x, 5.13.x, 5.14.x,
                                             or 5.15.x
       5.15.2      750/All 900/1050/1200*  5.12.x, 5.13.x, 5.14.x,
                                             or 5.15.x
       5.15.3      750/All 900/1050/1200*  5.12.x, 5.13.x, 5.14.x,
                                             or 5.15.x
       5.15.4      750/All 900/1050/1200*  5.12.x, 5.13.x, 5.14.x,
                                             or 5.15.x
       5.16.0      750/All 900/1050/1200** 5.12.x, 5.13.x, 5.14.x,
                                             5.15.x, or 5.16.x
       5.17.0      750/All 900/1050/1200** 5.12.x, 5.13.x, 5.14.x,
                                            5.15.x, 5.16.x, or 
                                            5.17.x
       5.18.0      750/All 900/1050/1200** 5.12.x, 5.13.x, 5.14.x,
                                            5.15.x, 5.16.x, or 
                                            5.17.x, or 5.18.0    
                                           
                                                                                     

    *  The 1050/1200 MHz CPU/Memory boards supported for firmware
       releases 5.14.4, 5.14.5, 5.14.6, 5.15.0, 5.15.1, 5.15.2,
       5.15.3, and 5.15.4 are UltraSPARC III 1050/1200 MHz boards.

    ** The 1050/1200 MHz CPU/Memory boards supported for firmware
       releases 5.16.0, 5.17.0, and 5.18.0 are UltraSPARC IV and
       UltraSPARC III 1050/1200 MHz boards.


7.1 Checking SC and Domain Firmware Versions
-----------------------------------------------------------------
To check the firmware level of the SC and each board in the
system, including the newly inserted replacement board, run
the following command:

        showboards -p version -v

Do one or both of the following, as applicable:

  o To change the firmware on the SC, execute the procedures
    in Section 3.0 or 4.0.

  o To change the firmware on a board in a domain, read
    Section 7.0, then execute the procedures in Section 7.2.


7.2 Upgrading or Downgrading the Firmware on a Board
-----------------------------------------------------------------
After checking firmware version levels (see Section 7.1), use
the following procedure to upgrade or downgrade the firmware
on any replacement domain board.

If you are downgrading the firmware on a board, see Section
5.0 for additional notes on downgrading.
      
If your domain is running DR software, you should not need
to bring down the domain to do this upgrade.

1. Make sure the board is powered on.

2. Do one of the following:

   o To copy firmware from another board of the same type, run:

        flashupdate -c <source board> <replacement board>

   o To use a URL as the source of the firmware, run:

        flashupdate -f <URL> <replacement board>

3. Run the showboards command to check the board status.
   If the output shows the board as "Failed," you must power
   the board off, then on, to clear the failed state.

4. Do one of the following:

   o If your domain is NOT running DR, proceed to the next
     step in this procedure.

   o If your domain IS running DR, use the Solaris command
     cfgadm to dynamically add the board to the domain.

     The procedure for domains running DR is now complete.
     For more information on using DR to add a replacement
     board to a domain, refer to the Sun Fire Midrange
     Systems Dynamic Reconfiguration User Guide.

5. Run the showboards -p version -v command to verify that the
   SCs and domains are now running the proper firmware version.

6. Shut down the domain in which the new board is to
   be used by halting the Solaris operating environment.

7. Power off all CPU/Memory boards and I/O assemblies in
   the domain by setting the keyswitch position to off:

        schostname:A> setkeyswitch off

8. Verify that all the CPU/Memory boards and I/O assemblies
   in the domain are powered off by running the showboards
   command on the SC in the platform shell:

        schostname:SC> showboards

9. If any CPU/Memory boards or I/O assemblies in the domain
    are not powered off, run the poweroff command on the SC
    in the platform shell to power off those components:

        schostname:SC> poweroff <component_names>

10. Update the configuration backup of the SC by running
    the dumpconfig command:

        schostname:SC> dumpconfig -f <URL>

    where <URL> is the URL to the directory in which the
    configuration is to be saved.

11. Bring up the domain with the new board by setting the
    keyswitch position to on:

        schostname:A> setkeyswitch on

12. Boot Solaris on the domain (if the domain did not
    automatically boot).


8.0 Synchronizing Date and Time on SCs
-----------------------------------------------------------------
The date and time settings on both the main and spare SC must
always be synchronized for failover purposes.

Although you can use the setdate command to set the date and
time on both SCs, Sun strongly suggests that you configure
both SCs to synchronize their date and time settings against
a Simple Network Time Protocol (SNTP) server. By configuring
SNTP on the SCs, the SCs will periodically check the SNTP
server to ensure that their date and time are accurate and
synchronized. You can use the setupplatform command to assign
an SNTP server.

NOTE: If the main SC and spare SC do not have the same date
      and time and an SC failover occurs, a time jump may
      occur in running domains.

If you skipped to this section as one step in a procedure,
return now to the next step in that procedure.

                >>> END <<<

