Browse Prior Art Database

Method for Selecting Firmware Architecture Level

IP.com Disclosure Number: IPCOM000119014D
Original Publication Date: 1997-Oct-01
Included in the Prior Art Database: 2005-Apr-01
Document File: 2 page(s) / 75K

Publishing Venue

IBM

Related People

Arndt, RL: AUTHOR

Abstract

Disclosed is a method for adjusting the architecture level of system firmware to match the operating system.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Method for Selecting Firmware Architecture Level

      Disclosed is a method for adjusting the architecture level of
system firmware to match the operating system.

      System software and platform firmware must operate using a
compatible architectural level of interface definition.  As the
architectural level of the firmware interface evolves, extensions
must be initially transparent or disabled to allow for backward
compatibility with the system software.  However, often the firmware
must make an assumption as to architectural level before the system
software can activate an extension.  Open Firmware (1) introduced
the notion of configuration variables to tell the firmware how to
handle such decisions.  However, setting the value of a configuration
variable requires a manual operation by the user which is burdensome
and subject to error.  This disclosure automates the setting of such
variables allowing for both forward and backward compatibility
between the system software and platform firmware.

      The current CHRP (2) platform's Open Firmware maintains a
"boot list" of devices among which it selects the source for loading
its initial system software ("client code").  This list has a
platform dependent default setting as it is comes from the factory
and to which  it returns should the list become corrupted.  This
invention adds, to each element in the boot list, a "level parameter"
whose default value reflects the base platform architecture (that is
no extension enabled).  The disclosure further specifies the uses and
manipulations of the level parameter as described below.

      When the firmware selects a boot list element to specify where
to get the client code, the boot element's level parameter also
selects the firmware's "current architectural level".  This allows a
different architectural level to match the various possible client
code loads (standard operating system, diagnostic package,
installation media, backup device, etc.).

      Once loaded and executing, the client code interfaces with the
platform firmware using the base level of architected interface.
With...