Specifications

22
2.5.2.6 Block I/O Emulation
This driver is used when EFI needs to access a traditional floppy or hard disk. It
translates EFI block I/O requests into the equivalent INT13 requests.
2.6 Assumptions
External Assumptions
The CSM code makes the following external assumptions:
• When unloaded, EFI device drivers that have EFI OpROMs leave the
hardware in a neutral state that allows an equivalent traditional OpROM to
be invoked without any adverse device interaction.
• Traditional OpROMs cannot be unloaded and thus leave the hardware in a
non-neutral state.
• The UGA hardware is bi-modal, which also supports a VGA emulation mode.
• The UGA OpROM also carries a traditional VGA OpROM.
• Only traditional ACPI-aware OSs are supported.
• Traditional device programming is done either by EFI, EfiCompatibility, or
ACPI.
• MS-DOS* boots but there is no guarantee that all DOS programs will work.
• The Legacy BIOS Platform Protocol code, Compatibility16 code, and
CompatibilitySmm code (if it exists) are all provided by the same IBV. Using
a single IBV ensures consistency and coherency.
Internal Assumptions
The CSM code makes the following internal assumptions:
• The Compatibility16 bit code consists of a traditional runtime BIOS, INT18,
and INT19. Compatibility16 does not include 16-bit OpROMs.
• The POST code is removed. The EFI code functions as the traditional BIOS
POST equivalent. This assumption presents the minimal space footprint.
2.6.2.1 Compatability16 bit code
The following assumptions pertain to the Compatibility16 bit code except where
indicated.
• Runtime text messages are kept to a minimum and are simple ASCII or
numerical data. It is considered too expensive, space wise, to carry a display
engine for a couple of messages. There is also the coherency of localization
between EFI and Compatibility16.
• There is no need for cache control. It is assumed that cache is always
enabled or controlled by the OS.
• There are no flash or NVRAM updates, or all updates are done via
CompatibilitySmm that is cognizant of EFI firmware volumes and EFI update
protocols. There are several reasons for this assumption. Compatibility16
code knows nothing of EFI firmware volumes. Having multiple independent
entities trying to maintain flash or NVRAM is guaranteed to introduce system
instability.