hometocprevnextglossaryfeedbacksearchhelp
PDF

Table Of Contents

Firmware Upgrade and Downgrade Procedures

Introduction

Using the Procedure Tables

Finding the Right Procedure

Standard Upgrade and Downgrade Procedures

Procedure 1—Standard Upgrade, 1-Core Card Set

Procedure 2—Standard Downgrade, 1-Core Card Set

Procedure 3—Standard Upgrade, 2-Core Card Set

Procedure 4—Standard Downgrade, 2-Core Card Set

Procedure 5—Standard Upgrade, 1-Core Card Set

Procedure 6—Standard Upgrade, 2-Core Card Set

Procedure 7—Standard Downgrade, 1-Core Card Set

Procedure 8—Standard Downgrade, 2-Core Card Set

Procedure 9—Standard Upgrade, 1-Core Card Set

Procedure 10—Standard Upgrade, 2-Core Card Set

Procedure 11—Standard Downgrade, 1-Core Card Set

Procedure 12—Standard Downgrade, 2-Core Card Set

Graceful Upgrade and Downgrade Procedures

Procedure 13—Graceful Upgrade, 1-Core Card Set (SM only)

Procedure 14—Graceful Downgrade, 1-Core Card Set (SM only)

Procedure 15—Graceful Upgrade, 2-Core Card Set

Procedure 16—Graceful Downgrade, 2-Core Card Set

Procedure 17—Graceful Upgrade, 1-Core Card Set (SM only)

Procedure 18—Graceful Downgrade, 1-Core Card Set (SM only)

Procedure 19—Graceful Upgrade, 2-Core Card Set

Procedure 20—Graceful Upgrade, 2-Core Card Set

Procedure 21—Graceful Upgrade, 2-Core Card Set

Procedure 22—Graceful Downgrade, 1-Core Card Set (SM only)

Procedure 23—Graceful Upgrade, 2-Core Card Set

Procedure 24—Graceful Downgrade, 1-Core Card Set (SM only)

Procedure 25—Graceful Upgrade, 2-Core Card Set

Description of Upgrade/Downgrade Terminology

Standard

Graceful

One-cc

Two-cc

chkflash

Version

tftp put

File Size

dspfwrevs

Slot-Specific and Card-Type-Specific SM Firmware

flashStartAddr and flashEndAddr

resetsys

softswitch

dspadrxlat

dsptotals

donotupdatestandby

Compatibility

clrallcnf

resetsys or clrallcnf

Save/Restore ASC Configuration

Upgrade/Downgrade

Save/Restore SM Configuration

Firmware Upgrade and Downgrade Procedures

Introduction

This appendix describes the procedures for upgrading or downgrading from one MGX 8220 firmware revision to another firmware revision. Both the upgrading and downgrading of ASC and service module firmware, and the upgrading and downgrading of backup boot code are included.

Each procedure is characterized by

•Whether an upgrade or downgrade is being performed

•Whether the MGX 8220 has one core card set or two core card sets

•What "from" release and what "to" release are involved

•Whether the upgrade or downgrade is standard or graceful

–A standard upgrade and downgrade is simpler and faster than its corresponding graceful procedures, but it usually involves some traffic loss through the MGX 8220 while the procedure is being performed.

–A graceful upgrade and downgrade is more complex and takes longer than its corresponding standard procedure, but it attempts to eliminate, or at least minimize, traffic loss while the procedure is being performed.

To cover all the possible combinations, there are 25 specific procedures, all of which are described in this appendix. To determine which procedure to use in a particular situation, look up a procedure number in one of the eight tables, see the "Using the Procedure Tables" section and follow that procedure described in the body of this appendix. The tables are identified as A through H.

The procedures themselves involve issuing a sequence of commands using the shelf command-line interface (CLI).

Definition of terms and descriptions of commands involved in the procedures are provided at the end of this appendix.

Using the Procedure Tables

Each of the eight tables includes the procedure for a particular type of upgrade or downgrade, and for a particular core card set. For example, one table shows the procedures for a graceful upgrade on a one core card set, another table shows the procedures of a standard downgrade for a two core card set.

The tables, A through H, are as follows:

•A = Standard upgrade, 1-core card set

•B = Standard upgrade, 2-core card set

•C = Standard downgrade, 1-core card set

•D = Standard downgrade, 2-core card set

•E = Graceful upgrade, 1-core card set

•F = Graceful upgrade, 2-core card set

•G = Graceful downgrade, 1-core card set

•H = Graceful downgrade, 2-core card set

Each row in a table corresponds to a particular "from" release and each column in a table corresponds to a particular "to" release.

By looking down to the appropriate row and across to the appropriate column, the cell (or position) in the table indicates the number of the procedure to be used. An em dash in a table indicates that no procedure is supported for that particular upgrade or downgrade.

Table C-1 Standard Firmware Upgrade/Downgrade Version Matrix

 

A

Std. Upgrade
1-Core Card Set

 

B

Std. Upgrade
2-Core Card Set

 

C

Std. Downgrade
1-Core Card Set

 

D

Std. Downgrade
2-Core Card Set

 

To 2.x

To 3.x

To 4.x

To 5.x

To 2.x

To 3.x

To 4.x

To 5.x

To 2.x

To 3.x

To 4.x

To 5.x

To 2.x

To 3.x

To 4.x

To 5.x

From Rel. 2.x

1

1

5

via 4.x

3

3

6

via 4.x

2

—

—

—

4

—

—

—

From Rel. 3.x

—

1

5

via 4.x

—

3

6

via 4.x

2

2

—

—

4

4

—

—

From Rel. 4.x

—

—

9

9

—

—

10

10

7

7

11

11

8

8

12

12

From Rel. 5.x

—

—

9

9

 

—

—

10

10

 

7

7

11

11

 

8

8

12

12


Table C-2 Graceful Firmware Upgrade/Downgrade Version Matrix

 

E

Graceful Upgrade
1 Core Card Set

 

F

Graceful Upgrade
2 Core Card Set

 

G

Graceful Downgrade
1 Core Card Set

 

H

Graceful Downgrade
2 Core Card Set

 

To 2.x

To 3.x

To 4.x

To 5.x

To 2.x

To 3.x

To 4.x

To 5.x

To 2.x

To 3.x

To 5.x

To 4.x

To 2.x

To 3.x

To 4.x

To 5.x

From Rel. 2.x

13

—

—

—

15

—

15

via 4.x

14

—

—

—

16

—

—

—

From Rel. 3.x

—

17

—

—

—

19

21

via 4.x

—

18

—

—

—

20

—

—

From Rel. 4.x

—

—

22

22

—

—

23

23

—

—

24

24

—

—

25

25

From Rel. 5.x

—

—

22

22

 

—

—

23

23

 

—

—

24

24

 

—

—

25

25


Finding the Right Procedure

To find which procedure to use, perform the following steps.

Step 1 Determine whether the desired procedure is an upgrade or a downgrade, and whether the MGX has a 1-core card set or a 2-core card set.

Using this information look at the table headings to determine which table to use.

For example, to perform a graceful upgrade on a 2-core card set, use Table F.

Step 2 Look down the left side of the table to select the row for the appropriate from release.

Step 3 Look across the top of the table to select the column for the appropriate to release.

Step 4 Read the procedure number from the selected cell (position) in the table.

Step 5 Proceed to the appropriate procedure in the "Standard Upgrade and Downgrade Procedures" section or the "Graceful Upgrade and Downgrade Procedures" section.

Step 6 Perform the procedure.

Standard Upgrade and Downgrade Procedures

These procedures must be performed at a UNIX workstation that has an operational data path to the MGX 8220. The workstation must be able to send MGX 8220 CLI commands and UNIX Trivial File Transfer Protocol (TFTP) downloads.

A Cisco WAN Manager (CWM) workstation attached to a BPX is one method in which MGX 8220 commands and TFTP commands can be run on the MGX 8220 using an in-band channel. The workstation can also be attached to the MGX 8220 through an Ethernet LAN, or through a TCP/IP connection on the control port on the ASC.

Procedure 1—Standard Upgrade, 1-Core Card Set

Procedure 1 is used for 1.2.x to 2.y, 2.2.x to 3.y, and 3.3.x to 3.y.

Step 1 Save the current ASC configuration. Perform this step for the ASC prior to upgrading the firmware.

First reset the card, then use TFTP get to save the card's current configuration in the workstation.

tftp shelf
tftp> bin
tftp> get AXIS_ASC_ACTIVE.BR

Step 2 Save the current service module (SM) configuration for each primary and stand-alone SM. Perform this step for the SM prior to upgrading the firmware.

First reset the card, then use TFTP get to save the card's current configuration in the workstation.

tftp shelf
tftp> bin
tftp> get AXIS_SM_1_ slot.PRI. service password

Step 3 Enter the dspadrcxat command. Note the value of the ConnNumOfValidEntries parameter.

This value indicates the number of connections. This command is run again at the end of the procedure to ensure that the number of connections did not change.

Step 4 For all primary and stand-alone SMs

a. Enter the dsptotals command.

The configuration of the shelf should not be changed during the upgrade or downgrade process. Use this step to examine the number of lines, ports, and channels before the upgrade or downgrade. A similar step can be made to examine the same configuration parameters after the upgrade or downgrade and, therefore, it can be established that the configuration has remained the same.

b. Enter the tftp put <ASC_BT_file> AXIS_ASC_BACKUP.FW command. This step downloads the new boot code into the ASC.

c. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

d. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

e. Enter the tftp put <ASC_FW_file> AXIS_ASC_ACTIVE.FW command.

f. Check the file size of the downloaded firmware. Use this step to check that the firmware was downloaded successfully to the ASC disk.

g. Enter the dspfwrevs command to verify the correct firmware revision.

Step 5 For all SMs, set the start and end addresses in Flash memory where the boot code file will be written.

a. Enter the flashStartAddr and flashEndAddr commands to start the Flash memory file at Oxbfc00000 and end it at 0xbfc40000

shelf.1.<slot>.<type><a|s>flashStartAddr = 0xbfc00000
shelf.1.<slot>.<type>.<a|s>flashEndAddr = 0xbfc40000

b. Enter the tftp put <SM_BT_file> AXIS_SM_1_$slot.FW command.

c. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

d. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

Step 6 For all SMs, set the start and end addresses in Flash memory where the firmware file will be written.

a. Enter the flashStartAddr and flashEndAddr commands to start the Flash memory file at Oxbfc00000 and end it at 0xbfd00000

shelf.1.<slot>.<type><a|s>flashStartAddr = 0xbfc40000
shelf.1.<slot>.<type>.<a|s>flashEndAddr = 0xbfd40000

b. Enter the tftp put <SM_FW_file> AXIS_SM_1_$slot.FW command.

c. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

d. Enter the resetsys command. This command resets all cards on the shelf.

e. Enter the dspadrxlat command to ensure that the number of connections has not changed during the procedure.

Step 7 For all primary and stand-alone SMs, enter the dsptotals command.

Use this step to examine the number of lines, ports, and channels after the upgrade or downgrade. The values can be compared to those before the download and, therefore it can be established that the configuration has remained the same.

Procedure 2—Standard Downgrade, 1-Core Card Set

Procedure 2 is used for 1.2.y to 2.x, 2.3.y to 2.x, and 3.3.y to 3.x.

Step 1 Check compatibility.

With any downgrade technique, there is always the issue of compatibility. Any release can be downgraded to any other release, but in many instances configuration information will be lost. Hardware incompatibilities can prevent some downgrades. For example, Releases 2 and 3 service modules require two Flash chips. Release 4 SMs will be shipped with a single Flash chip. A Release 4 shelf containing BNM-E1 cards or service resource module 3T3 cards cannot be downgraded to Release 2 or Release 3. Check the compatibility matrix to determine if a particular downgrade is supported, and how it could affect configuration loss.

Step 2 Enter the dspadrxlat command. Note the value of the ConnNumOfValidEntries parameter.

This value indicates the number of connections. This command is run again at the end of the procedure to ensure that the number of connections has not changed.

Step 3 For all primary and stand-alone SMs, enter the dsptotals command.

The configuration of the shelf should not be changed during the downgrade process. Use this step to examine the number of lines, ports, and channels before the upgrade or downgrade. A similar step can be made to examine the same configuration parameters after the upgrade or downgrade and, therefore, it can be established that the configuration has remained the same.

Step 4 Enter the tftp put <ASC_BT_file> AXIS_ASC_BACKUP.FW command. This step downloads the new boot code into the ASC.

Step 5 Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

