8868E871-E4F1-11d3-BC22-0080C73C8881
A5.4.2 Comply with EFI 1.0, with support for USB boot devices, firmware update, and PXE_BC, SERIAL_IO, and SIMPLE_NETWORK protocols, plus additional guidelines
Itanium-based system must comply with EFI 1.0 or later, with support for USB boot devices, firmware update, and PXE_BC, SERIAL_IO, and SIMPLE_NETWORK protocols.
The only boot mechanism supported for platforms running 64-bit Windows is defined in EFI 1.0 or later. BIOS-based boot is not supported and will not work with 64-bit Windows.
Note: Although the PXE_BC (remote/network boot), SERIAL_IO, and SIMPLE_NETWORK protocols are defined as optional implementation elements in the EFI specification, in this guideline they are requirements for EFI systems.
A5.4.2.1 System supports network-based boot via EFI boot manager
EFI systems must provide support for booting systems from the network as defined in EFI 1.0 or later. This support includes the capability, via the EFI boot manager, to configure boot devices in order of preference by the administrator of the server, plus a method for forcing a network-based boot. These mechanisms must be available to the administrator in the pre-boot state of the system.
A5.4.2.2 System provides boot support for USB keyboard and bus
The system firmware must provide EFI boot support for USB keyboards, pointing devices, and hubs.
The system firmware must also support the keyboard behind at least one level of external hub. This support must provide the ability for the user to enter the system’s firmware-based configuration utilities and provide sufficient functionality to get EFI-aware versions of Windows installed and booted. USB keyboards built as standalone devices, part of a composite device, or part of a compound device must be recognized and usable.
For systems with multiple USB host controllers, firmware support for USB keyboards, pointing devices, and hubs is required for all host controllers that are integrated on the system board (that is, firmware support is not required for add-on cards).
Keyboard and pointing devices must be functional for all modes of the operating system, including booting, loading, recovery console, and operating system installation.
USB external connectors and USB input device support must be enabled by default in the firmware, and the firmware must make USB input devices such as keyboards and pointing devices available at boot time.
A5.4.2.3 System implements SAL, including firmware update method
The System Abstraction Layer (SAL) is a firmware layer provided by OEMs. The implementation of this layer must conform to RS-Itanium-based System Abstraction Layer (SAL) Specification, Revision 2.7 or later, including implementation of a call that will allow the firmware to be updated.
SAL abstracts platform uniqueness by providing a consistent interface to a higher level of the software stack to discover and control an Itanium-based system. It exports components and their associated access details to the operating system through EFI using the SAL System Table.
A5.4.2.5 System firmware provides boot support for CD and DVD drives
The system firmware must support the No Emulation mode in El Torito, Version 1.0, and the additional requirements for EFI as defined in Section 16.2.2, "ISO-9660 and El Torito," in EFI 1.0.
A5.4.2.6 System provides minimum required boot list variable storage
The minimum required non-volatile storage for boot list variables (used by the EFI boot manager) is 4 K. Note that this is storage reserved solely for use by boot list variables and may not be used for any other variables or purposes.
A5.4.2.7 System provides a minimum, firmware-based driver set sufficient to allow boot, installation, and recovery operations without the presence of loadable media-based EFI drivers
The minimum set of capabilities required under this guideline include EFI console capabilities and sufficient other EFI drivers to permit access to devices needed for boot, installation, and recovery operations.
Note: An example of a specific problem that this guideline addresses is the possible case of a system that, in order to reach a given disk drive, must load a driver off that particular disk drive. It can readily be seen that such cases would result in an uninstallable system.
The requirements for management of the EFI boot process are documented in EFI 1.0 or later. In addition, EFI-based systems must meet other EFI requirements in these Logo Program Requirements.
See also: A1.1.4
A5.4.3 Provide serial port to use as debug port, using either 2F8h or 3F8h
Itanium-based system designers must provide a legacy serial port for use as a debug port. The platform firmware must configure at least one serial port to use either 2F8h or 3F8h. This allows the port to be treated as a boot device by the firmware and to be used by components as a diagnostic port if system debugging is required by either the firmware or the operating system.
A5.4.4 Provide SAPIC support
An Itanium-based system must include SAPIC support that complies with the 64-bit extensions to ACPI, Implemented per Multiple APIC Description Table (MADT) in ACPI 2.0, Section 5.2.10.4.
A5.4.5 Provide 64-bit support in PCI subsystem
For Itanium-based systems, all PCI bridges on the motherboard must support DAC for inbound access, and DAC-capable devices must not be connected below non-DAC-capable bridges, for example, on adapter cards.
New 64-bit adapters must be DAC capable.
This DAC requirement does not apply to outbound accesses to PCI devices. However, for systems where DAC is not supported on outbound accesses to PCI devices, the system firmware must not claim that the bus aperture can be placed above the 4-GB boundary.
All 64-bit PCI adapters must be able to address any location in the address space supported by the platform.
The server system must support a 64-bit PCI bus if the server has 64-bit processors or has the capability to support more than 4 GB of physical memory.
In particular, access to PCI configuration space must use mechanisms that do not directly reference PCI configuration space but that instead use the services provided by the SAL or other services which in turn call SAL services.
See also:
-
Ref A1.1.4 Provide PCI interrupt routing information per ACPI 2.0 Section 6.2.8.
-
Ref B2.5.1.7 Adapters address full physical address space on a 64-bit platform; 32-bit PCI adapters used on the primary data path support the PCI DAC command, with the exception of 10/100 Ethernet devices.
A5.4.6 Provide correct device support
64-bit Windows does not provide native legacy parallel port support. Parallel ports must not be present in Itanium-based systems.
Note: 64-bit Windows does not provide native legacy parallel port support.
A5.4.6.2 Primary graphics adapter supports 800x600x256 color and complies with VESA timing standards
At a minimum, the adapter must support 800 × 600 × 256 color, following the VESA monitor timing standards and guidelines for this mode.
A5.4.6.3 Server with no 8042 or other port 60h and port 64h based keyboard controller meets requirements
System designs that remove legacy (port 60h/port 64h) keyboard controllers, typically implemented using 8042 or similar controllers, must meet these requirements to function with Windows. Specifically, these systems must properly set Fixed ACPI Description Table Boot Architecture Flags as described in the ACPI 2.0 specification.
A5.4.7 Provide GPT-partitioned hard drive for boot
64-bit Windows requires bootable hard drives to be partitioned using the GPT mechanism defined in EFI 1.0. This is also the 64-bit Windows default partitioning scheme for all non-removable storage media.
A5.4.7.1 System with GPT-partitioned bootable hard disks provide one ESP of correct size
64-bit Windows requires bootable hard drives to contain a single EFI System Partition (ESP) of size Max(100MB, min (1% of the physical disk size, 1GB)) as defined in EFI 1.0. This formula is to be read, in words, as “the size of the ESP must be the larger of these two numbers, 100MB or 1% of the physical disk size (up to 1GB).” The physical disk size is measured at the time of disk partitioning.
A5.4.7.2 System with ESP contains only components needed for system boot, installation, or recovery
The ESP may only be used for components required for system boot, installation, or recovery. Examples of such components include operating system loaders, EFI drivers, firmware utilities, configuration tools, and diagnostics.
A5.4.7.3 System provides restoration tool for recovery of critical ESP and OEM special partition contents
An EFI system must provide a tool that will permit the user to restore the critical EFI System Partition contents and any OEM special partition contents in the event of a catastrophic failure. This tool does not need to restore any operating system or other non-OEM–supplied ESP contents.
A5.4.7.4 MSR partition of correct size is present on every physical or virtual hard disk manifested to Windows when such disks are otherwise being partitioned by the provider of the system
All entities that represent themselves as a hard disk to an EFI system—whether single drives, or collections of drives behind an intelligent controller that represents the assembly as a whole as a single “disk”—must contain an Microsoft Reserved (MSR) partition of correct size.
This guideline applies only to disks shipped with systems being partitioned by the provider of the system, such as disks that contain system utilities or are otherwise preinstalled with software for use by or with Windows. It is not required for disks that are “blank”—in other words, those disks that have no partitions present on them when installed by the manufacturer and that will be configured by the user.
The formula for calculation of the size of an MSR is as follows:
if (disksize < 16 GB) {MSR = 32 MB;} else {MSR = 128 MB;}
The GUID for such partitions is defined as follows:
DEFINE_GUID(PARTITION_MSFT_RESERVED_GUID, 0xE3C9E316L, 0x0B5C, 0x4DB8, 0x81, 0x7D, 0xF9, 0x2D, 0xF0, 0x02, 0x15, 0xAE);
No software required for system boot can be stored in an OEM-specific, non-ESP partition. Instead, such software must reside in an ESP or in system firmware.
A5.4.7.6 ESP resides only on a device that can be reached through firmware-resident EFI drivers
To prevent problems that can occur if a driver needs to reach a disk containing an ESP that is actually contained on that disk (resulting in a non-bootable system), ESPs must be placed only on devices that can be reached using firmware-resident EFI drivers.
A5.4.8 - A5.4.10 DELETED A5.4.11 System includes 1 GB memory, minimum
See WL-2
A5.4.12 DELETED
|
