May 20061 Overview
1.1 p5 server hardware
1.2 System firmware fixes and upgrades
1.3 Decoding firmware names
1.4 Decoding the operator control panel
1.5 Temporary versus Permanent Firmware sides
1.6 Be Advised
2 Requirements
2.1 Software requirements
3 Upgrade firmware with HMC
3.1 Connectivity
3.2 HMC requirements
3.3 Viewing system firmware information using LIC wizard
3.4 Upgrade system firmware to a new release using HMC
3.5 Update system firmware within a release using HMC
3.6 Change License Internal Code Wizard
3.7 Reject the installed firmware using a HMC
4 Upgrade firmware without a HMC
4.1 Access ASMI via serial console
4.2 Checking the current firmware level
4.3 Power on using ASMI
4.4 Upgrade system firmware via running operating system
4.4.1 Upgrade firmware image using AIX
4.4.2 Upgrade firmware image using Linux
4.5 Upgrade firmware using diagnostics CD
5 Reject installed firmware without an HMC
5.1 Boot to the permanent side
5.2 Reject the installed firmware using an OS command
5.3 Reject the installed firmware using a diagnostic CD
6 Appendix common problems
7 References
The goal of this paper is to provide easy-to-read instructions to quickly update system firmware on p5 servers. It is assumed the reader has basic p5 skills. There are extensive references that should help with items not covered in this paper.
Three firmware update methods will be covered:
1. Update on an HMC managed system
2. Update on a standalone server via OS, without a HMC
3. Update on a standalone server using the Diagnostic CD, without a HMC
Please first read through the prerequisites before getting started on any of these upgrade sections. Then refer to any one section or all sections when choosing the preferred method for updating system firmware.
1.1 p5 server hardware
The hardware used in developing this paper was a p5 550Q (type-model 9133-55A). HMC (version 5.2.0 including fix MH00586) was also used when needed.1.2 System firmware fixes and upgrades
Firmware, also known as microcode, is Licensed Internal Code that fixes problems and enables new system features as they are introduced. New features introduced are supported by new firmware release levels. In between new hardware introductions, there are fixes or updates to the supported features. These fixes are often bundled into service packs. A service pack is referred to as an update level. A new release is referred to as an upgrade level. Both levels are represented by the file name in the form of PPMMXXX_YYY_ZZZ. PP and MM are package and machine type identifiers. PP can be 01 for managed system or it can be 02 for power subsystem. The MM identifier is a SF for p5 systems and a BP for Bulk Power Controller. The firmware version file applicable to p5 machines is in the form of 01SFXXX_YYY_ZZZ.1.3 Decoding firmware names
The file naming convention for system firmware is:01SFXXX_YYY_ZZZ, where
XXX is the stream release level
YYY is the service pack level
ZZZ is the last disruptive service pack level
Using the above example, the system firmware 01SF235_185 would be described as release level 235, service pack 185.
Each stream release level supports new machine types and/or new features.
Firmware updates can be disruptive or concurrent. A disruptive upgrade is defined as one that requires the target system to be shutdown and powered off prior to activating the new firmware level. A new release level upgrade will always be disruptive. All other upgrades are defined as concurrent, meaning that they can be applied while the system is running. Concurrent updates require an HMC but are not guaranteed to be non-disruptive.
In general, a firmware upgrade is disruptive if
1. The release levels (XXX) are different.
Example: Currently installed release is SF230, new release is SF235
2. The service pack level (YYY) and the last disruptive service pack level (ZZZ) are equal.
Example: SF235_180_180 is disruptive, no matter what level of SF235 is currently installed on the system
3. The service pack level (YYY) currently installed on the system is lower than the last disruptive service pack level (ZZZ) of the new service pack to be installed.
Example: Currently installed service pack is SF235_180_180 and the new service pack is SF235_190_185
An installation is concurrent if:
1. The service pack level (YYY) is higher than the service pack level currently installed on your system.
Example: Currently installed service pack is SF235_180_160, new service pack is SF235_185_160.
1.4 Decoding the operator control panel
When the system is powered on, note the operator control panel. It should appear similar to the image below.01 N V=F
HMC=1 T
In this example the system is currently booted from the temporary side of the firmware image as denoted in the control panel by the letter T. This indicates the firmware is running from the temporary side. N indicates the system is booted in normal mode. V=F indicates the boot speed is set to Fast. HMC=1 indicates that the server is managed by and connected to one HMC.
If it has been recently managed by an HMC and no HMC is connected then it will display HMC=0. If no HMC is available and it is desired to set the server to unmanaged it might be required to reset the service processor to factory default using ASMI.
1.5 Temporary versus Permanent Firmware sides
The Service Processor maintains two copies of firmware, the temporary and permanent side, to help manage and reduce the frequency of downtime for maintenance. The permanent side is also known as the "P" side. The temporary side is also known as the "T" side. Server firmware fixes are installed on the temporary side. Copying the temporary firmware level to the permanent side is known as committing or accepting the fix. Conversely, rejecting, or removing the current firmware level consists of copying the permanent firmware image to the temporary side.Note: It is recommended to use a new firmware fix for a period of time before committing (or accepting) it.
If firmware fixes are applied consecutively, the first fix will, by default, be copied from the temporary to the permanent side, or accepted. Using an HMC, it is possible to simply replace the temporary image by doing an Install and Activate of the new firmware and indicating that the firmware should not be accepted.
1.6 Be Advised
During a firmware update, the flashing of the NVRAM might take anywhere from ten minutes to one hour. In general, updating to a new release level will take longer. Ensure the system is not interrupted before the flash process is completed. Interrupting this process could result in a service call.For systems that are not managed by a HMC, the installation of system firmware is always disruptive. During the update_flash process, the console output will be displayed. Again, do not interrupt this process.
Restarting system.
FLASH: preparing saved firmware image for flash
FLASH: flash image is 35191632 bytes
FLASH: performing flash and reboot
FLASH: this will take several minutes. Do not power off!
2.1 Software requirements
The table below is a summary of the minimum components required for each method covered in this paper:Method | Minimum Requirements |
Update via HMC | 1. A compatible version of HMC. 2. An Ethernet connection from the HMC to the p5 server (HMC1 port). 3. Desired firmware image on CD. The rpm and XML files are required. |
Update via running AIX or Linux operating system | 1. A running AIX or supported Linux operating system on a single LPAR environment, ie, no attached HMC. 2. Firmware image on a CD or file system. The rpm file only. 3. update_flash executable. For AIX, it is part of the diagnostic aids tool in the /usr/lpp/diagnostics/bin directory. For Linux, it is part of the Service and Productivity Tools. 4. Serial console and connection |
Update via Standalone Diagnostic CD | 1. Diagnostic CD 2. Firmware image (.img) file on a CD. Remember, the rpm file is not directly compatible. 3. Serial console and connection |