Step 6 Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

Step 7 Enter the tftp put <ASC_FW_file> AXIS_ASC_ACTIVE.FW command.

Step 8 Check the file size of the downloaded firmware. Use this step to check that the firmware was downloaded successfully to the ASC disk.

Step 9 Enter the dspfwrevs command to verify the correct firmware revision.

Step 10 For all SMs enter the flashStartAddr and flashEndAddr commands to start the Flash memory file at Oxbfc00000 and end it at 0xbfc40000

shelf.1.<slot>.<type><a|s>flashStartAddr = 0xbfc00000
shelf.1.<slot>.<type>.<a|s>flashEndAddr = 0xbfc40000

Step 11 Enter the tftp put <SM_BT_file> AXIS_SM_1_$slot.FW command.

Step 12 Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

Step 13 Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

Step 14 For all SMs enter the flashStartAddr and flashEndAddr commands to start the Flash memory file at 0xbfc40000 and end it at 0xbfd00000

shelf.1.<slot>.<type><a|s>flashStartAddr = 0xbfc40000
shelf.1.<slot>.<type>.<a|s>flashEndAddr = 0xbfd00000

Step 15 Enter the tftp put <SM_FW_file> AXIS_SM_1_$slot.FW command.

Step 16 Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

Step 17 Enter the resetsys or clrallcnf command. These commands reset all cards on the shelf.

Step 18 Set the BRAM revision.

Step 19 Enter the dspadrxlat command to ensure that the number of connections is correct.

Step 20 For all primary and stand-alone SMs, enter the dsptotals commands.

Use this step to examine the number of lines, ports, and channels after the upgrade or downgrade. The values can be compared to those before the download and, therefore, it can be established that the configuration has remained the same. Restore the ASC and SM configurations if necessary.

Procedure 3—Standard Upgrade, 2-Core Card Set

Procedure 3 is used for 1.2.x to 2.y, 2.2.x to 3.x, and 3.3.x to 3.y.

Step 1 Save the current ASC configuration. Perform this step for the ASC prior to upgrading the firmware.

First reset the card, then use TFTP get to save the card's current configuration in the workstation.

tftp shelf
tftp> bin
tftp> get AXIS_ASC_ACTIVE.BR

Step 2 Save the current service module (SM) configuration for each primary and stand-alone SM. Perform this step for the SM prior to upgrading the firmware.

First reset the card, then use TFTP get to save the card's current configuration in the workstation.

tftp shelf
tftp> bin
tftp> get AXIS_SM_1_<slot>.PRI.<service password>

Step 3 Enter the dspadrcxat command. Note the value of the ConnNumOfValidEntries parameter.

This value indicates the number of connection. This command is run again at the end of the procedure to ensure that the number of connections has not changed.

Step 4 For all stand-alone and primary SMs

a. Enter the dsptotals command.

The configuration of the shelf should not be changed during the downgrade process. Use this step to examine the number of lines, ports, and channels before the upgrade or downgrade. A similar step can be made to examine the same configuration parameters after the upgrade or downgrade and, therefore, it can be established that the configuration has remained the same.

b. Enter the tftp put <ASC_BT_file> AXIS_ASC_BACKUP.FW command. This step downloads the new boot code into the ASC.

c. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

d. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

e. Enter the switchcc command to switch to the other ASC.

f. Enter the tftp put <ASC_BT_file> AXIS_ASC_BACKUP.FW command. This step downloads the new boot code into the second ASC.

g. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

h. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

i. Enter the tftp put <ASC_FW_file> AXIS_ASC_ACTIVE.FW command.

j. Check the file size of the downloaded firmware. Use this to check that the firmware was downloaded successfully to the ASC disk.

k. Enter the dspfwrevs command to verify the correct firmware revision.

l. Enter the tftp put <ASC_FW_file> AXIS_ASC_STANDBY.FW command.

m. Check the file size of the downloaded firmware.Use this step to check that the firmware was downloaded successfully to the ASC disk.

n. Enter the dspfwrevs command to verify the correct firmware revision.

Step 5 For all SMs, set the start and end addresses in Flash memory where the boot code file will be written.

a. Enter the flashStartAddr and flashEndAddr commands to start the Flash memory file at Oxbfc00000 and end it at 0xbfc40000

shelf.1.<slot>.<type><a|s>flashStartAddr = 0xbfc00000
shelf.1.<slot>.<type>.<a|s>flashEndAddr = 0xbfc40000

b. Enter the tftp put <SM_BT_file> AXIS_SM_1_$slot.FW command.

c. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

d. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

Step 6 For all SMs, set the start and end addresses in Flash memory where the firmware file will be written.

a. Enter the flashStartAddr and flashEndAddr commands to start the Flash memory file at Oxbfc40000 and end it at 0xbfd00000

shelf.1.<slot>.<type><a|s>flashStartAddr = 0xbfc40000
shelf.1.<slot>.<type>.<a|s>flashEndAddr = 0xbfd00000

b. Enter the tftp put <SM_FW_file> AXIS_SM_1_$slot.FW command.

c. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

d. Enter the resetsys command. This command resets all cards on the shelf.

e. Enter the dspadrxlat command to ensure that the number of connections is correct.

Step 7 For all primary and stand-alone SMs, enter the dsptotals command.

Use this step to examine the number of lines, ports, and channels after the upgrade or downgrade. The values can be compared to those before the download and, therefore, it can be established that the configuration has remained the same.

Procedure 4—Standard Downgrade, 2-Core Card Set

Procedure 4 is used for 1.2.y to 2.x, 2.3.y to 2.x, and 3.3.y to 3.x.

Step 1 Check compatibility.

With any downgrade technique, there is always the issue of compatibility. Any release can be downgraded to any other release, but in many instances configuration information will be lost. Hardware incompatibilities can prevent some downgrades. For example, Release 2 and Release 3 service modules require two Flash chips. Release 4 SMs will be shipped with a single Flash chip. A Release 4 shelf containing BNM-E1 cards or service resource module 3T3 cards cannot be downgraded to Release 2 or Release 3. Check the compatibility matrix to determine if a particular downgrade is supported and how it could affect configuration loss.

Step 2 Enter the dspadrcxat command. Note the value of the ConnNumOfValidEntries parameter.

This value indicates the number of the connection. This command is run again at the end of the procedure to ensure that the number of connections has not changed.

Step 3 For all stand-alone and primary SMs

a. Enter the dsptotals command.

The configuration of the shelf should not be changed during the downgrade process. Use this step to examine the number of lines, ports, and channels before the upgrade or downgrade. A similar step can be made to examine the same configuration parameters after the upgrade or downgrade and, therefore, it can be established that the configuration has remained the same.

b. Enter the tftp put <ASC_BT_file> AXIS_ASC_BACKUP.FW command. This step downloads the new boot code into the ASC.

c. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

d. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

e. Enter the switchcc command to switch to the other ASC.

f. Enter the tftp put <ASC_BT_file> AXIS_ASC_BACKUP.FW command. This step downloads the new boot code into the second ASC.

g. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

h. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

i. Enter the tftp put <ASC_FW_file> AXIS_ASC_ACTIVE.FW command.

j. Check the file size of the downloaded firmware. Use this step to check that the firmware was downloaded successfully to the ASC disk.

k. Enter the dspfwrevs command to verify the correct firmware revision.

l. Enter the tftp put <ASC_FW_file> AXIS_ASC_STANDBY.FW command.

m. Check the file size of the downloaded firmware. Use this step to check that the firmware was downloaded successfully to the ASC disk.

n. Enter the dspfwrevs command to verify the correct firmware revision.

Step 4 For all SMs, set the start and end addresses in Flash memory where the boot code file will be written.

a. Enter the flashStartAddr and flashEndAddr commands to start the Flash memory file at Oxbfc00000 and end it at 0xbfc40000

shelf.1.<slot>.<type><a|s>flashStartAddr = 0xbfc00000
shelf.1.<slot>.<type>.<a|s>flashEndAddr = 0xbfc40000

b. Enter the tftp put <SM_BT_file> AXIS_SM_1_$slot.FW command.

c. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

d. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

Step 5 For all SMs, set the start and end addresses in Flash memory where the firmware file will be written.

a. Enter the flashStartAddr and flashEndAddr commands to start the Flash memory file at Oxbfc40000 and end it at 0xbfd00000

shelf.1.<slot>.<type><a|s>flashStartAddr = 0xbfc40000
shelf.1.<slot>.<type>.<a|s>flashEndAddr = 0xbfd00000

b. Enter the tftp put <SM_FW_file> AXIS_SM_1_$slot.FW command.

c. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

d. Enter the resetsys or clrallcnf command. These commands reset all cards on the shelf.

e. Set the BRAM revision.

f. Enter the dspadrxlat command to ensure that the number of connections is correct.

Step 6 Enter the dsptotals command for all primary and stand-alone SMs.

Use this step to examine the number of lines, ports, and channels after the upgrade or downgrade. The values can be compared to those before the download and it can be established that the configuration has remained the same. Restore the ASC and SM configurations if necessary.

Procedure 5—Standard Upgrade, 1-Core Card Set

Procedure 5 is used for 1.2.x to 4.y, and 2.3.x to 4.y.

Step 1 Save the current ASC configuration. Perform this step for the ASC prior to upgrading the firmware.

First reset the card, then use TFTP get to save the card's current configuration in the workstation.

tftp shelf
tftp> bin
tftp> get AXIS_ASC_ACTIVE.BR

Step 2 Save the current service module (SM) configuration for each primary and stand-alone SM. Perform this step for the SM prior to upgrading the firmware.

First reset the card, then use TFTP get to save the card's current configuration in the workstation.

tftp shelf
tftp> bin
tftp> get AXIS_SM_1_<slot>.PRI.<service password>

Step 3 Enter the dspadrcxat command. Note the value of the ConnNumOfValidEntries parameter.

This value indicates the number of connections. This command is run again at the end of the procedure to ensure that the number of connections has not changed.

Step 4 For all stand-alone and primary SMs

a. Enter the dsptotals command.

The configuration of the shelf should not be changed during the downgrade process. Use this step to examine the number of lines, ports, and channels before the upgrade or downgrade. A similar step can be made to examine the same configuration parameters after the upgrade or downgrade and, therefore, it can be established that the configuration has remained the same.

b. Enter the tftp put <ASC_BT_file> AXIS_ASC_BACKUP.FW command. This step downloads the new boot code into the ASC.

c. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

d. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

e. Enter the tftp put <ASC_FW_file> AXIS_ASC_ACTIVE.FW command.

f. Check the file size of the downloaded firmware. This step can be used to check that the firmware was downloaded successfully to the ASC disk.

g. Enter the dspfwrevs command to verify the correct firmware revision.

Step 5 For all SMs, set the start and end addresses in Flash memory where the boot code file will be written.

a. Enter the flashStartAddr and flashEndAddr commands to start the Flash memory file at 0xbfc00000 and end it at 0xbfc80000

shelf.1.<slot>.<type><a|s>flashStartAddr = 0xbfc00000
shelf.1.<slot>.<type>.<a|s>flashEndAddr = 0xbfc80000

b. Enter the tftp put <SM_BT_file> AXIS_SM_1_$slot.FW command.

c. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

d. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

e. Enter the resetsys command.

Step 6 For all SMs

a. Enter the tftp put <SM_FW_file> AXIS_SM_1_$slot/0.FW command.

b. Check the file size of the downloaded firmware. Use this step to check that the firmware was downloaded successfully to the ASC disk.

c. Enter the dspfwrevs command. This command displays the current firmware revisions.

d. Enter the dspadrxlat command to ensure that the number of connections is correct.

Step 7 Enter the dsptotals command for all primary and stand-alone SMs.

Use this step to examine the number of lines, ports, and channels after the upgrade or downgrade. The values can be compared to those before the download and, therefore, it can be established that the configuration has remained the same. Restore the ASC and SM configurations if necessary.

Procedure 6—Standard Upgrade, 2-Core Card Set

Procedure 6 is used for 1.2.x to 4.y, and 2.3.x to 4.y.

Step 1 Save the current ASC configuration. Perform this step for the ASC prior to upgrading the firmware.

First reset the card, then use TFTP get to save the card's current configuration in the workstation.

tftp shelf
tftp> bin
tftp> get AXIS_ASC_ACTIVE.BR

Step 2 Save the current service module (SM) configuration for each primary and stand-alone SM. Perform this step for the SM prior to upgrading the firmware.

First reset the card, then use TFTP get to save the card's current configuration in the workstation.

