Browse Prior Art Database

Method for a common image format and PEIM/Driver composition that supports driver functionality within two separate system environments

IP.com Disclosure Number: IPCOM000008217D
Publication Date: 2002-May-28
Document File: 5 page(s) / 149K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a method for a common image format and PEIM/Driver composition that supports driver functionality within two separate system environments. Benefits include improved performance and resource utilization.

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

Method for a common image format and PEIM/Driver composition that supports driver functionality within two separate system environments

Disclosed is a method for a common image format and PEIM/Driver composition that supports driver functionality within two separate system environments. Benefits include improved performance and resource utilization.

Background

              Conventionally, extensible firmware interface (EFI) has two distinct phases of execution, the preliminary equipment index (PEI) and data exchange (DXE). The binary components that abstract the behavior and service in the PEI phase are referred to as the PEI modules (PEIMs). The components in the DXE phase are called DXE Drivers. Each subscribes to a standard image format and has a defined, architectural mechanism for describing the load semantics, service requirements, and how to publish services. The modules are typically stored in the platform’s flash memory. It is a persistent, memory-mapped technology that is many times smaller than a fixed disk and costs many times more per byte than a disk. In the cost-conscious PC industry, the minimization of the flash needed by the BIOS is a primary variable for controlling the cost of the overall platform.

              In EFI, separate PEIMs and DXE drivers that provide the same functionality, such as metronome, the SMBUS access service, the status code service, and the root I/O abstraction. This duplication can be mediated somewhat if it is a single code-base by the judicious use of libraries, but the library approach has the downside of duplicating the code in two places (wasting flash space) and only working if there is a single source-base. The conventional solution does not solve the issue of component interoperability in the horizontal industry.

Description

              The disclosed method includes a mechanism for a single image format that serves as the container for a single code image that supports services in both the PEI and DXE phases of execution. The combination driver acts as a PEIM in the early PEI phase and as a DXE driver in the later driver load sequence.

              The PEI phase is characterized by a lack of permanent memory. This phase leverages some transitory memory store, such as a cache-as-SRAM capability of a CPU or CPU-only resources to load and dispatch binary modules from third parties. This resource-poor environment is characterized by a call-stack that might be only 4 KB in size to accomplish the primary goal of enabling the main memory complex.  This task requires the interoperation of several modules, including the following:

·        Memory-controller ASIC support

·        OEM-specific SMBUS-to-DIMM routing

·        Third-party SMBUS controllers

·        Platform-policy for effecting the memory initialization and error handling

              The DXE phase has a 128 KB stack and richer sets of intrinsics. If any functionality is required in both the PEI and DXE phases, the conventional implementation practice has been to duplicate the services in the PEIM and the DXE Driver. The DXE phase...