Compatibility Support Module

From PhoenixWiki

Jump to: navigation, search

The CSM provides additional functionality to UEFI. This additional functionality permits the loading of a traditional OS or the use of a traditional OpROM. This new functionality requires the following:

  • New 32-bit code that operates in the EFI environment (EfiCompatibility)
  • A stripped-down traditional 16-bit real-mode BIOS (Compatibility16)
  • Code to transition between the 32-bit and 16-bit code (thunk and reverse thunk)
  • Optionally code in SMM (CompatibilitySmm) to perform traditional functions not taken over by UEFI SMM.

Outside this additional functionality are the traditional OpROMs, regardless if they reside onboard or offboard.

Several pieces of code make up the CSM, as listed below.

  • EfiCompatibility - 32-bit code that interfaces with EFI EfiCompatibility is comprised of several UEFI drivers. These drivers fall into the following four categories:
    • Drivers that are platform and hardware neutral. They provide the foundation of the CSM and do not change from platform to platform.
    • Drivers that are platform and chipset neutral They control traditional hardware such as the 8259 PIC.
    • Drivers that are chipset dependant. They control chipset hardware that changes from platform to platform. An example is the code to perform PCI IRQ steering.
    • Drivers that are platform specific.
  • Compatibility16 - Stripped-down, traditional IBV, 16-bit real-mode code consisting mainly of the traditional software INT runtime support.
  • CompatibilitySmm - Optional code in SMM to perform traditional functions that are not taken over by the UEFI SMM.
  • Thunk and Reverse Thunk Thunk code is used to switch from EfiCompatibility (32-bit) to Compatibility16 or traditional OpROMs (16-bit). Reverse thunk code is used to switch from Compatibility16 code or traditional OpROMs (16-bit) to EfiCompatibility (32-bit).

Outside the CSM, but still part of a traditional system, are the traditional 16-bit real-mode Option ROMs.

The CSM operates in two distinct environments:

  • Booting a traditional or non-EFI-aware OS.
  • Loading a UEFI-aware OS a device that is controlled by a traditional Option ROM.

The first operation, booting a traditional or non-EFI-aware OS, is the traditional environment. It is expected that traditional OpROMs will be around long after traditional OSs have been replaced by EFI-aware OSs. The code that is required to load a UEFI-aware OS is a subset of the code that is required to boot a traditional (non-EFI-aware) OS. The SecureCore Tiano(TM) architecture reflects this split to allow removing unneeded code in the future.


Copyright (C) 2009 Phoenix Technologies Ltd. All Rights Reserved. Portions copyright (C) 2007 Intel Corporation. Used with permission.

Personal tools