tftp shelf
tftp> bin
tftp> get AXIS_SM_1_<slot>.PRI.<service password>

Step 3 Enter the dspadrcxat command. Note the value of the ConnNumOfValidEntries parameter.

This value indicates the number of connections. This command is run again at the end of the procedure to ensure that the number of connections did not change.

Step 4 For all stand-alone and primary SMs

a. Enter the dsptotals command.

The configuration of the shelf should not be changed during the downgrade process. Use this step to examine the number of lines, ports, and channels before the upgrade or downgrade. A similar step can be made to examine the same configuration parameters after the upgrade or downgrade and, therefore, it can be established that the configuration has remained the same.

b. Enter the tftp put <ASC_BT_file> AXIS_ASC_BACKUP.FW command. This step downloads the new boot code into the ASC.

c. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

d. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

e. Enter the switchcc command to switch to the other ASC.

f. Enter the tftp put <ASC_BT_file> AXIS_ASC_BACKUP.FW command. This step downloads the new boot code into the second ASC.

g. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

h. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

i. Enter the tftp put <ASC_FW_file> AXIS_ASC_ACTIVE.FW command.

j. Check the file size of the downloaded firmware. Use this step to check that the firmware was downloaded successfully to the ASC disk.

k. Enter the dspfwrevs command to verify the correct firmware revision.

l. Enter the tftp put <ASC_FW_file> AXIS_ASC_STANDBY.FW command.

m. Check the file size of the downloaded firmware. Use this step to check that the firmware was downloaded successfully to the ASC disk.

n. Enter the dspfwrevs command to verify the correct firmware revision.

Step 5 For all SMs, set the start and end addresses in Flash memory where the boot code file will be written.

a. Enter the flashStartAddr and flashEndAddr commands to start the Flash memory file at 0xbfc00000 and end it at 0xbfc80000

shelf.1.<slot>.<type><a|s>flashStartAddr = 0xbfc00000
shelf.1.<slot>.<type>.<a|s>flashEndAddr = 0xbfc80000

b. Enter the tftp put <SM_BT_file> AXIS_SM_1_$slot.FW command.

c. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

d. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

e. Enter the resetsys command. This command resets all cards on the shelf.

Step 6 For all SMs

a. Enter the tftp put <SM_FW_file> AXIS_SM_1_$slot/0.FW command.

b. Check the file size of the downloaded firmware. Use this step to check that the firmware was downloaded successfully to the ASC disk.

c. Enter the dspfwrevs command to verify the correct firmware revision.

d. Enter the dspadrxlat command to ensure that the number of connections is correct.

Step 7 Enter the dsptotals command for all primary and stand-alone SMs.

Use this step to examine the number of lines, ports, and channels after the upgrade or downgrade. The values can be compared to those before the download and, therefore, it can be established that the configuration has remained the same. Restore the ASC and SM configurations if necessary.

Procedure 7—Standard Downgrade, 1-Core Card Set

Procedure 7 is used for 1.4.y to 2.x, and 2.4.y to 3.x.

Step 1 Check compatibility.

With any downgrade technique, there is always the issue of compatibility. Any release can be downgraded to any other release, but in many instances configuration information will be lost. Hardware incompatibilities can prevent some downgrades. For example, Release 2 and Release 3 service modules require two Flash chips. Release 4 SMs will be shipped with a single Flash chip. A Release 4 shelf containing BNM-E1 cards or service resource module 3T3 cards cannot be downgraded to Release 2 or Release 3. Check the compatibility matrix to determine if a particular downgrade is supported and how it affects configuration loss.

Step 2 Enter the dspadrcxat command. Note the value of the ConnNumOfValidEntries parameter.

This value indicates the number of connections. This command is run again at the end of the procedure to ensure that the number of connections has not changed.

Step 3 For all stand-alone and primary SMs

a. Enter the dsptotals command.

The configuration of the shelf should not be changed during the downgrade process. Use this step to examine the number of lines, ports, and channels before the upgrade or downgrade. A similar step can be made to examine the same configuration parameters after the upgrade or downgrade and, therefore, it can be established that the configuration has remained the same.

b. Enter the tftp put <ASC_BT_file> AXIS_ASC_BACKUP.FW command. This step downloads the new boot code into the ASC.

c. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

d. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

e. Enter the tftp put <ASC_FW_file> AXIS_ASC_ACTIVE.FW command.

f. Check the file size of the downloaded firmware. Use this step to check that the firmware was downloaded successfully to the ASC disk.

g. Enter the dspfwrevs command to verify the correct firmware revision.

Step 4 For all SMs

a. Enter the tftp put <SM_BT_file> AXIS_SM_1_$slot.BOOT command.

b. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

c. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

Step 5 For all SMs, set the start and end addresses in Flash memory where the boot code file will be written.

a. Enter the flashStartAddr and flashEndAddr commands to start the Flash memory file at 0xbfc40000 and end it at 0xbfd00000

shelf.1.<slot>.<type><a|s>flashStartAddr = 0xbfc40000
shelf.1.<slot>.<type>.<a|s>flashEndAddr = 0xbfd0000

b. Enter the tftp put <SM_FW_file> AXIS_SM_1_$slot.BOOT command.

c. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

d. Enter the clrallcnf command. This command resets all cards on the shelf.

Step 6 For all SMs, perform the dsptotals command.

Use this step to examine the number of lines, ports, and channels after the upgrade or downgrade. The values can be compared to those before the download and, therefore, it can be established that the configuration remained the same. Restore the ASC and SM configurations if necessary.

Procedure 8—Standard Downgrade, 2-Core Card Set

Procedure 8 is used for 1.4.y to 2.x, and 2.4.y to 3.x.

Step 1 Check compatibility.

With any downgrade technique, there is always the issue of compatibility. Any release can be downgraded to any other release, but in many instances configuration information will be lost. Hardware incompatibilities can prevent some downgrades. For example, Release 2 and Release 3 service modules require two Flash chips. Release 4 SMs will be shipped with a single Flash chip. A Release 4 shelf containing BNM-E1 cards or service resource module 3T3 cards cannot be downgraded to Release 2 or Release 3. Check the compatibility matrix to determine if a particular downgrade is supported and how it affects configuration loss.

Step 2 Enter the dspadrcxat command. Note the value of the ConnNumOfValidEntries parameter.

This value indicates the number of connections. This command is run again at the end of the procedure to ensure that the number of connections did not change.

Step 3 For all stand-alone and primary SMs

a. Enter the dsptotals command.

The configuration of the shelf should not be changed during the downgrade process. Use this step to examine the number of lines, ports, and channels before the upgrade or downgrade. A similar step can be made to examine the same configuration parameters after the upgrade or downgrade and, therefore, it can be established that the configuration remained the same.

a. Enter the tftp put <ASC_BT_file> AXIS_ASC_BACKUP.FW command. This step downloads the new boot code into the ASC.

b. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

c. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

d. Enter the switchcc command to switch to the other ASC.

e. Enter the tftp put <ASC_BT_file> AXIS_ASC_BACKUP.FW command. This step downloads the new boot code into the second ASC.

f. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

g. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

h. Enter the tftp put <ASC_FW_file> AXIS_ASC_ACTIVE.FW command.

i. Check the file size of the downloaded firmware. Use this step to check that the firmware was downloaded successfully to the ASC disk.

j. Enter the dspfwrevs command to verify the correct firmware revision.

k. Enter the tftp put <ASC_FW_file> AXIS_ASC_STANDBY.FW command.

l. Check the file size of the downloaded firmware. Use this step to check that the firmware was downloaded successfully to the ASC disk.

m. Enter the dspfwrevs command to verify the correct firmware revision.

Step 4 For all SM

a. Enter the tftp put <SM_BT_file> AXIS_SM_!$slot.BOOT command.

b. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

c. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

Step 5 For all SMs, set the start and end addresses in Flash memory where the boot code file is written.

a. Enter the flashStartAddr and flashEndAddr commands to start the Flash memory file at Oxbfc40000 and end it at 0xbfd00000

shelf.1.<slot>.<type><a|s>flashStartAddr = 0xbfc40000
shelf.1.<slot>.<type>.<a|s>flashEndAddr = 0xbfd00000

b. Enter the tftp put <SM_FW_file> AXIS_SM_1_$slot.BOOT command.

c. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

d. Enter the clrallcnf command. This command resets all cards on the shelf.

Step 6 For all SMs, enter the dsptotals command.

Use this step to examine the number of lines, ports, and channels after the upgrade or downgrade. The values can be compared to those before the download and, therefore, it can be established that the configuration has remained the same. Restore the ASC and SM configurations if necessary.

Procedure 9—Standard Upgrade, 1-Core Card Set

Procedure 9 is used for 4.x to 4.y, 4x to 5.x, and 5.x to 5.y.

Step 1 Save the current ASC configuration. Perform this step for the ASC prior to upgrading the firmware.

First reset the card, then use TFTP get to save the card's current configuration in the workstation.

tftp shelf
tftp> bin
tftp> get AXIS_ASC_ACTIVE.BR

Step 2 Save the current service module (SM) configuration for each primary and stand-alone SM. Perform this step for the SM prior to upgrading the firmware.

First reset the card, then use TFTP get to save the card's current configuration in the workstation.

tftp shelf
tftp> bin
tftp> get AXIS_SM_1_<slot>.PRI.<service password>

Step 3 Enter the dspadrcxat command. Note the value of the ConnNumOfValidEntries parameter.

This value indicates the number of connections. This command is run again at the end of the procedure to ensure that the number of connections did not changed.

Step 4 For all stand-alone and primary SMs

a. Enter the dsptotals command.

The configuration of the shelf should not be changed during the downgrade process. Use this step to examine the number of lines, ports, and channels before the upgrade or downgrade. A similar step can be made to examine the same configuration parameters after the upgrade or downgrade and, therefore, it can be established that the configuration has remained the same.

b. Enter the tftp put <ASC_BT_file> AXIS_ASC_BACKUP.FW command. This step downloads the new boot code into the ASC.

c. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

d. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

e. Enter the tftp put <ASC_FW_file> AXIS_ASC_ACTIVE.FW command.

f. Enter the file size of the downloaded firmware. This step is used to check that the firmware Enter the dspfwrevs command to verify the correct firmware revision.

Step 5 For all SMs

a. Enter the tftp put <SM_BT_file> AXIS_SM_1_$slot.BOOT command.

b. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

c. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

d. Enter the tftp put <SM_FW_file> AXIS_SM_1_$slot/0.FW command.

e. Check the file size of the downloaded firmware. This step is used to check that the firmware was downloaded successfully to the ASC disk.

f. Enter the dspfwrevs command. This command displays the current firmware revisions.

g. Enter the resetsys command. This command resets all cards on the shelf.

Step 6 For all SMs, enter the dsptotals command.

Use this step to examine the number of shelf connections, lines, ports, and channels after the upgrade or downgrade. The values can be compared to those before the download and, therefore, it can be established that the configuration has remained the same.

Procedure 10—Standard Upgrade, 2-Core Card Set

Procedure 10 is used for 4.x to 4.y, 4x to 5.x, and 5.x to 5.y.

Step 1 Save the current ASC configuration. Perform this step for the ASC prior to upgrading the firmware.

First reset the card, then use TFTP get to save the card's current configuration in the workstation.

tftp shelf
tftp> bin
tftp> get AXIS_ASC_ACTIVE.BR

Step 2 Save the current service module (SM) configuration for each primary and stand-alone SM. Perform this step for the SM prior to upgrading the firmware.

First reset the card, then use TFTP get to save the card's current configuration in the workstation.

tftp shelf
tftp> bin
tftp> get AXIS_SM_1_<slot>.PRI.<service password>

Step 3 Enter the dspadrcxat command. Note the value of the ConnNumOfValidEntries parameter.

This value indicates the number of connections. This command is run again at the end of the procedure to ensure that the number of connections has not changed.

Step 4 For all stand-alone and primary SMs

a. Enter the dsptotals command.

The configuration of the shelf should not be changed during the downgrade process. Use this step to examine the number of lines, ports, and channels before the upgrade or downgrade. A similar step can be made to examine the same configuration parameters after the upgrade or downgrade and, therefore, it can be established that the configuration has remained the same.

b. Enter the tftp put <ASC_BT_file> AXIS_ASC_BACKUP.FW command. This step downloads the new boot code into the ASC.

c. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

d. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

e. Enter the switchcc command to switch to the other ASC.

f. Enter the tftp put <ASC_BT_file> AXIS_ASC_BACKUP.FW command. This step downloads the new boot code into the second ASC.

g. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

h. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

i. Enter the tftp put <ASC_FW_file> AXIS_ASC_ACTIVE.FW command.

j. Check the file size of the downloaded firmware. Use this step to check that the firmware was downloaded successfully to the ASC disk.

k. Enter the dspfwrevs command to verify the correct firmware revision.

l. Enter the tftp put <ASC_FW_file> AXIS_ASC_STANDBY.FW command.

m. Check the file size of the downloaded firmware. Use this step to check that the firmware was downloaded successfully to the ASC disk.

n. Enter the dspfwrevs command to verify the correct firmware revision.

Step 5 For all SMs

a. Enter the tftp put <SM_BT_file> AXIS_SM_1_$slot.BOOT command.

b. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

c. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

Step 6 For all SMs

a. Enter the tftp put <SM_FW_file> AXIS_SM_1_$slot/0.FW command.

b. Check the file size of the downloaded firmware. Use this step to check that the firmware was downloaded successfully to the ASC disk.

c. Enter the dspfwrevs command to verify the correct firmware revision.

d. Enter the resetsys command. This command resets all cards on the shelf.

e. Enter the dspadrxlat command to ensure that the number of connections is correct.

Step 7 For all primary and stand-alone SMs, enter the dsptotals command.

Use this step to examine the number of lines, ports, and channels after the upgrade or downgrade. The values can be compared to those before the download and, therefore, it can be established that the configuration has remained the same. Restore the ASC and SM configurations if necessary.

Procedure 11—Standard Downgrade, 1-Core Card Set

Procedure 11 is used for 4.x to 4.y, 4x to 5.x, and 5.x to 5.y.

Step 1 Check compatibility.

With any downgrade technique, there is always the issue of compatibility. Any release can be downgraded to any other release, but in many instances configuration information will be lost. Hardware incompatibilities can prevent some downgrades. For example, Release 2 and Release 3 service modules require two Flash chips. Release 4 SMs will be shipped with a single Flash chip. A Release 4 shelf containing BNM-E1 cards or service resource module 3T3 cards cannot be downgraded to Release 2 or Release 3. Check the compatibility matrix to determine if a particular downgrade is supported and how it affects configuration loss.

Step 2 Save the current ASC configuration. Perform this step for the ASC prior to upgrading the firmware.

First reset the card, then use TFTP get to save the card's current configuration in the workstation.

tftp shelf
tftp> bin
tftp> get AXIS_ASC_ACTIVE.BR

Step 3 Save the current service module (SM) configuration for each primary and stand-alone SM. Perform this step for the SM prior to upgrading the firmware.

First reset the card, then use TFTP get to save the card's current configuration in the workstation.

tftp shelf
tftp> bin
tftp> get AXIS_SM_1_<slot>.PRI.<service password>

Step 4 Enter the dspadrcxat command. Note the value of the ConnNumOfValidEntries parameter.

This value indicates the number of connection. This command is run again at the end of the procedure to ensure that the number of connections has not changed.

Step 5 For all stand-alone and primary SMs

a. Enter the dsptotals command.

The configuration of the shelf should not be changed during the downgrade process. Use this step to examine the number of lines, ports, and channels before the upgrade or downgrade. A similar step can be made to examine the same configuration parameters after the upgrade or downgrade and, therefore, it can be established that the configuration has remained the same.

b. Enter the tftp put <ASC_BT_file> AXIS_ASC_BACKUP.FW command. This step downloads the new boot code into the ASC.

c. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

d. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

e. Enter the tftp put <ASC_FW_file> AXIS_ASC_ACTIVE.FW command.

f. Check the file size of the downloaded firmware. Use this step to check that the firmware was downloaded successfully to the ASC disk.

g. Enter the dspfwrevs command to verify the correct firmware revision.

Step 6 For all SMs

a. Enter the tftp put <SM_BT_file> AXIS_SM_1_$slot.BOOT command.

b. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

c. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

d. Enter the tftp put <SM_FW_file> AXIS_SM_1_$slot/0.FW command.

e. Check the file size of the downloaded firmware. Use this step to check that the firmware was downloaded successfully to the ASC disk.

f. Enter the dspfwrevs command. This command displays the current firmware revisions.

g. Enter the resetsys command. This command resets all cards on the shelf.

h. Enter the dspadrxlat command to ensure that the number of connections is correct.

Step 7 For all primary and stand-alone SMs, enter the dsptotals command.

Use this step to examine the number of lines, ports, and channels after the upgrade or downgrade. The values can be compared to those before the download and, therefore, it can be established that the configuration has remained the same. Restore the ASC and SM configurations if necessary.

Procedure 12—Standard Downgrade, 2-Core Card Set

Procedure 12 is used for 4.x to 4.y, 4x to 5.x, and 5.x to 5.y.

Step 1 Check compatibility.

With any downgrade technique, there is always the issue of compatibility. Any release can be downgraded to any other release, but in many instances configuration information will be lost. Hardware incompatibilities can prevent some downgrades. For example, Release 2 and Release 3 service modules require two Flash chips. Release 4 SMs will be shipped with a single Flash chip. A Release 4 shelf containing BNM-E1 cards or service resource module 3T3 cards cannot be downgraded to Release 2 or Release 3. Check the compatibility matrix to determine if a particular downgrade is supported and how it affects configuration loss.

Step 2 Save the current ASC configuration. Perform this step for the ASC prior to upgrading the firmware.

First reset the card, then use TFTP get to save the card's current configuration in the workstation.

tftp shelf
tftp> bin
tftp> get AXIS_ASC_ACTIVE.BR

Step 3 Save the current service module (SM) configuration for each primary and stand-alone SM. Perform this step for the SM prior to upgrading the firmware.

First reset the card, then use TFTP get to save the card's current configuration in the workstation.

tftp shelf
tftp> bin
tftp> get AXIS_SM_1_<slot>.PRI.<service password>

Step 4 Enter the dspadrcxat command. Note the value of the ConnNumOfValidEntries parameter.

This value indicates the number of connections. This command is run again at the end of the procedure to ensure that the number of connections has not changed.

Step 5 For all stand-alone and primary SMs

a. Enter the dsptotals command.

The configuration of the shelf should not be changed during the downgrade process. Use this step to examine the number of lines, ports, and channels before the upgrade or downgrade. A similar step can be made to examine the same configuration parameters after the upgrade or downgrade and, therefore, it can be established that the configuration has remained the same.

b. Enter the tftp put <ASC_BT_file> AXIS_ASC_BACKUP.FW command. This step downloads the new boot code into the ASC.

c. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

d. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

e. Enter the switchcc command to switch to the other ASC.

f. Enter the tftp put <ASC_BT_file> AXIS_ASC_BACKUP.FW command. This step downloads the new boot code into the second ASC.

g. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

h. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

i. Enter the tftp put <ASC_FW_file> AXIS_ASC_ACTIVE.FW command.

j. Check the file size of the downloaded firmware. Use this step to check that the firmware was downloaded successfully to the ASC disk.

k. Enter the dspfwrevs command to verify the correct firmware revision.

l. Enter the tftp put <ASC_FW_file> AXIS_ASC_STANDBY.FW command.

m. Check the file size of the downloaded firmware. Use this step to check that the firmware was downloaded successfully to the ASC disk.

n. Enter the dspfwrevs command to verify the correct firmware revision.

Step 6 For all SMs

a. Enter the tftp put <SM_BT_file> AXIS_SM_1_$slot.BOOT command.

b. Enter the chkflash command.

This command calculates and compares the Flash checksum to verify whether the boot code is correct.

c. Enter the version command.

This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

Step 7 For all SMs

a. Enter the tftp put <SM_FW_file> AXIS_SM_1_$slot/0.FW command.

b. Check the file size of the downloaded firmware. Use this step to check that the firmware was downloaded successfully to the ASC disk.

c. Enter the dspfwrevs command to verify the correct firmware revision.

d. Enter the resetsys command. This command resets all cards on the shelf.

e. Enter the dspadrxlat command to ensure that the number of connections is correct.

Step 8 For all primary and stand-alone SMs enter the dsptotals command.

Use this step to examine the number of lines, ports, and channels after the upgrade or downgrade. The values can be compared to those before the download and, therefore, it can be established that the configuration has remained the same. Restore the ASC and SM configurations if necessary.

Graceful Upgrade and Downgrade Procedures

These procedures must be performed at a UNIX workstation that has an operating data path to the MGX 8220. The workstation must be able to send MGX 8220 CLI commands and UNIX Trivial File Transfer Protocol (TFTP) downloads.

A CWM workstation attached to a BPX is one method in which MGX 8220 commands and TFTP commands can be run on the MGS 8220 using an inband channel. The workstation can also be attached to the MGX 8220 through an Ethernet LAN, or through a TCP/IP connection on the control port on the ASC.

Procedure 13—Graceful Upgrade, 1-Core Card Set (SM only)

Procedure 13 is used for 1.2.x to 2.y.

Step 1 Save the current ASC configuration. Perform this step for the ASC prior to upgrading the firmware.

First reset the card, then use TFTP get to save the card's current configuration in the workstation.

tftp shelf
tftp> bin
tftp> get AXIS_ASC_ACTIVE.BR

Step 2 Save the current service module (SM) configuration for each primary and stand-alone SM. Perform this step for the SM prior to upgrading the firmware.

First reset the card, then use TFTP get to save the card's current configuration in the workstation.

tftp shelf
tftp> bin
tftp> get AXIS_SM_1_<slot>.PRI.<service password>

Step 3 Enter the dspadrcxat command. Note the value of the ConnNumOfValidEntries parameter.

This value indicates the number of connection. This command is run again at the end of the procedure to ensure that the number of connections has not changed.

Step 4 For all SMs, enter the dsptotals command.

The configuration of the shelf should not be changed during the downgrade process. Use this step to examine the number of lines, ports, and channels before the upgrade or downgrade. A similar step can be made to examine the same configuration parameters after the upgrade or downgrade and, therefore, it can be established that the configuration has remained the same.

Step 5 For all SMs

a. Enter the flashStartAddr and flashEndAddr commands to start the Flash memory file at 0xbfc00000 and end it at 0xbfc40000.

shelf.1.<slot>.<type><a|s>flashStartAddr = 0xbfc00000
shelf.1.<slot>.<type>.<a|s>flashEndAddr = 0xbfc40000

b. Enter the tftp put <SM_BT_file> AXIS_SM_1_$slot.FW command.

c. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

d. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

Step 6 For all SMs

a. Enter the flashStartAddr and flashEndAddr commands to start the Flash memory file at Oxbfc40000 and end it at 0xbfd00000

shelf.1.<slot>.<type><a|s>flashStartAddr = 0xbfc40000
shelf.1.<slot>.<type>.<a|s>flashEndAddr = 0xbfd00000

b. Enter the tftp put <SM_FW_file> AXIS_SM_1_$slot.FW command.

c. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

Step 7 For all SMs, enter the resetcd command. This command resets the card.

Step 8 For all SMs, enter the dsptotals command.

Use this step to examine the number of shelf connections, lines, ports, and channels after the upgrade or downgrade. The values can be compared to those before the download and, therefore, it can be established that the configuration has remained the same.

Procedure 14—Graceful Downgrade, 1-Core Card Set (SM only)

Procedure 14 is used for 1.2.y to 2.x.

Step 1 Check compatibility.

With any downgrade technique, there is always the issue of compatibility. Any release can be downgraded to any other release, but in many instances configuration information will be lost. Hardware incompatibilities can prevent some downgrades. For example, Release 2 and Release 3 service modules require two Flash chips. Release 4 SMs will be shipped with a single Flash chip. A Release 4 shelf containing BNM-E1 cards or service resource module 3T3 cards cannot be downgraded to Release 2 or Release 3. Check the Compatibility Matrix to determine if a particular downgrade is supported and how it affects configuration loss.

Step 2 Save the current ASC configuration. Perform this step for the ASC prior to upgrading the firmware.

First reset the card, then use TFTP get to save the card's current configuration in the workstation.

tftp shelf
tftp> bin
tftp> get AXIS_ASC_ACTIVE.BR

Step 3 Save the current service module (SM) configuration for each primary and stand-alone SM. Perform this step for the SM prior to upgrading the firmware.

First reset the card, then use TFTP get to save the card's current configuration in the workstation.

tftp shelf
tftp> bin
tftp> get AXIS_SM_1_<slot>.PRI.<service password>

Step 4 Enter the dspadrcxat command. Note the value of the ConnNumOfValidEntries parameter.

