Firmware for 64-bit Windows Systems
Firmware provides boot support to initialize hardware before the operating system is started. In x86-based (32-bit) systems, this capability is provided by the BIOS. Because traditional BIOS-based boot will not work with 64-bit Windows, other firmware boot solutions must be implemented. This topic describes these solutions.
Extensible Firmware Interface
Extensible Firmware Interface (EFI) is a standard for the interface that is provided by the firmware that boots PCs, based on the . Microsoft supports EFI as the only firmware interface for booting 64-bit Windows operating systems.
Because 64-bit Windows will not boot with BIOS or with System Abstraction Layer alone, EFI is a requirement for all Intel Itanium-based systems.
In addition to required protocols in the EFI specification, Microsoft recommends that the firmware support PXE_BC (remote/network boot), SERIAL_IO, and SIMPLE_NETWORK protocols as defined in the EFI specification. Support for these protocols is required by the "Designed for Windows" logo program for 64-bit systems.
Firmware and boot partition acronyms
| Acronym | Definition |
|---|---|
| EBR | extended boot record |
| ESP | EFI system partition |
| GPT | GUID partition table |
| GUID | globally unique identifier |
| HAL | hardware abstraction layer |
| MBR | master boot record |
| SAL | System Abstraction Layer |
The ESP contains the OS Loader, EFI drivers, and other files that are necessary to boot the system. MBR disks can also have an ESP, which is identified by partition type 0xEF. Although EFI specifies booting from either the GPT or MBR, 64-bit Windows does not support booting EFI from MBR disks or 0xEF partitions.
The ESP should only include the following:
- Files that are required for booting an operating system
- Platform tools that run before operating system boot
- Files that must be accessed before operating system boot; for example, to perform pre-boot system maintenance
Other value-add files or diagnostics that are used while the operating system is running should not be placed in the ESP because of its limited space. Value-add files are best stored in an OEM-specific partition. Like MBR OEM partitions, the contents of GPT OEM (or other unrecognized) partitions are not exposed (not given drive letters or returned in volume lists). Users are warned that deleting the partition can cause the system to fail to operate.
An OEM-specific partition should be placed before the MSR and after any ESP on the disk. Although not architectural, this placement has the same benefits as placing the ESP first. For example, it is also impossible to span volumes when an OEM-specific partition is logically placed between two spanned data partitions.
OEM System Abstraction Layer
The SAL is a firmware layer provided by OEMs. The implementation of this layer must conform to RS-IA-64 System Abstraction Layer (SAL) Specification, Revision 2.7 or later, including implementation of a call that allows updates to the firmware.
SAL abstracts the uniqueness of a particular platform by providing a consistent interface to a higher level of the software stack to discover and control an Itanium-based system. SAL exports its components and their associated access details to the operating system through EFI by using the SAL System Table.
Related topics