Table of Contents
Advertisement
Operating system
EFI operating system loader
EFI boot & runtime services
System abstraction layer (SAL)
Processor abstraction layer (PAL)
Platform hardware
Figure 1-16 The EFI concept
The primary goal of this specification is to provide an abstract model for both
operating system and hardware developers. With such a model in a place, OS
loader customizations are not required if there are changes in the platform
hardware or firmware such as added new boot or input devices, for instance. The
EFI breaks up a tight dependency between the operating system and the
firmware, thus speeding up the process of releasing the new products and
introducing the new features and functionality to the hardware and/or operating
system.
Consider, for example, the situation where a new type of boot device, say a USB
key, is to be implemented. First the legacy BIOS would have to offer an option to
choose this new device for booting, then new USB key-specific functions would
have to be added to the firmware to support booting from a USB device, and
finally, the OS loader would have to be modified to use these functions.
The same situation with the EFI would be dramatically simplified. The OS loader
calls unified (not vendor-specific) EFI API functions for booting. These functions
are not dependent on the boot device used, so when a new boot device type is
IBM Eserver xSeries 455 Planning and Installation Guide
30
Advertisement
Table of Contents