This value indicates the number of connection. This command is run again at the end of the procedure to ensure that the number of connections has not changed.

Step 5 For all SMs, enter the dsptotals command.

The configuration of the shelf should not be changed during the downgrade process. Use this step to examine the number of lines, ports, and channels before the upgrade or downgrade. A similar step can be made to examine the same configuration parameters after the upgrade or downgrade and, therefore, it can be established that the configuration has remained the same.

Step 6 For all SMs, set the start and end addresses in Flash memory where the firmware file will be written.

a. Enter the flashStartAddr and flashEndAddr commands to start the Flash memory file at 0xbfc00000 and end it at 0xbfc40000

shelf.1.<slot>.<type><a|s>flashStartAddr = 0xbfc00000
shelf.1.<slot>.<type>.<a|s>flashEndAddr = 0xbfc40000

b. Enter the tftp put <SM_BT_file> AXIS_SM_1_$slot.FW command.

c. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

d. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

e. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

f. Enter the flashStartAddr and flashEndAddr commands to start the Flash memory file at 0xbfc40000 and end it at 0xbfd00000

shelf.1.<slot>.<type><a|s>flashStartAddr = 0xbfc40000
shelf.1.<slot>.<type>.<a|s>flashEndAddr = 0xbfd00000

g. Enter the tftp put <SM_FW_file> AXIS_SM_1_$slot.FW command.

h. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

i. Enter the resetcd command. This command resets the card.

Step 7 For all SMs, enter the dsptotals command.

Use this step to examine the number of shelf connections, lines, ports, and channels after the upgrade or downgrade. The values can be compared to those before the download and, therefore, it can be established that the configuration has remained the same. Restore the ASC and SM configurations if necessary.

Procedure 15—Graceful Upgrade, 2-Core Card Set

Procedure 15 is used for 1.2.x to 2.y.

Step 1 Save the current ASC configuration. Perform this step for the ASC prior to upgrading the firmware.

First reset the card, then use TFTP get to save the card's current configuration in the workstation.

tftp shelf
tftp> bin
tftp> get AXIS_ASC_ACTIVE.BR

Step 2 Save the current service module (SM) configuration for each primary and stand-alone SM. Perform this step for the SM prior to upgrading the firmware.

First reset the card, then use TFTP get to save the card's current configuration in the workstation.

tftp shelf
tftp> bin
tftp> get AXIS_SM_1_<slot>.PRI.<service password>

Step 3 Enter the dspadrcxat command. Note the value of the ConnNumOfValidEntries parameter.

This value indicates the number of connections. This command is run again at the end of the procedure to ensure that the number of connections has not changed.

Step 4 For all SMs

a. Enter the dsptotals command.

The configuration of the shelf should not be changed during the downgrade process. Use this step to examine the number of lines, ports, and channels before the upgrade or downgrade. A similar step can be made to examine the same configuration parameters after the upgrade or downgrade and, therefore, it can be established that the configuration has remained the same.

b. Enter the tftp put <ASC_BT_file> AXIS_ASC_BACKUP.FW command. This step downloads the new boot code into the ASC.

c. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

d. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

e. Enter the switchcc command to switch to the other ASC.

f. Enter the tftp put <ASC_BT_file> AXIS_ASC_BACKUP.FW command. This step downloads the new boot code into the second ASC.

g. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

h. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

i. Enter the donotupdatestandby command.

j. Enter the tftp put <ASC_FW_file> AXIS_ASC_STANDBY.FW command.

k. Check the file size of the downloaded firmware. Use this step to check the firmware was downloaded successfully to the ASC disk.

l. Enter the dspfwrevs command to verify the correct firmware revision.

Step 5 For all SMs, set the start and end addresses in Flash memory where the boot code file will be written.

a. Enter the flashStartAddr and flashEndAddr commands to start the Flash memory file at 0xbfc00000 and end it at 0xbfc40000

shelf.1.<slot>.<type><a|s>flashStartAddr = 0xbfc00000
shelf.1.<slot>.<type>.<a|s>flashEndAddr = 0xbfc40000

b. Enter the tftp put <SM_BT_file> AXIS_SM_1_$slot.FW command.

c. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

d. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

Step 6 For all SMs, set the start and end addresses in Flash memory where the firmware file will be written.

a. Enter the flashStartAddr and flashEndAddr commands to start the Flash memory file at 0xbfc40000 and end it at 0xbfd00000

shelf.1.<slot>.<type><a|s>flashStartAddr = 0xbfc40000
shelf.1.<slot>.<type>.<a|s>flashEndAddr = 0xbfd00000

b. Enter the tftp put <SM_FW_file> AXIS_SM_1_$slot.FW command.

c. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

d. Enter the resetcd <standby_ASC> command. This command resets the standby card.

e. Enter the resetcd <active_ASC> command. This command resets the active card.

Step 7 For all SMs

a. Enter the resetcd command. This command resets the card.

b. Enter the dspadrxlat command to ensure that the number of connections is correct.

Step 8 For all SMs, enter the dsptotals command.

Use this step to examine the number of lines, ports, and channels after the upgrade or downgrade. The values can be compared to those before the download and, therefore, it can be established that the configuration has remained the same. Restore the ASC and SM configurations if necessary.

Procedure 16—Graceful Downgrade, 2-Core Card Set

Procedure 16 is used for 1.2.x to 2.y.

Step 1 Check compatibility.

With any downgrade technique, there is always the issue of compatibility. Any release can be downgraded to any other release, but in many instances configuration information will be lost. Hardware incompatibilities can prevent some downgrades. For example, Release 2 and Release 3 service modules require two Flash chips. Release 4 SMs will be shipped with a single Flash chip. A Release 4 shelf containing BNM-E1 cards or service resource module 3T3 cards cannot be downgraded to Release 2 or Release 3. Check the compatibility matrix to determine if a particular downgrade is supported and how it affects configuration loss.

Step 2 Save the current ASC configuration. Enter this step for the ASC prior to upgrading the firmware.

First reset the card, then use TFTP get to save the card's current configuration in the workstation.

tftp shelf
tftp> bin
tftp> get AXIS_ASC_ACTIVE.BR

Step 3 Save the current service module (SM) configuration for each primary and stand-alone SM. Perform this step for the SM prior to upgrading the firmware.

First reset the card, then use TFTP get to save the card's current configuration in the workstation.

tftp shelf
tftp> bin
tftp> get AXIS_SM_1_<slot>.PRI.<service password>

Step 4 Enter the dspadrcxat command. Note the value of the ConnNumOfValidEntries parameter.

This value indicates the number of connections. This command is run again at the end of the procedure to ensure that the number of connections has not changed.

Step 5 For all SMs

a. Enter the dsptotals command.

The configuration of the shelf should not be changed during the downgrade process. Use this step to examine the number of lines, ports, and channels before the upgrade or downgrade. A similar step can be made to examine the same configuration parameters after the upgrade or downgrade and, therefore, it can be established that the configuration has remained the same.

b. Enter the tftp put <ASC_BT_file> AXIS_ASC_BACKUP.FW command. This step downloads the new boot code into the ASC.

c. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

d. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

e. Enter the switchcc command to switch to the other ASC.

f. Enter the tftp put <ASC_BT_file> AXIS_ASC_BACKUP.FW command. This step downloads the new boot code into the second ASC.

g. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

h. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

i. Enter the donotupdatestandby command.

j. Enter the tftp put <ASC_FW_file> AXIS_ASC_STANDBY.FW command.

k. Check the file size of the downloaded firmware. Use this step to check that the firmware was downloaded successfully to the ASC disk.

l. Enter the dspfwrevs command to verify the correct firmware revision.

Step 6 For all SMs, set the start and end addresses in Flash memory where the boot code file will be written.

a. Enter the flashStartAddr and flashEndAddr commands to start the Flash memory file at 0xbfc00000 and end it at 0xbfc40000

shelf.1.<slot>.<type><a|s>flashStartAddr = 0xbfc00000
shelf.1.<slot>.<type>.<a|s>flashEndAddr = 0xbfc40000

b. Enter the tftp put <SM_BT_file> AXIS_SM_1_$slot.FW command.

c. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

d. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

Step 7 For all SMs, set the start and end addresses in Flash memory where the firmware file will be written.

a. Enter the flashStartAddr and flashEndAddr commands to start the Flash memory file at 0xbfc40000 and end it at 0xbfd00000

shelf.1.<slot>.<type><a|s>flashStartAddr = 0xbfc40000
shelf.1.<slot>.<type>.<a|s>flashEndAddr = 0xbfd00000

b. Enter the tftp put <SM_FW_file> AXIS_SM_1_$sl26 command.

c. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

d. Enter the resetcd <standby_ASC>command. This command resets the standby card.

e. Enter the resetcd <active_ASC>command. This command resets the active card.

Step 8 For all SMs

a. Enter the resetcd command. This command resets the card.

b. Enter the dspadrxlat command to ensure that the number of connections is correct.

Step 9 For all SMs, enter the dsptotals command.

Use this step to examine the number of lines, ports, and channels after the upgrade or downgrade. The values can be compared to those before the download and, therefore, it can be established that the configuration has remained the same. Restore the ASC and SM configurations if necessary.

Procedure 17—Graceful Upgrade, 1-Core Card Set (SM only)

Procedure 17 is used for 1.3.x to 3.y.

Step 1 Save the current ASC configuration. Perform this step for the ASC prior to upgrading the firmware.

First reset the card, then use TFTP get to save the card's current configuration in the workstation.

tftp shelf
tftp> bin
tftp> get AXIS_ASC_ACTIVE.BR

Step 2 Save the current service module (SM) configuration for each primary and stand-alone SM. Perform this step for the SM prior to upgrading the firmware.

First reset the card, then use TFTP get to save the card's current configuration in the workstation.

tftp shelf
tftp> bin
tftp> get AXIS_SM_1_<slot>.PRI.<service password>

Step 3 For all primary and stand-alone SMs, enter the dsptotals command.

The configuration of the shelf should not be changed during the upgrade or downgrade process. Use this step to examine the number of shelf connections. A similar step can be made to examine the same configuration parameters after the upgrade or downgrade and, therefore, it can be established that the configuration has remained the same.

Step 4 For all SMs, set the start and end addresses in Flash memory where the firmware file will be written.

a. Enter the flashStartAddr and flashEndAddr commands to start the Flash memory file at Oxbfc00000 and end it at 0xbfc40000

shelf.1.<slot>.<type><a|s>flashStartAddr = 0xbfc00000
shelf.1.<slot>.<type>.<a|s>flashEndAddr = 0xbfc40000

b. Enter the tftp put <SM_BT_file> AXIS_SM_1_$slot.FW command.

c. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

d. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

Step 5 For all SMs

a. Enter the flashStartAddr and flashEndAddr commands to start the Flash memory file at 0xbfc40000 and end it at 0xbfd00000

shelf.1.<slot>.<type><a|s>flashStartAddr = 0xbfc40000
shelf.1.<slot>.<type>.<a|s>flashEndAddr = 0xbfd00000

b. Enter the tftp put <SM_FW_file> AXIS_SM_1_$slot.FW command.

c. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

Step 6 For all stand-alone SMs, enter the resetcd <stand-alone_SM>.

Step 7 For all primary SMs in all redundany groups

a. Enter the resetcd command <primary_SM>.

b. Enter the resetcd command <secondary_SM>.

Step 8 For all primary and stand-alone SMs in all redundancy groups, enter the dsptotals command.

Use this step to examine the number of shelf connections, lines, ports, and channels after the upgrade or downgrade. The values can be compared to those before the download and, therefore, it can be established that the configuration has remained the same.

Procedure 18—Graceful Downgrade, 1-Core Card Set (SM only)

Procedure 18 is used for 1.3.y to 3.x.

Step 1 Check compatibility.

With any downgrade technique, there is always the issue of compatibility. Any release can be downgraded to any other release, but in many instances configuration information will be lost. Hardware incompatibilities can prevent some downgrades. For example, Release 2 and Release 3 service modules require two Flash chips. Release 4 SMs will be shipped with a single Flash chip. A Release 4 shelf containing BNM-E1 cards or service resource module 3T3 cards cannot be downgraded to Release 2 or Release 3. Check the compatibility matrix to determine if a particular downgrade is supported and how it affects configuration loss.

Step 2 Save the current ASC configuration. Perform this step for the ASC prior to upgrading the firmware.

First reset the card, then use TFTP get to save the card's current configuration in the workstation.

