User Manual

ADCP-75-192 • Issue D • October 2005 • Section 6: Software Updates
Page 6-5
 2005, ADC Telecommunications, Inc.
The HCP’s (FSC, HUC, RDC, and RUC) will automatically evaluate the hardware module
revision and determine if the FPGA image in the FPGA Prom is outdated. If this is the case,
the HCP will generate a “mismatched Revision” fault. This indicates to the operator that the
FPGA’s must be updated by following the manual restart process outlined below. The HCP’s
will use the transceptHcpLoadFpgaProm fields in the HCP MIB’s to report the status of the
Prom loading. The enumerated values in this MIB field are:
noStatus(0) : Indicates that no Prom Load has been attempted
loadingProm(1) : Indicates that a Prom Load is in progress / manually start a Prom Load.
loadSuccess(2) : Indicates that a Prom Load has completed successfully.
loadFailure(3) : Indicates that a Prom Load attempt has failed.
The transceptHcpLoadFpgaProm fields in the HUC, RDC, RUC, and FSC MIB’s need to be
monitored (via SNMP polling or traps) in order to detect failed FPGA Prom Loads (value =
loadFailure(3), which is a fault condition that needs to be remedied by manually restarting the
Prom Load session. This manual restart is accomplished by changing this MIB field to a value
of loadingProm(1). In addition to polling for loadFailure(3), the NMS should also poll for a
value of loadSuccess(2) in order to log the fact that a successful Prom Load has taken place,
and for a value of loadingProm(1) to know that a Prom Load is underway. Please refer to the
Fault and Troubleshooting guide for details.
3.6 Backup/Restore
There are several files on a CPU being upgraded that should be backed up in case something
goes wrong with the upgrade and need to be restored. This set of files includes the MIBmap
files where MIB data is stored, as well as several system configuration files.
The upgrade executable will automatically run the backup script to take care of backing up all
key files. These files will be bundled into a file that will be stored on the CPU being upgraded,
in the /var directory. This file will be given a name that associates it with version of the
upgrade being performed, for example: backup-pre-2.1.0.tar.gz.
Upgrading a CPU does not require that a restore of the backed up files be performed unless a
problem is encountered. Any data contained in the MIBmap files and any configuration data in
the system configuration files will remain untouched through a software upgrade. The only
time that backup data needs to be recovered is when an upgrade has failed and the CPU is
being reverted to the previous version using the downgrade script. In this event, the downgrade
script will automatically attempt to restore the backup data at the end of the downgrade
process.
Alternatively, the backup/restore steps can be run manually, with the backup file being saved
to any location on any CPU connected to the network. The steps for doing this are as follows:
3.6.1 Backup:
Telnet to the target CPU, using operator/operate as the username/password.
Run the backup script:
sudo backup-hubmaster operator@<target-IP>:/var <backupname>.tar