News Column

"Updating Firmware Compatibility Data" in Patent Application Approval Process

August 7, 2014



By a News Reporter-Staff News Editor at Computer Weekly News -- A patent application by the inventors Asselin, Albert A. (Morrisville, NC); Piazza, William J. (Holly Springs, NC); Roberts, David B. (Cary, NC), filed on January 17, 2013, was made available online on July 24, 2014, according to news reporting originating from Washington, D.C., by VerticalNews correspondents.

This patent application is assigned to International Business Machines Corporation.

The following quote was obtained by the news editors from the background information supplied by the inventors: "The present invention relates in general to firmware for systems and electronic devices and, in particular, to firmware upgrades. More particularly, the present invention relates to a method for identifying if a candidate firmware is compatible with an existing, or installed, firmware installation.

"Firmware is software codes which reside in a piece of hardware and are responsible for an integral portion of the hardware function and are generally treated as being a component of the hardware. Typically, firmware is stored as binary information in some form of nonvolatile memory component, in which binary can be represented in hexadecimal, octal and other number bases. The components of firmware may be executable programs, such as power-on self test (POST), Basic Input/Output Software (BIOS), configuration utilities, etc., or it may be data tables, e.g., a description of the geometry of a hardfile, register values to use with a universal asynchronous receiver-transmitter (UART) to produce different baud rates, etc. Firmware is typically stored in a special type of memory chip that doesn't lose its storage capabilities when power is removed or lost. This non-volatile memory is classified as 'read-only' memory (ROM) because the user, during normal operation, cannot change the information stored there. Generally, ROMs are programmed at the 'factory', i.e., by the ROM manufacturer utilizing information provided by a customer. A basic type of memory device utilized to store firmware is called a programmable read only memory (PROM), which is programmable by any technician utilizing, e.g., a programming console. A basic PROM receives one version of firmware and the firmware code is 'burned in' to the PROM and cannot be changed. To update the firmware, the PROM must be physically removed from the device and replaced with a new PROM that contains the upgraded firmware. Improvements in memory device technologies have rendered variations of the PROM, such as erasable programmable read only memory (EPROM) and electrically erasable programmable read only memory (EEPROM) devices, that can be erased utilizing electrical signals without the need to remove them from a circuit.

"Many products experience a number of firmware revisions that correct firmware defects, compensate for hardware or operating system errors or introduce new features. As long as the hardware architecture of the subsystem does not change substantially and each new firmware revision is capable of recognizing and dealing with differences in hardware revisions levels, things are relatively simple for the flash utility that replaces the present installed firmware image with a upgrade firmware image. The flash utility may assume that the progression of build IDs, such as QYKT24AUS, QYKT25AUS, etc., is valid and that older revisions may be applied over newer revisions, i.e., the level of the flash may regress, albeit with the possible loss of function and re-introduction of firmware defects.

"However, certain events in the life-cycle of a product family break these simple assumptions. These events may include:

"(1) Major changes in the architecture of a product, e.g., as a result of cost reduction changes, such that older versions of firmware do not recognize newer hardware features and therefore treat them improperly.

"(2) The divergence of a product family into 2 or more related families, possibly under the control of two different engineering teams located, e.g., in distant cities, where the firmware may look similar but has actually been customized for a specific set of hardware.

"(3) The convergence of two product families (from a firmware perspective). Convergence can be used as a cost reduction tool where two similar pieces of firmware exist and can be combined into a single firmware image that works on both hardware platforms but requires only a single development group to maintain and test it.

"(4) A characteristic of a product, e.g., the layout of configuration information in CMOS memory, changes in such a way that older levels of firmware would misinterpret it.

"Generally, systems and subsystems with updateable firmware typically require some sort of verification to determine applicability of a candidate image to an existing installation. Conventional methods quite often amount to nothing more than verifying some or all of the following: (i) a company's copyright notice exists in the candidate image; (ii) a part number in a recognizable form and position exists in the candidate image; (iii) a 'type code' exists in the candidate image in a recognizable form and position and the type code indicates that the old and new images are compatible (type codes identify compatible types of hardware and may be applied to the overall product or to subsystems within the product); (iv) a revision level exists in the candidate image and that the user is attempting to apply a newer image over an older image; and (v) the candidate image has not been corrupted, e.g., verified by using a checksum or CRC. Items (i), (ii), and (iv) above do little (if anything) to aid in verifying compatibility between firmware images. They allow software utilities to verify that the firmware images came from a single vendor and that the user is not attempting to regress to an older firmware image. Even then, there are times when it may be desirable to regress so that a warning with a mechanism to override the protection is usually provided.

"Type codes have sometimes been used to indicate compatibility between firmware images, but such practices have limitations. Conventional techniques either do not utilize such type codes, in which case it is possible to inadvertently apply the wrong type of firmware image to a product, or assume that only firmware images within the same type code are compatible. Additionally, conventional techniques will often require that an exact match exist between a single type code in the candidate image and a single type code in the installed image. Furthermore, these techniques may also commonly assume that any new firmware images that present the same type code as an installed firmware image is compatible and may be utilized to update the installed image. These 'simple' schemes often cause problems in the real world where complicated scenarios may arise."

In addition to the background information obtained for this patent application, VerticalNews journalists also obtained the inventors' summary information for this patent application: "One embodiment of the present invention provides a method of determining the compatibility of a firmware version. The method includes downloading a candidate version of a firmware image for a particular product, updating incomplete firmware compatibility metadata by downloading additional firmware compatibility metadata for the particular product, and using the updated firmware compatibility metadata to determining whether the candidate version of the firmware image is compatibility with a current version of a firmware image that is installed within the particular product.

"Another embodiment of the invention provides a computer program product including computer usable program code embodied on a tangible computer usable storage medium. The computer program product includes computer usable program code for downloading a candidate version of a firmware image for a particular product, computer usable program code for updating incomplete firmware compatibility metadata by downloading additional firmware compatibility metadata for the particular product, and computer usable program code for using the updated firmware compatibility metadata to determining whether the candidate version of the firmware image is compatibility with a current version of a firmware image that is installed within the particular product.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

"FIG. 1 is a simplified high-level block diagram of an exemplary data processing system that provides a suitable environment for the practice of the present invention.

"FIG. 2 is a diagram of a flash utility application program in communication with the system firmware.

"FIG. 3 is a diagram of firmware compatibility metadata in the form of a matrix.

"FIG. 4 is a flowchart of a method in accordance with one embodiment of the invention."

URL and more information on this patent application, see: Asselin, Albert A.; Piazza, William J.; Roberts, David B. Updating Firmware Compatibility Data. Filed January 17, 2013 and posted July 24, 2014. Patent URL: http://appft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=%2Fnetahtml%2FPTO%2Fsearch-adv.html&r=152&p=4&f=G&l=50&d=PG01&S1=20140717.PD.&OS=PD/20140717&RS=PD/20140717

Keywords for this news article include: Software, International Business Machines Corporation.

Our reports deliver fact-based news of research and discoveries from around the world. Copyright 2014, NewsRx LLC


For more stories covering the world of technology, please see HispanicBusiness' Tech Channel



Source: Computer Weekly News


Story Tools






HispanicBusiness.com Facebook Linkedin Twitter RSS Feed Email Alerts & Newsletters