tftp shelf
tftp> bin
tftp> get AXIS_ASC_ACTIVE.BR

Step 3 Save the current service module (SM) configuration for each primary and stand-alone SM. Perform this step for the SM prior to upgrading the firmware.

First reset the card, then use TFTP get to save the card's current configuration in the workstation.

tftp shelf
tftp> bin
tftp> get AXIS_SM_1_<slot>.PRI.<service password>

Step 4 For all primary and stand-alone SMs, enter the dsptotals command.

The configuration of the shelf should not be changed during the upgrade or downgrade process. Use this step to examine the number of shelf connections. A similar step can be made to examine the same configuration parameters after the upgrade or downgrade and, therefore, it can be established that the configuration has remained the same.

Step 5 For all SMs, set the start and end addresses in Flash memory where the firmware file will be written.

a. Enter the flashStartAddr and flashEndAddr commands to start the Flash memory file at 0xbfc00000 and end it at 0xbfc40000

shelf.1.<slot>.<type><a|s>flashStartAddr = 0xbfc00000
shelf.1.<slot>.<type>.<a|s>flashEndAddr = 0xbfc40000

b. Enter the tftp put <SM_BT_file> AXIS_SM_1_$slot.FW command.

c. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

d. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

Step 6 For all SMs

a. Enter the flashStartAddr and flashEndAddr commands to start the Flash memory file at 0xbfc40000 and end it at 0xbfd00000

shelf.1.<slot>.<type><a|s>flashStartAddr = 0xbfc40000
shelf.1.<slot>.<type>.<a|s>flashEndAddr = 0xbfd00000

b. Enter the tftp put <SM_FW_file> AXIS_SM_1_$slot.FW command.

c. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

Step 7 For all stand-alone SMs, enter the resetcd command <stand-alone_SM>.

Step 8 For all primary SMs in all redundancy groups

a. Enter the resetcd command <primary_SM>.

b. Enter the resetcd command <secondary_SM>.

Step 9 For all primary and stand-alone SMs in all redundancy group, enter the dsptotals command.

Use this step to examine the number of shelf connections, lines, ports, and channels after the upgrade or downgrade. The values can be compared to those before the download and, therefore, it can be established that the configuration has remained the same. Restore ASC and SM configurations if necessary.

Procedure 19—Graceful Upgrade, 2-Core Card Set

Procedure 19 is used for 1.3.x to 3.y.

Step 1 Save the current ASC configuration. Perform this step for the ASC prior to upgrading the firmware.

First reset the card, then use TFTP get to save the card's current configuration in the workstation.

tftp shelf
tftp> bin
tftp> get AXIS_ASC_ACTIVE.BR

Step 2 Save the current service module (SM) configuration for each primary and stand-alone SM. Perform this step for the SM prior to upgrading the firmware.

First reset the card, then use TFTP get to save the card's current configuration in the workstation.

tftp shelf
tftp> bin
tftp> get AXIS_SM_1_<slot>.PRI.<service password>

Step 3 Enter the dspadrcxat command. Note the value of the ConnNumOfValidEntries parameter.

This value indicates the number of connections. This command is run again at the end of the procedure to ensure that the number of connections has not changed.

Step 4 For all SMs

a. This value indicates the dsptotals command.

The configuration of the shelf should not be changed during the downgrade process. Use this step to examine the number of lines, ports, and channels before the upgrade or downgrade. A similar step can be made to examine the same configuration parameters after the upgrade or downgrade and, therefore, it can be established that the configuration has remained the same.

b. Enter the tftp put <ASC_BT_file> AXIS_ASC_BACKUP.FW command. This step downloads the new boot code into the ASC.

c. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

d. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

e. Enter the switchcc command to switch to the other ASC.

f. Enter the tftp put <ASC_BT_file> AXIS_ASC_BACKUP.FW command. This step downloads the new boot code into the second ASC.

g. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

h. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

i. Enter the donotupdatestandby command.

j. Enter the tftp put <ASC_FW_file> AXIS_ASC_STANDBY.FW command.

k. Check the file size of the downloaded firmware. Use this step to check the firmware was downloaded successfully to the ASC disk.

l. Enter the dspfwrevs command to verify the correct firmware revision.

Step 5 For all SMs, set the start and end addresses in Flash memory where the boot code file will be written.

a. Enter the flashStartAddr and flashEndAddr commands to start the Flash memory file at 0xbfc00000 and end it at 0xbfc40000

shelf.1.<slot>.<type><a|s>flashStartAddr = 0xbfc00000
shelf.1.<slot>.<type>.<a|s>flashEndAddr = 0xbfc40000

b. Enter the tftp put <SM_BT_file> AXIS_SM_1_$slot.FW command.

c. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

d. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

Step 6 For all SMs, set the start and end addresses in Flash memory where the firmware file will be written.

a. Enter the flashStartAddr and flashEndAddr commands to start the Flash memory file at 0xbfc40000 and end it at 0xbfd00000

shelf.1.<slot>.<type><a|s>flashStartAddr = 0xbfc40000
shelf.1.<slot>.<type>.<a|s>flashEndAddr = 0xbfd00000

b. Enter the tftp put <SM_FW_file> AXIS_SM_1_$slot.FW command.

c. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

d. Enter the resetcd <standby_ASC> command. This command resets the standby card.

e. Enter the resetcd <active_ASC> command. This command resets the active card.

Step 7 For all stand-alone SMs

a. Enter the resetcd <stand-alone> command. This command resets the stand-alone card.

b. Enter the dspadrxlat command to ensure that the number of connection is correct.

Step 8 For all primary SMs in all redundancy groups

a. Enter the resetcd command <primary_SM>

b. Enter the resetcd command <secondary_SM>

Step 9 For all SMs, enter the dsptotals command.

This step is to examine the number of lines, ports, and channels after the upgrade or downgrade. The values can be compared to those before the download and, therefore, it can be established that the configuration has remained the same. Restore the ASC and SM configurations if necessary.

Procedure 20—Graceful Upgrade, 2-Core Card Set

Procedure 20 is used for 1.3.x to 3.y.

Step 1 Check compatibility.

With any downgrade technique, there is always the issue of compatibility. Any release can be downgraded to any other release, but in many instances configuration information will be lost. Hardware incompatibilities can prevent some downgrades. For example, Release 2 and Release 3 service modules require two Flash chips. Release 4 SMs will be shipped with a single Flash chip. A Release 4 shelf containing BNM-E1 cards or service resource module 3T3 cards cannot be downgraded to Release 2 or Release 3. Check the compatibility matrix to determine if a particular downgrade is supported and how it affects configuration loss.

Step 2 Save the current ASC configuration. Perform this step for the ASC prior to upgrading the firmware.

First reset the card, then use TFTP get to save the card's current configuration in the workstation.

tftp shelf
tftp> bin
tftp> get AXIS_ASC_ACTIVE.BR

Step 3 Save the current service module (SM) configuration for each primary and stand-alone SM. Perform this step for the SM prior to upgrading the firmware.

First reset the card, then use TFTP get to save the card's current configuration in the workstation.

tftp shelf
tftp> bin
tftp> get AXIS_SM_1_<slot>.PRI.<service password>

Step 4 Enter the dspadrcxat command. Note the value of the ConnNumOfValidEntries parameter.

This value indicates the number of connections. This command is run again at the end of the procedure to ensure that the number of connections has not changed.

Step 5 For all SMs

a. Enter the dsptotals command.

The configuration of the shelf should not be changed during the downgrade process. Use this step to examine the number of lines, ports, and channels before the upgrade or downgrade. A similar step can be made to examine the same configuration parameters after the upgrade or downgrade and, therefore, it can be established that the configuration has remained the same.

b. Enter the tftp put <ASC_BT_file> AXIS_ASC_BACKUP.FW command. This step downloads the new boot code into the ASC.

c. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

d. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

e. Enter the switchcc command to switch to the other ASC.

f. Enter the tftp put <ASC_BT_file> AXIS_ASC_BACKUP.FW command. This step downloads the new boot code into the second ASC.

g. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

h. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

i. Enter the donotupdatestandby command.

j. Enter the tftp put <ASC_FW_file> AXIS_ASC_STANDBY.FW command.

k. Check the file size of the downloaded firmware. Use this step to check the firmware was downloaded successfully to the ASC disk.

l. Enter the dspfwrevs command to verify the correct firmware revision.

Step 6 For all SMs, set the start and end addresses in Flash memory where the boot code file will be written.

a. Enter the flashStartAddr and flashEndAddr commands to start the Flash memory file at 0xbfc00000 and end it at 0xbfc40000

shelf.1.<slot>.<type><a|s>flashStartAddr = 0xbfc00000
shelf.1.<slot>.<type>.<a|s>flashEndAddr = 0xbfc40000

b. Enter the tftp put <SM_BT_file> AXIS_SM_1_$slot.FW command.

c. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

d. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

Step 7 For all SMs, set the start and end addresses in Flash memory where the firmware file will be written.

a. Enter the flashStartAddr and flashEndAddr commands to start the Flash memory file at 0xbfc40000 and end it at 0xbfd00000

shelf.1.<slot>.<type><a|s>flashStartAddr = 0xbfc40000
shelf.1.<slot>.<type>.<a|s>flashEndAddr = 0xbfd00000

b. Enter the tftp put <SM_FW_file> AXIS_SM_1_$slot.FW command.

c. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

d. Enter the resetcd <standby_ASC> command. This command resets the standby card.

e. Enter the resetcd <active_ASC> command. This command resets the active card.

Step 8 For all stand-alone SMs

a. Enter the resetcd <stand-alone>command. This command resets the stand-alone card.

b. Enter the dspadrxlat command to ensure that the number of connection is correct.

Step 9 For all primary SMs in all redundancy groups:

a. Enter the resetcd <primary_SM>.

b. Enter the resetcd <secondary_SM>.

Step 10 For all SMs, enter the dsptotals command.

Use this step to examine the number of lines, ports, and channels after the upgrade or downgrade. The values can be compared to those before the download and, therefore, it can be established that the configuration has remained the same. Restore the ASC and SM configurations if necessary.

Procedure 21—Graceful Upgrade, 2-Core Card Set

Procedure 21 is used for 1.3.x to 4.y.

Step 1 Save the current ASC configuration. Perform this step for the ASC prior to upgrading the firmware.

First reset the card, then use TFTP get to save the card's current configuration in the workstation.

tftp shelf
tftp> bin
tftp> get AXIS_ASC_ACTIVE.BR

Step 2 Save the current service module (SM) configuration for each primary and stand-alone SM. Perform this step for the SM prior to upgrading the firmware.

First reset the card, then use TFTP get to save the card's current configuration in the workstation.

tftp shelf
tftp> bin
tftp> get AXIS_SM_1_<slot>.PRI.<service password>

Step 3 Enter the dspadrcxat command. Note the value of the ConnNumOfValidEntries parameter.

This value indicates the number of connections. This command is run again at the end of the procedure to ensure that the number of connections has not changed.

Step 4 For all primary and stand-alone SMs

a. Enter the dsptotals command.

The configuration of the shelf should not be changed during the downgrade process. Use this step to examine the number of lines, ports, and channels before the upgrade or downgrade. A similar step can be made to examine the same configuration parameters after the upgrade or downgrade and, therefore, it can be established that the configuration has remained the same.

b. Enter the tftp put <ASC_BT_file> AXIS_ASC_BACKUP.FW command. This step downloads the new boot code into the ASC.

c. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

d. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

e. Enter the switchcc command to switch to the other ASC.

f. Enter the tftp put <ASC_BT_file> AXIS_ASC_BACKUP.FW command. This step downloads the new boot code into the second ASC.

g. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

h. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

i. Enter the donotupdatestandby command.

j. Enter the tftp put <ASC_FW_file> AXIS_ASC_STANDBY.FW command.

k. Check the file size of the downloaded firmware. Use this step to check that the firmware was downloaded successfully to the ASC disk.

l. Enter the dspfwrevs command to verify the correct firmware revision.

Step 5 For all SMs, set the start and end addresses in Flash memory where the boot code file will be written.

a. Enter the flashStartAddr and flashEndAddr commands to start the Flash memory file at 0xbfc00000 and end it at 0xbfc80000

shelf.1.<slot>.<type><a|s>flashStartAddr = 0xbfc00000
shelf.1.<slot>.<type>.<a|s>flashEndAddr = 0xbfc80000

b. Enter the tftp put <SM_BT_file> AXIS_SM_1_$slot.FW command.

c. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

d. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

e. Enter the resetcd <standby_ASC> command. This command resets the standby card.

