Intel Extensible Firmware Interface - Manual (Page 59)

Overview
Version 1.10 12/01/02 2-19
2.5.1.4 Ties to PC-AT System Design
Legacy option ROMs assume a PC-AT-like system architecture. Many of them include code that
directly touches hardware registers. This can make them incompatible on legacy-free and headless
platforms. Legacy option ROMs may also contain setup programs that assume a PC-AT-like
system architecture to interact with a keyboard or video display. This makes the setup application
incompatible on legacy-free and headless platforms.
EFI Driver Model design considerations:
• Drivers should use well-defined protocols to interact with system hardware, system input
devices, and system output devices.
2.5.1.5 Ambiguities in Specification and Workarounds Born of Experience
Many legacy option ROMs and BIOS code contain workarounds because of incompatibilities
between legacy option ROMs and system BIOS. These incompatibilities exist in part because there
are no clear specifications on how to write a legacy option ROM or write a system BIOS.
Also, interrupt chaining and boot device selection is very complex in legacy option ROMs. It is not
always clear which device will be the boot device for the OS.
EFI Driver Model design considerations:
• EFI Drivers and EFI firmware is written to follow the EFI Specification. Since both
components have a clearly defined specification, compliance tests can be developed to prove
that drivers and system firmware are compliant. This should eliminate the need to build
workarounds into either drivers or system firmware (other than those that might be required to
address specific hardware issues).
• Give OEMs more control through Platform Driver Override Protocol and Driver Configuration
Protocol and other OEM value-add components to manage the boot device selection process.