This section describes additional requirements or exceptions to the requirements defined earlier in Section A1.0.
For desktop systems, all applicable requirements in A2.0 are included by reference.
For server systems, all applicable requirements in A6.0 are included by reference.
A5.1 Itanium-based System - Windows Compatibility
A5.1.1 Windows DDK: “64-Bit Issues”
For 64-bit platforms, each device must have drivers for Windows. The manufacturer does not need to supply a driver if the device functions fully and correctly using a driver provided with the operating system.
If the manufacturer supplies drivers, the device drivers and installation requirements for the Windows Logo Program must be met.
Note: This is a general reference, not a requirement.
Note: This is a general reference, not a requirement.
A5.1.3 64-bit version of Windows Server 2003: Standard Error Record Format passed by the SAL to the operating system
All Error Records passed by the System Abstraction Layer (SAL) to the operating system for all fatal and corrected CPU and Platform Machine Check Architecture (MCA) Events must be, at a minimum, compliant with the Itanium Processor Family System Abstraction Layer Specification (SAL 3.0). The SAL must maintain the Error Records in non-volatile storage across system reboots and power cycles. See Appendix B, “Error Record Structures,” in SAL 3.0 specification, dated January 2001.
Note: This list provides complete titles and web locations for references cited. The listing of a reference here does not imply that complete compliance with that reference is a Windows Logo Program requirement.
A5.2.1 Advanced Configuration and Power Interface Specification, V. 2.0
Microsoft Extensible Firmware Interface FAT32 File System Specification
Microsoft Extensible Firmware Interface Long File Name Specification
Microsoft Portable Executable and Common Object File Format Specification
A5.2.4 Intel Itanium Processor Family System Abstraction Layer Specification (SAL 3.0)
WHQL Test Specification References:
Chapter 2: EFI Test Specification;
Plus technology-specific test specifications
A5.3.1 Pass Windows Logo Program testing for Itanium-based products
Product is submitted to the appropriate WHQL test program and passes all testing for the Windows Logo Program for hardware as described in detail in the WHQL Test Specification and the Microsoft Windows Hardware Compatibility Test Kit documentation.
A5.4 Itanium-based System - Windows Experience
A5.4.1 Comply with ACPI 2.0
For an Itanium-based system in which more than one processor can be installed, the system must employ those processors symmetrically; that is, all processors must be able to access all I/O buses and system memory, and cache coherency must be maintained. The system must also comply with the ACPI 2.0 specification.
To comply with this requirement, implement the ACPI 1.0b backward-compatible portion of ACPI 2.0, plus the 64-bit fixed tables. The fixed tables that must be supported include:
Extended System Description Table (XSDT)
Fixed ACPI Description Table (FADT)
Firmware ACPI Control Structure (FACS)
Multiple APIC Description Table (MADT)
Itanium-based platforms must use the new Extensible Firmware Interface (EFI) GUID for the ACPI 2.0 RSDP Structure (see Section 184.108.40.206 in ACPI 2.0).
The EFI GUID for the ACPI 2.0 RSDP Structure pointer is:
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.
A220.127.116.11 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.
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.
A18.104.22.168 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.
A22.214.171.124 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.
A126.96.36.199 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.
A188.8.131.52 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.
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 184.108.40.206.
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.
Ref A1.1.4 Provide PCI interrupt routing information per ACPI 2.0 Section 6.2.8.
Ref B220.127.116.11 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
A18.104.22.168 System does not include parallel port
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.
A22.214.171.124 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.
A126.96.36.199 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.
A188.8.131.52 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.
A184.108.40.206 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.
A220.127.116.11 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.
A18.104.22.168 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:
A22.214.171.124 Non-ESP partitions do not contain software required for boot
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.
A126.96.36.199 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.