f. Enter the resetcd <active_ASC> command. This command resets the active card.

Step 6 For all SMs

a. Enter the tftp put <SM_FW_file> AXIS_SM_1_$slot/0.FW command.

b. Check the file size of the downloaded firmware. Use this step to check that the firmware was downloaded successfully to the ASC disk.

c. Enter the dspfwrevs command to verify the correct firmware revision.

Step 7 For all stand-alone SMs, enter the resetcd <stand-alone>command. This command resets the stand-alone card.

Step 8 For all primary SMs in all redundancy groups

a. Enter the softswitch <primary_SM> command.

b. Enter the softswitch <secondary_SM> command.

Step 9 For all SMs, enter the dsptotals command.

Use this step to examine the number of lines, ports, and channels after the upgrade or downgrade. The values can be compared to those before the download and, therefore, it can be established that the configuration has remained the same. Restore the ASC and SM configurations if necessary.

Procedure 22—Graceful Downgrade, 1-Core Card Set (SM only)

Procedure 22 is used for 4.x to 4.y, 4x to 5.x, and 5.x to 5.y.

Step 1 Save the current ASC configuration. Perform this step for the ASC prior to upgrading the firmware.

First reset the card, then use TFTP get to save the card's current configuration in the workstation.

tftp shelf
tftp> bin
tftp> get AXIS_ASC_ACTIVE.BR

Step 2 Save the current service module (SM) configuration for each primary and stand-alone SM. Perform this step for the SM prior to upgrading the firmware.

First reset the card, then use TFTP get to save the card's current configuration in the workstation.

tftp shelf
tftp> bin
tftp> get AXIS_SM_1_<slot>.PRI.<service password>

Step 3 For all SMs, enter the dsptotals command.

The configuration of the shelf should not be changed during the upgrade or downgrade process. Use this step to examine the number of shelf connections. A similar step can be made to examine the same configuration parameters after the upgrade or downgrade and, therefore, it can be established that the configuration has remained the same.

Step 4 For all SMs

a. Enter the tftp put <SM_BT_file> AXIS_SM_1_$slot.FW command.

b. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

c. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

Step 5 For all SMs

a. Enter the tftp put <SM_FW_file> AXIS_SM_1_$slot.FW command.

b. Check the file size of the downloaded firmware. Use this step to check that the firmware was downloaded successfully to the ASC disk.

c. Enter the dspfwrevs command to verify the correct firmware revision.

Step 6 For all stand-alone SMs, enter the resetcd command <stand-alone_SM>

Step 7 For all primary SMs in all redundancy groups:

a. Enter the softswitch <primary_SM> <secondary_SM> command.

b. Enter the softswitch <secondary_SM> <primary_SM> command.

Step 8 For all SMs, enter the dsptotals command.

Use this step to examine the number of shelf connections, lines, ports, and channels after the upgrade or downgrade. The values can be compared to those before the download and, therefore, it can be established that the configuration has remained the same. Restore ASC and SM configurations if necessary.

Procedure 23—Graceful Upgrade, 2-Core Card Set

Procedure 23 is used for 4.x to 4.y, 4x to 5.x, and 5.x to 5.y.

Step 1 Save the current ASC configuration. Perform this step for the ASC prior to upgrading the firmware.

First reset the card, then use TFTP get to save the card's current configuration in the workstation.

tftp shelf
tftp> bin
tftp> get AXIS_ASC_ACTIVE.BR

Step 2 Save the current service module (SM) configuration for each primary and stand-alone SM. Perform this step for the SM prior to upgrading the firmware.

First reset the card, then use TFTP get to save the card's current configuration in the workstation.

tftp shelf
tftp> bin
tftp> get AXIS_SM_1_<slot>.PRI.<service password>

Step 3 Enter the dspadrcxat command. Note the value of the ConnNumOfValidEntries parameter.

This value indicates the number of connections. This command is run again at the end of the procedure to ensure that the number of connections has not changed.

Step 4 For all primary and stand-alone SMs

a. Enter the dsptotals command.

The configuration of the shelf should not be changed during the downgrade process. Use this step to examine the number of lines, ports, and channels before the upgrade or downgrade. A similar step can be made to examine the same configuration parameters after the upgrade or downgrade and, therefore, it can be established that the configuration has remained the same.

b. Enter the tftp put <ASC_BT_file> AXIS_ASC_BACKUP.FW command. This step downloads the new boot code into the ASC.

c. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

d. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

e. Enter the switchcc command to switch to the other ASC.

f. Enter the tftp put <ASC_BT_file> AXIS_ASC_BACKUP.FW command. This step downloads the new boot code into the second ASC.

g. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

h. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

i. Enter the donotupdatestandby command.

j. Enter the tftp put <ASC_FW_file> AXIS_ASC_STANDBY.FW command.

k. Check the file size of the downloaded firmware. Use this step to check that the firmware was downloaded successfully to the ASC disk.

l. Enter the dspfwrevs command to verify the correct firmware revision.

Step 5 For all SMs

a. Enter the tftp put <SM_BT_file> AXIS_SM_1_$slot.BOOT command.

b. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

c. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

Step 6 For all SMs

a. Enter the tftp put <SM_FW_file> AXIS_SM_1_$slot/0.FW command.

b. Check the file size of the downloaded firmware. Use this step to check that the firmware was downloaded successfully to the ASC disk.

c. Enter the dspfwrevs command to verify the correct firmware revision.

d. Enter the resetcd <standby_ASC> command. This command resets the standby card.

e. Enter the resetcd <active_ASC> command. This command resets the active card.

Step 7 For all stand-alone SMs, enter the resetcd <stand-alone> command. This command resets the stand-alone card.

Step 8 For all primary SMs in all redundancy groups

a. Enter the softswitch <primary_SM> <secondary_SM> command.

b. Enter the softswitch <secondary_SM> <primary_SM> command.

Step 9 For all SMs, enter the dsptotals command.

Use this step to examine the number of lines, ports, and channels after the upgrade or downgrade. The values can be compared to those before the download and, therefore, it can be established that the configuration has remained the same. Restore the ASC and SM configurations if necessary.

Procedure 24—Graceful Downgrade, 1-Core Card Set (SM only)

Procedure 24 is used for 4.x to 4.y, 4x to 5.x, and 5.x to 5.y.

Step 1 Check compatibility.

With any downgrade technique, there is always the issue of compatibility. Any release can be downgraded to any other release, but in many instances configuration information will be lost. Hardware incompatibilities can prevent some downgrades. For example, Release 2 and Release 3 service modules require two Flash chips. Release 4 SMs will be shipped with a single Flash chip. A Release 4 shelf containing BNM-E1 cards or service resource module 3T3 cards cannot be downgraded to Release 2 or Release 3. Check the compatibility matrix to determine if a particular downgrade is supported and how it affects configuration loss.

Step 2 Save the current ASC configuration. Perform this step for the ASC prior to upgrading the firmware.

First reset the card, then use TFTP get to save the card's current configuration in the workstation.

tftp shelf
tftp> bin
tftp> get AXIS_ASC_ACTIVE.BR

Step 3 Save the current service module (SM) configuration for each primary and stand-alone SM. Perform this step for the SM prior to upgrading the firmware.

First reset the card, then use TFTP get to save the card's current configuration in the workstation.

tftp shelf
tftp> bin
tftp> get AXIS_SM_1_<slot>.PRI.<service password>

Step 4 For all primary and stand-alone SMs, enter the dsptotals command.

The configuration of the shelf should not be changed during the upgrade or downgrade process. Use this step to examine the number of shelf connections. A similar step can be made to examine the same configuration parameters after the upgrade or downgrade and, therefore, it can be established that the configuration has remained the same.

Step 5 For all SMs, set the start and end addresses in Flash memory where the firmware file will be written.

a. Enter the tftp put <SM_BT_file> AXIS_SM_1_$slot.BOOT command.

b. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

c. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

Step 6 For all SMs

a. Enter the tftp put <SM_FW_file> AXIS_SM_1_$slot/0.FW command.

b. Check the file size of the downloaded firmware. Use this step to check that the firmware was downloaded successfully to the ASC disk.

c. Enter the dspfwrevs command to verify the correct firmware revision.

Step 7 For all stand-alone SMs, enter the resetcd <stand-alone_SM> command.

Step 8 For all primary SMs in all redundancy groups

a. Enter the resetcd <primary_SM> <secondary_SM> command.

b. Enter the resetcd <secondary_SM> <primary_SM> command.

Step 9 For all primary and stand-alone SMs in all redundancy groups, enter the dsptotals command.

This step is to examine the number of shelf connections, lines, ports, and channels after the upgrade or downgrade. The values can be compared to those before the download and, therefore, it can be established that the configuration has remained the same. Restore ASC and SM configurations if necessary.

Procedure 25—Graceful Upgrade, 2-Core Card Set

Procedure 25 is used for 4.x to 4.y, 4x to 5.x, and 5.x to 5.y.

Step 1 Check compatibility.

With any downgrade technique, there is always the issue of compatibility. Any release can be downgraded to any other release, but in many instances configuration information will be lost. Hardware incompatibilities can prevent some downgrades. For example, Release 2 and Release 3 service modules require two Flash chips. Release 4 SMs will be shipped with a single Flash chip. A Release 4 shelf containing BNM-E1 cards or service resource module 3T3 cards cannot be downgraded to Release 2 or Release 3. Check the compatibility matrix to determine if a particular downgrade is supported and how it affects configuration loss.

Step 2 Save the current ASC configuration. Perform this step for the ASC prior to upgrading the firmware.

First reset the card, then use TFTP get to save the card's current configuration in the workstation.

tftp shelf
tftp> bin
tftp> get AXIS_ASC_ACTIVE.BR

Step 3 Save the current service module (SM) configuration for each primary and stand-alone SM. Perform this step for the SM prior to upgrading the firmware.

First reset the card, then use TFTP get to save the card's current configuration in the workstation.

tftp shelf
tftp> bin
tftp> get AXIS_SM_1_<slot>.PRI.<service password>

Step 4 Enter the dspadrcxat command. Note the value of the ConnNumOfValidEntries parameter.

This value indicates the number of connections. This command is run again at the end of the procedure to ensure that the number of connections has not changed.

Step 5 For all primary and stand-alone SMs

a. Enter the dsptotals command.

The configuration of the shelf should not be changed during the downgrade process. Use this step to examine the number of lines, ports, and channels before the upgrade or downgrade. A similar step can be made to examine the same configuration parameters after the upgrade or downgrade and, therefore, it can be established that the configuration has remained the same.

b. Enter the tftp put <ASC_BT_file> AXIS_ASC_BACKUP.FW command. This step downloads the new boot code into the ASC.

c. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

d. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

e. Enter the switchcc command to switch to the other ASC.

f. Enter the tftp put <ASC_BT_file> AXIS_ASC_BACKUP.FW command. This step downloads the new boot code into the second ASC.

g. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

h. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

i. Enter the donotupdatestandby command.

j. Enter the tftp put <ASC_FW_file> AXIS_ASC_STANDBY.FW command.

k. Check the file size of the downloaded firmware. Use this step to check that the firmware was downloaded successfully to the ASC disk.

l. Enter the dspfwrevs command to verify the correct firmware revision.

Step 6 For all SMs

a. Enter the tftp put <SM_BT_file> AXIS_SM_1_$slot.BOOT command.

b. Enter the chkflash command. This command calculates and compares the Flash checksum to verify whether the boot code is correct.

c. Enter the version command. This command displays the version of the boot code currently stored in Flash memory. This step downloads new firmware into the ASC.

Step 7 For all SMs

a. Enter the tftp put <SM_FW_file> AXIS_SM_1_$slot/0.FW command.

b. Check the file size of the downloaded firmware. Use this step to check that the firmware was downloaded successfully to the ASC disk.

c. Enter the dspfwrevs command to verify the correct firmware revision.

d. Enter the resetcd <standby_ASC> command. This command resets the standby card.

e. Enter the resetcd <active_ASC> command. This command resets the active card.

Step 8 For all stand-alone SMs, enter the resetcd <stand-alone>command. This command resets the stand-alone card.

Step 9 For all primary SMs in all redundancy groups

a. Enter the softswitch <primary_SM> <secondary_SM> command.

b. Enter the softswitch <secondary_SM> <primary_SM> command.

Step 10 For all SMs, enter the dsptotals command.

This step is to examine the number of lines, ports, and channels after the upgrade or downgrade. The values can be compared to those before the download and, therefore, it can be established that the configuration has remained the same. Restore the ASC and SM configurations if necessary.

