Mobile PC Note: This requirement does not apply for mobile systems.
Note: For SAPIC requirements for Itanium-based system, see A5.4.4.
A1.4.13 System includes headset microphone if system is speech capable
[AUD-0332]
If a system is represented as speech capable or includes speech-recognition software (not including Microsoft Office XP), the system must include a headset microphone that meets the requirements defined in B3.1.4.13.
A1.4.14 Onboard graphics device can be used as a primary VGA boot device
See B4.1.1.8.
A1.5 General System - FAQs A1.5.1 Current general FAQs
See http://www.microsoft.com/winlogo/hardware/.
A1.5.2 APIC/SAPIC Requirement [Clarification]
[SYS-0001.3; SDG3.24, 25]
Implementation and design guidelines are defined in PC 2001 System Design Guide and Hardware Design Guide 3.0.
For background information about APIC, see Key Benefits of the I/O APIC at http://www.microsoft.com/hwdev/newpc/io-apic.htm.
For technical information about how to implement this requirement, see the related chip-set guide from your chip-set vendor.
FAQ date: new revision June 20, 2000
A1.5.3 Riser Cards [Logo Program Clarification]
The BIOS for a system board that supports any type of enumerable riser card, such as AMR, Advanced Communications Riser (ACR), and Communications and Networking Riser (CNR), must include the following support:
-
Detecting and enumerating each function on that type of riser device.
Representing each function on that device so the relevant Windows bus enumerator (such as a PCI bus enumerator) can detect it, and then locate and install appropriate drivers.
This is a Windows Logo Program compliance testing requirement as of July 1, 2000.
FAQ date: December 22, 1999; revised May 9, 2000
The system BIOS must provide a unique PCI SID for any riser card, assigned by the codec manufacturer. This is identical to current Logo Program requirements for audio and modem devices on a PCI add-on card—except these are system-board devices, so the PCI SID must reflect that of the system-board manufacturer.
If an OEM chooses a riser card and driver from any riser card driver manufacturer, the BIOS must populate the fields as follows:
-
The PCI SVID must reflect the Vendor ID assigned by the PCI Special Interest Group (SIG) to that OEM.
-
The SID must be unique for each AC ‘97 device configuration. For example, for a modem-on-motherboard (MoM), modem riser (MR), or audio modem riser (AMR) device, each SID must be unique.
If an OEM chooses a system board from a manufacturer that works with one or more codecs, the following applies:
-
The SVID must reflect the Vendor ID assigned by the PCI SIG to that system-board manufacturer.
-
The SID must be unique for each AC ‘97 codec/device configuration. For example, for a MoM, MR, or AMR device, each SID must be unique.
For an AMR riser, the system BIOS must properly implement the detection algorithm from Intel to verify that the hardware on an AMR/MR riser extension is actually present. The detection algorithm is available at ftp://download.intel.com/ial/scalableplatforms/audio/ac97bios.pdf.
Similar provisions exist in the CNR and ACR specifications.
For information about WHQL testing for riser cards, see http://www.microsoft.com/hwtest/.
See also AC ‘97 and AMR Plug and Play Design (http://www.microsoft.com/hwdev/audio/AMR.htm).
FAQ date: June 2, 1999; revised May 9, 2000
A1.5.4 PCI-to-PCI bridges [Clarification]
[PCI-0123; SDG3:37]
The system BIOS must correctly configure PCI-to-PCI bridges if the system has a VGA device behind a bridge.
Specifically, the BIOS must correctly set the VGA Enable and ISA Enable bits on the bridges, to avoid causing the bridges to be in conflict with each other. See http://www.microsoft.com/hwdev/pci/pcibridge-cardbus.htm.
FAQ date: March 12, 1999
A1.5.5 Multiprocessor Systems Compatibility Testing [Clarification]
As of mid-1999, WHQL accepts multiprocessor submissions for Windows Logo Program and Windows XP/Windows 2000/Windows Whistler Server compatibility testing that contain mixed processor steppings. However, the following requirements for multiprocessor systems must be met:
-
Systems must use the lowest stepping processor as the bootstrap processor.
-
Systems must not contain processors from different processor manufacturers or with mixed speeds or mixed cache sizes.
-
Systems designed to run the Windows 2000/Windows Whistler Datacenter Server operating system must not contain mixed processor steppings.
Note, however, that inherent support for mixed steppings is not currently a design feature supported by Microsoft on either Windows NT-based or Windows 2000-based systems. See http://www.microsoft.com/hwdev/desguid/smp.htm.
FAQ date: August 26, 1999
A1.5.6 Multiprocessor Wakeup [Clarification]
A problem has been uncovered with certain multiprocessor systems that will prevent them from properly waking up from a Sleep state under Windows 2000. This pertains to dual-processor or multiprocessor systems that transition all processors from an active state to a STPCLK state, and more specifically to systems where all processors receive their STPCLK# request from one source. For multiprocessor systems submitted for Windows Logo Program testing for 1999-2000, the vendor must implement a solution for this problem as described in this notice.
The following information has been provided by Intel to help manufacturers correct the problem. For technical questions regarding this issue, please contact Intel. For questions related to support under Microsoft Windows operating systems, please send e-mail to ihv@microsoft.com with Multiprocessor Wakeup in the Subject line.
Prior to transitioning from a STPCLK state to a Sleep state or lower power state, all processors must generate a Stop Grant bus cycle. It is essential that all processors have transitioned to the STPGNT state before it is safe to: 1) transition to a lower power state such as Sleep, or 2) externally shut off the processor clocks to allow for flushing buffers, cache maintenance, and other internal activities.
For dual-processor and multiprocessor systems using a single STPCLK to all processors and a single SLP pin to all processors, the transition to the Sleep state should not be used. Behavior of the system during removal of the processor clock—such as transitions from STPCLK to Sleep state—cannot be guaranteed unless all STPGNT bus cycles are received.
For example, Intel Xeon II Specification, "Section 4.2.5 Sleep State-State 5," specifies that for a multiprocessor system, all processors are required to complete the Stop Grant bus cycle before the subsequent 100 BCLK waiting period and before the assertion of SLP# can occur. When multiple processors are serviced by a single STPCLK# request to all processors and a single SLP#, there is no provision to guarantee that all Stop Grant bus cycles are received before the assertion of SLP#.
As another example, in 450NX-based platforms from Intel, the STPCLK# from PIIX4E is connected to all processors, and SLP# from PIIX4E is connected to all processors. The following sequence occurs:
t0. Operating system writes PMCNTRL register.
t1. PIIX4E asserts STPCLK#, then waits for Stop Grant acknowledgment.
t3. The processor acknowledges with Stop Grant ACK cycle.
t4. PIIX4E asserts SLP# after receiving this.
This sequence works for uniprocessor systems (which is what the PIIX4E was originally designed for). However, in multiprocessor systems, SLP# might be asserted to a processor that is not in Processor Sleep State 3 (that is, not yet acknowledged). This premature SLP# assertion might result in a wakeup problem.
To work around this problem, processors are put to Processor Sleep State 3 (not State 5) during ACPI S1 state. That is, the OEM must remove SLP# assertion to all the processors in 450NX-based platforms.
Intel provides additional information about this issue through the Intel Technical Support Hotline at 1-800-628-8686 (outside North America at 916-377-7000).
Note: Please remove SLP# assertion to all the processors on multiprocessor PIIX4-based platforms. Disabling the Sleep Enable bit in the PIIX4 Processor Control Register does not actually disable the assertion of SLP# as documented in the PIIX4 specification.
FAQ date: March 19, 1999; revisions May 28, 1999
A1.5.7 BIOS support for preboot execution environment, with UUID provided in print [Clarification]
[BIOS-0014.1; SDG3:13.1]
References to PXENV system identifier in Network PC System Design Guidelines, Version 1.0b, are superseded by PXE. [see A1.1.4]
UUID is not required in print.
|
