Browse Prior Art Database

System to efficiently resume interrupted firmware updates Disclosure Number: IPCOM000179953D
Original Publication Date: 2009-Mar-03
Included in the Prior Art Database: 2009-Mar-03
Document File: 3 page(s) / 77K

Publishing Venue



When a firmware update fails, the data that was already written during the failed code update is re-written during a subsequent recovery code update. This disclosure presents a mechanism to preserve data that was successfully transferred during an interrupted code update to be maintained across a consecutive code update. The idea introduces a novel way to reduce the amount of data transfer on the subsequent firmware update. The advantages of this idea are: * Reduce the amount of data transfer between HMC and FSP during updates reducing the chance of data corruption * Improved code update efficiency * Faster code updates * Ability to move between HMCs and still be able to continue interrupted code updates

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 53% of the total text.

Page 1 of 3

System to efficiently resume interrupted firmware updates

During a firmware code update operation, if the update is interrupted, the system may be left in a possible erroneous state. The firmware update may be interrupted for a variety of reasons such as a network disconnect between the service processor (FSP) and the hardware management console (HMC), an unexpected reboot of the FSP or the HMC, power loss etc. In each case, the connection between the HMC and the FSP is lost. The HMC has mechanisms in place to log surveillance errors for expected and unexpected disconnects that may occur. Unexpected disconnects occur when the FSP network connection to the HMC is disconnected at the wrong time during a code update, and if this happens, there is a time-out period before which the HMC will declare the code update has failed. The code update operation has policies in place to indicate the start and end of the update and to maintain locks that will prevent platform state transitions during a firmware update. However, if the correct end of update acknowledgement is not received from the HMC, the FSP will also time-out resulting in a failed firmware code update.

In most cases the update operation can be restarted once the connection between the HMC and FSP is restored. However, during the initial code update a significant amount of data may have been transferred between the HMC and FSP, and re-starting the code update would re-start the data transfer process from the beginning.

This disclosure presents a mechanism to efficiently transfer data on a firmware update re-try when the initial firmware update was interrupted. By preserving the initially transferred data, a recovery firmware update would require less data transfer making the update more efficient and faster.

The invention can be implemented as follows:


When a code update is started, the FSP creates a code update log file. The code update log file has the same name for any update. The log file will comprise of 2 parts.The initial part of the code update log file will contain the build name in two formats:

Format 1: bmmdda

_xxxx.yyy , where mm is the month, dd is the day, xxxx is the build number, and yyy is the release


Format 2: ssssttt

_nnn , where ssss is the system/bpc identifier, ttt is the release, mmm and nnn are the build


This will ensure that the build is correctly matched and compared when a new update is performed.

The third part of the log file will contain a list of the li...