Description of Upgrade/Downgrade Terminology

Standard

A standard upgrade/downgrade technique is the simplest and fastest method for upgrading/downgrading between a pair of firmware and/or backup boot code releases. A standard technique trades traffic loss for simplicity and speed.

Graceful

A graceful upgrade/downgrade technique attempts to minimize traffic loss at the expense of added complexity and time. For example, the service module graceful upgrade from Release 3.x to Release 3.y for a shelf with a 9:1 redundancy group requires 18 resetcd operations and can take 20 minutes. The average traffic loss per connection approximately 20 seconds. The service module standard upgrade from Release 3.x to Release 3.y requires only a single resetsys command and can take 60 seconds, but the average traffic loss per connection can be over a minute.

One-cc

1-core card set (MGX 8220 shelf controller [ASC] broadband network module [BNM] [SRM]).

Two-cc

2-core card sets (ASC BNM [SRM]).

chkflash

The MGX 8220 ASC and service module CLI command, chkflash, calculates and compares the Flash checksum. In some releases, the chkflash command reports the firmware or backup boot code version as it resides in Flash. In this case, the version reported by the chkflash command should be compared with the version of firmware or backup boot code which was TFTP-put.

Example: shelf.1.<slot>.<type>.<a|s>chkflash

Version

The MGX 8220 ASC and service module (SM) CLI command, version, displays the backup boot code version that is currently stored in Flash (not necessarily the version of backup boot code that is running) and the firmware version that is running.

Example: shelf.1.<slot>.<type>.<a|s>version

tftp put

The UNIX TFTP (Trivial File Transfer Program) is used to write firmware or backup boot code to the ASC Flash or disk, and to the SM Flash.

Example:

tftp shelf

tftp> bin

tftp> put <file> AXIS_<FILE>.<EXTENSION>

tftp> quit

The number of bytes reported as being sent by the TFTP routine should be compared with the size of the firmware or backup boot code file.

Example:

ls -l <file>

-rw-rw-rw- <size> <file>

tftp> put <file> AXIS_<FILE>.<EXTENSION>

Sent <size> bytes in <seconds>seconds

File Size

The firmware file size tends to be rather unique. The firmware file size can be used to verify that the firmware file was successfully TFTP-put to the ASC disk.

Example:

shelf.1.<3|4>.ASC.<a|s>shellConn

shelf.1.<3|4>.ASC.<a|s> cd "C:fw"

shelf.1.<3|4>.ASC.<a|s> ll

size

date

time

name

512

<date>

<time>

.

512

<date>

<time>

.

<size>

<date>

<time>

ASC.FW


dspfwrevs

The dspfwrevs command was first introduced in Releases 2.1.25 and 4.0.02 and later in Release 3. Any time ASC firmware is TFTP put to an ASC card running Release 2.1.25 or Release 4.0.02 (or greater), the dwpfwrevs command can be used to ensure that the ASC firmware was successfully TFTP-put to the disk. Any time SM firmware is TFTP-put to an ASC card running Release 4.0.02 (or greater), the dwpfwrevs command can be used to ensure that the SM firmware was successfully TFTP-put to the disk.

Example: shelf.1.<3|4>.ASC.<a|s> dspfwrevs

Config

File Name

Card Type

Version

—

asc fw

ASC

<version>


Slot-Specific and Card-Type-Specific SM Firmware

MGX 8220 active ASC cards running Release 2 or Release 3 firmware support TFTP-putting slot-specific SM firmware. This means that firmware is TFTP-put to each SM slot individually. The SM firmware is written directly to the SM Flash. Within the upgrade/downgrade techniques, this is denoted as

tftp put <SM_FW_file> AXIS_SM_1_$slot.FW

MGX 8220 active ASC cards running Release 4 firmware support TFTP-putting card-type-specific
SM firmware (in addition to slot-specific SM firmware). In Release 4, the SM firmware is written to the ASC disk instead of the SM Flash as in Releases 2 and 3.

In Release 4, a single SM firmware file can be TFTP put to the ASC disk for all SMs of a particular card type. This is denoted as

tftp put <SM_FW_file> AXIS_SM_1_0.FW

Each time an SM is reset, it downloads the SM firmware file based on its card type. MGX 8220 active ASC cards running Release 4 firmware also support TFTP-putting slot-type-specific SM firmware. The SM firmware is still written to the ASC disk.

Slot-specific SM firmware takes precedence over card-type-specific firmware. That is, for a SM of a particular card type in a particular slot, if both card-type-specific and slot-specific firmware files exist, the slot-specific firmware is downloaded to the SM.

A CONFIG.SYS file on the ASC disk keeps track of which SM firmware files are "in effect." If an SM firmware file (slot-specific or card-type-specific) is not contained within the CONFIG.SYS file, it is not downloaded to an SM.

An SM firmware file is automatically added to the CONFIG.SYS file when it is TFTP-put to the active ASC disk, and when the active ASC disk downloads the SM firmware file to the standby ASC disk. A SM firmware file can be removed from the CONFIG.SYS file entering the delcfgsys command.

The dspfwrevs command can be used to list all of the SM firmware files on the active and standby ASC disks and identify which SM firmware files are contained within the CONFIG.SYS file.

flashStartAddr and flashEndAddr

The flashStartAddr and flashEndAddr commands are simply variables that determine where within Flash memory a file will be written. The ASC flashStartAddr defaults to 0xbfc00000 (ASC backup boot code) and need never be changed (the ASC firmware resides on the ASC disk in Releases 2, 3, and 4). The ASC flashEndAddr defaults to 0xbfc80000.

In Releases 2 and 3, the SM flashStartAddr defaults to 0xbfc40000 (SM firmware) after the SM is reset. The SM flashEndAddr defaults to 0xbfd00000.

In Release 4, the SM flashStartAddr defaults to 0xbfc00000 (SM backup boot code) after the SM is reset. The SM flashEndAddr defaults to 0xbfc80000.

SM backup boot code (Releases 2 and 3):

shelf.1.<slot>.<type>.<a|s>shellConn

shelf.1.<slot>.<type>.<a|s>flashStartAddr = 0xbfc00000

shelf.1.<slot>.<type>.<a|s>flashEndAddr = 0xbfc40000

SM backup boot code (Release 4):

shelf.1.<slot>.<type>.<a|s>shellConn

shelf.1.<slot>.<type>.<a|s>flashStartAddr = 0xbfc00000

shelf.1.<slot>.<type>.<a|s>flashEndAddr = 0xbfc80000

SM firmware (Releases 2 and 3):

shelf.1.<slot>.<type>.<a|s>shellConn

shelf.1.<slot>.<type>.<a|s>flashStartAddr = 0xbfc40000

shelf.1.<slot>.<type>.<a|s>flashEndAddr = 0xbfd00000

resetsys

The MGX 8220 active ASC CLI command, resetsys, is used to reset all the cards in the MGX 8220 shelf.

shelf.1.<3|4>.ASC.a > resetsys

The resetsys command terminates all Telnet sessions. You must re-initiate a Telnet session after an ASC card returns to the active state.

softswitch

The MGX 8220 active ASC CLI command, softswitch, is used to transfer traffic between a primary and secondary SM, while greatly minimizing the traffic loss. The softswitch command is available in Release 4.

shelf.1.<3|4>.ASC.a > softswitch <primary> <secondary>

shelf.1.<3|4>.ASC.a > softswitch <secondary> <primary>

dspadrxlat

Any upgrade that involves resetting the active ASC card and any downgrade in which the configuration is preserved should compare the number of shelf connections before and after the upgrade/downgrade. This is accomplished by entering the MGX 8220 ASC CLI command.

shelf.1.<3|4>.ASC.a > dspadrxlat

The most important information is

ConnNumOfValidEntries: <value>

You should not make configuration changes to the shelf while an upgrade or downgrade is in progress. There is a chance that all or part of the configuration changes could be lost.

dsptotals

Any upgrade that involves resetting a stand-alone or primary service module should compare the total number of lines, ports and channels before and after the upgrade/downgrade. This is accomplished by entering the MGX 8220 SM CLI command.

shelf.1.<slot>.<type>.a > dsptotals

The most important information is

total active lines = <value>/<maximumlines>

total active ports = <value>/<maximumports>

total active chans = <value>/<maximumchannels>

You should not make configuration changes to the shelf while an upgrade or downgrade is in progress. There is a chance that all or part of the configuration changes could be lost.

donotupdatestandby

The MGX 8220 active ASC CLI command, donotupdatestandby, is used as part of an ASC graceful firmware upgrade to prevent the active ASC card from downloading firmware or configuration information to a reset standby ASC card. Some ASC firmware releases include the MGX 8220 active ASC CLI command, updatestandby, which can be used to undo the effects of the donotupdatestandby command.

shelf.1.<3|4>.ASC.a > donotupdatestandby

Compatibility

With any downgrade technique, there is always the issue of compatibility. Any release can be downgraded to any other release, but in many instances configuration information will be lost. Hardware incompatibilities can prevent some downgrades. For example, Releases 2 and 3 service modules require two Flash chips. Release 4 SMs will be shipped with a single Flash chip. A Release 4 shelf containing BNM-E1 cards or service resource module 3T3 cards cannot be downgraded to Release 2 or Release 3. Check the compatibility matrix to determine if a particular downgrade is supported and how it affects configuration loss.

clrallcnf

The MGX 8220 active ASC CLI command, clrallcnf, is used in place of the resetsys command as part of a downgrade in which the configuration information can not be maintained for compatibility reasons. The clrallcnf command will terminate all Telnet sessions. You must reinitiate a Telnet session after an ASC card returns to the active state.

resetsys or clrallcnf

Some standard techniques can involve releases that support downgrade without configuration loss (compatible releases). For these releases, the resetsys command can be used. For releases that involve configuration loss, the clrallcnf command should be used.

Save/Restore ASC Configuration

The ASC card stores ASC configuration information in BRAM (battery-backed RAM). The BRAM contains a revision that identifies the format of the configuration information. The format can change from release to release. The newer version of firmware always provides conversion routines that automatically reformat the configuration information as part of an upgrade. However, there is no support for reformatting as part of a firmware downgrade.

Upgrade/Downgrade

If the BRAM revision is different between the firmware revisions involved in an upgrade, the active ASC BRAM information should be saved prior to the upgrade using:

tftp shelf

tftp> bin

tftp> get AXIS_ASC_ACTIVE.BR

tftp> quit

In general, it is recommended to save the active ASC BRAM information prior to any upgrade.

If the BRAM revision is different between the firmware revisions involved in a downgrade, the active and standby ASC BRAM information should be restored following the downgrade using:

tftp shelf

tftp> bin

tftp> put AXIS_ASC_ACTIVE.BR

tftp> quit

tftp shelf

tftp> bin

tftp> put AXIS_ASC_ACTIVE.BR AXIS_ASC_STANDBY.BR

tftp> quit

The active and standby ASC cards must be reset in order to run the saved configuration. If the
ASC BRAM revision is the same between the firmware revisions involved in a downgrade, the ASC configuration should be preserved (there is no need to restore the configuration).

Save/Restore SM Configuration

The ASC card stores service module (SM) configuration information on the disk in a configuration (PRI) file. The file contains a revision which identifies the format of the configuration information. The format can change from release to release. The newer version of firmware always provides conversion routines which automatically reformat the configuration information as part of an upgrade. However, there is no support for reformatting as part of a firmware downgrade.

If the SM configuration file revision is different between the firmware revisions involved in an upgrade, the configuration file should be saved for each primary and stand-alone SM using:

tftp shelf

tftp> bin

tftp> get AXIS_SM_1_<slot>.PRI.<service password>

tftp> quit

In general, it is recommended to save the SM configuration file for each primary and stand-alone SM prior to any upgrade. If the SM configuration file revision is different between the firmware revisions involved in a downgrade, the configuration file should be restored for each primary and stand-alone SM using:

tftp shelf

tftp> bin

tftp> put AXIS_SM_1_<slot>.PRI.<service password>

tftp> quit

The standby ASC card must be reset in order to download the SM configuration files from the active ASC card. Each primary and stand-alone SM must be reset in order to run the saved configuration. If the SM configuration file revision is the same between the firmware revisions involved in a downgrade, the SM configuration should be preserved (there is no need to restore the configuration).

hometocprevnextglossaryfeedbacksearchhelp

Posted: Wed Nov 10 21:50:21 PST 2004
All contents are Copyright © 1992--2004 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.