|
|
| Search Microsoft.com for: |
EFI and Windows VistaUpdated: April 20, 2006 On This Page
The Three Components of SoftwareThis paper briefly describes Microsoft plans for supporting the Extended Firmware Interface (EFI) in Microsoft Windows operating systems and provides a brief background for related technical issues. The software that runs on a personal computer can be classified into three vertically integrated components: firmware, operating system (OS), and application software. Firmware Firmware is stored in PROM or EEPROM or flash memory and is the first piece of code that runs when the processor completes a reset. It is designed to perform basic initialization of a particular hardware platform. Firmware provides a set of basic services that enable the operating system to load itself and begin executing. Examples of firmware are a basic input-output system (BIOS) and the Extended Firmware Interface (EFI). Windows expects the BIOS to comply with the Advanced Configuration and Power Interface (ACPI), which provides information describing the composition of particular platform and allows the operating system to execute fragments of BIOS code at runtime in a protected sandbox known as an ACPI interpreter. Operating System After the firmware finishes basic initialization, which might include hardware diagnostic tests, it hands control to the OS loader. The OS loader uses services that the firmware provides to access hardware resources such as disk drives, CD-ROM drives, memory, and so on. After the OS loader has loaded the basic operating system components, it no longer needs all the services that the firmware provides because the operating system has its own services and functions for accessing the hardware, including high-performance drivers based on the Windows Driver Model (WDM). When Windows must interact with firmware components at runtime, it normally tries to do so in a sandboxed environment to improve system reliability. Examples of Microsoft operating systems are Microsoft Windows XP, Microsoft Windows Server 2003, and Microsoft Windows Vista. Software The operating system provides a platform on which application software runs. The application can exist on the hard drive, CD ROM, or other storage resources that the operating system can access. Examples of application software include Microsoft Word and Adobe Photoshop. BIOS as PC FirmwareEach PC usually comes preloaded with firmware and, until recently, that was usually in the form of BIOS, which was first designed in the late 1970s. BIOS firmware has been through numerous changes to accommodate the modern-day needs of complex platforms. BIOS design was not governed by any standards other than commonly followed conventions, and BIOS vendors have worked to address the special needs of specific hardware vendors. Firmware usually resides on a limited-size EEPROM or flash memory (~1 MB). The size limitation is due to the costs of parts and maintenance. BIOS interfaces are used to start the Windows load process. BIOS is not used at OS runtime, with the exception that video BIOS support might be emulated. EFI as PC FirmwareEFI is the next-generation firmware model, set to replace the legacy BIOS in the coming decade. EFI serves as the interface between hardware platform and the operating system, providing information about the platform that is necessary for the operating system to boot. Although EFI is primarily used to boot the system, there is also some limited run-time support. For example, EFI provides run-time functions for manipulating EFI variables (used mainly for boot management), system time management, system reset, and so on. EFI was initially developed by Intel Corporation and published in the EFI 1.0 specification. EFI has been used as the only supported firmware on Intel Itanium-based systems. Microsoft Windows Server 2003 was one of the first operating systems to support this interface on Itanium systems. In 2005, Intel and Microsoft were among the founding members of the Unified EFI Forum. Other founding members of the forum include AMD, American Megatrends, Dell, Hewlett Packard, IBM, Insyde, and Phoenix Technologies. Using the EFI 1.10 specification as the starting point, the forum began to develop, manage, and promote the Unified Extended Firmware Interface (UEFI) specification with the goal to bring UEFI to mainstream systems that have traditionally used a BIOS to boot. On January 31, 2006, the UEFI 2.0 specification from UEFI Forum was released. The UEFI committee decided that UEFI firmware and the operating system must match bit-wise; that is, the maximum number of address bits used by the operating system must match the maximum number of address bits used by firmware. For example, 32-bit UEFI implementations have the ability to boot 32-bit operating systems, but not 64-bit operating systems. Likewise, a 64-bit UEFI firmware implementation has the ability to natively boot a 64-bit operating system, but does not support natively booting a 32-bit operating system. This restriction was reached for technical reasons related to runtime UEFI support, The UEFI specification also allows firmware vendors to add flexible support for booting operating systems that are designed to boot on traditional BIOS. For this, the UEFI vendor will integrate a firmware interface layer that performs the compatibility functionality while presenting the BIOS-type interface to an operating system that expects BIOS-type interfaces to boot. Thus, any UEFI implementation can be written to provide boot support for native 32-bit, native 64-bit, and legacy BIOS-based operating systems. However, supporting all three of these options requires a very large firmware image which would not fit on a traditional PROM, adding to the cost of the bill of materials (BOM). This also adds to the validation costs for a platform, which in turn adds to the non-recoverable engineering (NRE) cost for the system manufacturer. However, it is practical to support both a native UEFI firmware implementation along with the BIOS firmware interface layer. Microsoft expects that most UEFI platforms in the near future will choose native 64 bit support along with a BIOS compatibility module so that these platforms can run earlier versions of Windows that support boot only through a BIOS. Nearly all new processors in the Windows Vista timeframe will be 64-bit capable. Microsoft would like to use the advent of mainstream 64-bit computing as a transition point to enable a move toward EFI boot. Although a platform vendor could choose to have UEFI 32-bit support, this has a short life and diminishing returns. In the near future, OEMs won't need large, multipurpose firmware images. Evaluating BIOS vs. UEFI SupportUEFI is a technically superior solution to use for boot compared to BIOS. UEFI is well-specified and is a testable interface that will improve system compatibility and reliability. Architecturally, UEFI allows the transition away from real-mode 16-bit code that is common in BIOS. Its agility will improve time to market for platforms and will allow new scenarios to be developed in future release of Windows. However, because BIOS boot is ingrained into all existing x86 and x64 deployments, Microsoft will continue to support BIOS-based boot for the foreseeable future. If UEFI becomes a well-established standard for booting systems, then Microsoft might consider a gradual transition away from BIOS-based boot support. It is likely that this transition would initially take the form of implementing only some features on UEFI systems. EFI, UEFI Support, and Windows VistaWindows 2003 Server supports EFI 1.10 on Intel Itanium platforms. Microsoft Windows Server 2008 supports EFI 1.10 on Intel Itanium platforms, and also introduces support for native UEFI boot on x64 64-bit platforms. Although the initial release of Windows Vista will not include UEFI x64 64-bit support, a subsequent Windows Vista release will support UEFI. Given the advent of mainstream 64-bit computing and the platform costs previously discussed, Microsoft determined that vendors would not have any interest in producing native UEFI 32-bit firmware. Microsoft has therefore chosen to not ship support for 32-bit UEFI implementations. For Microsoft, support for UEFI means rigorous testing on a heterogeneous mix of UEFI implementations on a wide range of hardware platforms. As of mid-2006, no firmware vendor has yet provided production-ready UEFI implementations. The inability to perform wide testing on multiple implementations creates a risk-adequate testing must be done before operating system support can be released. This risk has driven the decision to enable UEFI support with Windows Server 2008. By that time, it is expected that sufficient production-quality UEFI implementations will be available so Microsoft will be able to work with hardware vendors to test a wide range of platforms. Microsoft is working closely with the Unified EFI Forum and industry partners to ensure that it can provide a high-quality, standards-based UEFI solutions. Microsoft has demonstrated Windows support for native UEFI boot at industry events such as Windows Hardware Engineering Conference (WinHEC). As part of this continuing effort, Microsoft is also making "technology preview" code for UEFI boot support available in the Windows Vista Beta 2 release. This technology preview allows partners to test their UEFI implementations to make production-ready samples available for Microsoft for testing support in Windows. The technology preview code will be removed for Windows Vista release candidates (RC) and final release to manufacturing. However, support for well-tested UEFI will be made available in a future update to Windows Vista. The supporting code will be present for Windows Server 2008 Beta 3 and Windows Server 2008 release to manufacturing. To help smooth the transition from BIOS boot to UEFI boot, differences between UEFI and BIOS environments are abstracted from the end user wherever possible. Once the OS is fully functional, it shields the user from underlying firmware differences. For example, a new boot configuration data (BCD) store was designed for Windows to help abstract these differences and to enable easier deployment of BIOS and UEFI systems. Following are specifics of EFI versus BIOS boot:
References
|
