Browse Prior Art Database

Apparatus and method for updating component firmware upgrade in appliance Disclosure Number: IPCOM000234721D
Publication Date: 2014-Jan-31
Document File: 5 page(s) / 34K

Publishing Venue

The Prior Art Database


Disclosed is a rule-based component firmware upgrade mechanism for an appliance that contains multiple hardware components.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 24% of the total text.

Page 01 of 5

Apparatus and method for updating component firmware upgrade in appliance

An appliance that contains many hardware (HW) components can be designed to support a multitude of complicated jobs. These hardware components can be controlled via the component firmware provided by vendors. Occasionally, vendors provide newer versions of component firmware by means of a fixpack or improvement of some functionality. Because these hardware components are in the appliance, the appliance is expected to manage the hardware component firmware update when the appliance is performing an appliance firmware upgrade itself. In other words, hardware component firmware is invisible but it is seamlessly upgraded or downgraded as part of the appliance firmware upgrade/downgrade.

The appliance depends on hardware components to perform its function; therefore, the version of component firmware must be precisely controlled by the appliance. However, with many different hardware components, each could have a unique nature of upgrade/downgrade. Hardware components can use a one-way upgrade, multi-hop, or have a dependency between multiple hardware components. The combination of those natures makes the upgrade/downgrade process difficult.

The difficulty of handling a hardware component firmware upgrade/downgrade in the appliance upgrade/downgrade process is that each hardware component has a unique upgrade rule and the appliance needs to consider all rules. These rules could expand as time progresses. In addition, the appliance firmware upgrade/downgrade itself can be a factor. The appliance system environment might be different after an appliance firmware upgrade. It is possible that a hardware component firmware utility cannot be executed in the environment after appliance firmware upgrade. Another variation is the

appliance platform. The hardware component might be different on a different hardware platform, but the appliance firmware used is the same for those multiple platforms.

The current solution for this complex issue is hardcoding the rule in the implementation,

which locks the extensibility and requires more effort when there are new rules for upgrading new hardware component version. Moving to a rule-based system as described below addresses that.

The novel contribution is a rule-based component firmware upgrade mechanism. A set

of rules is used to perform a firmware upgrade for a specific hardware component, including how to upgrade the associated firmware, the dependent components, multi-hop steps and update policies. Hardware components can be defined as either a critical or a non-critical component in a rule file. A critical component's firmware level needs to be upgraded to the level as defined in the rule file, or the whole upgrade can fail. This ensures that an appliance can properly boot after a firmware upgrade. Rules also contain special conditions for a firmware version, such as to upgrade in one direction (i.e. one-way) or to reboot af...