Device Requirements

This section summarizes requirements for the system devices and peripherals provided with server systems.

Note: It is recognized that administrators might not want a keyboard, mouse, or monitor attached to working servers. However, these devices are typically required at least for installation of the operating system.

Device driver and installation meet Hardware Design Guide requirements

Required

Each device must have drivers for the Windows NT operating system. The manufacturer does not need to supply a driver if the device passes compliance testing using a driver provided with the operating system.

If the manufacturer supplies drivers, the device drivers and installation requirements include the following:

• All devices and drivers pass compliance testing for these guidelines. Each device included in a server system must comply with the requirements defined in this section and must have supporting 32-bit device drivers for the CPU platform and operating system. The installation and loading of a driver must not reduce or eliminate functionality of other devices installed on the system. The following are also required:
  • Every driver (or minidriver) must support Plug and Play and power management I/O request packets (IRPs).
    
    
  • Real-mode or 16-bit protected-mode components must not be provided to operate under Windows NT. Only 32-bit protected-mode components are installed on systems with 32-bit processors.
    
    
  • Any device with WDM-based operating system support must have a manufacturer-supplied WDM minidriver.
    
    
  • All devices in systems with 64-bit processors must have 64-bit Windows NT-compatible drivers.
• All configuration settings are stored in the registry. The driver must not use INI files for configuration settings. The driver must also include correct provider, version, and copyright entries. This information is displayed in the user interface.
  
  
• Files have correct identifiers and are stored in the correct locations. The correct minidriver or any other manufacturer-supplied files specified in the device’s INF must be installed in the correct location.

For manufacturer-provided files, the vendor must not be identified as Microsoft; all other copyright and version information must be correct for the manufacturer.

Driver files provided by the vendor must not use the same file names used by files included in Microsoft operating systems and provided as either retail or OEM products, unless specifically agreed upon with Microsoft.

• Driver installation and removal use methods defined in the Windows NT DDK. The device driver must be removable using Windows-based software by using either the Windows Control Panel option for removing devices or its own remove utility. For information, see the Windows NT 5.0 DDK.

However, any software applications included with the device can be installed using an alternate Windows-based installation method as defined in the Microsoft Platform SDK. Also, any software components and registry entries installed during driver installation must be removed during driver removal.

• Driver supports unattended installation. It must be possible for a user to install a device’s driver without being present. This unattended installation can be done using a mechanism such as a script or special software for supplying the required parameters.
  
  
• Windows Help file is provided if special driver parameters are used. This requirement ensures that the user can correctly change settings. The device’s installation routine must install the Help file as part of the setup program. The user interface for the device’s dialog boxes must display the correct Help file; the Help file must contain relevant information to assist the user. The guidelines for implementing Help are defined in the Windows NT DDK.

Keyboard and mouse connections meet requirements for bus and device classes

Required

These requirements, which depend on the type of connection designed into the system, ensure that all Plug and Play requirements are met and that Microsoft drivers support this device.

If a PS/2-style keyboard port is used, the following requirements must be met:

• Support PIC-based IRQ 1 on Intel Architecture systems, ensuring that software functions properly if it was written for legacy systems and expects to use this IRQ signal.
  
  
• Map the I/O address ports to 60h and 64h.
  
  
• Return expected scan codes, including send ID (0F2h) and response ACK (0FAh), plus 2-byte ID.

If a PS/2-style mouse port is used, the following requirements must be met:

• Comply in full with requirements in the IBM Personal System/2 specifications.
  
  
• Use a device with an 8042-compatible interface to the keyboard controller function to ensure compatibility with Windows NT. In most cases, the existing 8042 keyboard port is sufficient. The 8042 chip initiates a PIC-based IRQ 12 interrupt when the mouse is connected to the port.
  
  
• Support PIC-based IRQ 12 to ensure the proper functioning of software written for legacy systems that use this IRQ signal.
  
  
• Return expected codes, including send ID (0F2h) and response ACK (0FAh) + 1-byte ID.

If a USB connection is used, the following requirements must be met:

• Meet requirements in Universal Serial Bus Specification, Version 1.0 or later.
  
  
• Meet requirements in USB Human Interface Device Class Specifications, Version 1.0 or later.
  
  
• Implement minidriver support based on WDM HID class support in the operating system, as defined in the Windows NT 5.0 DDK.

If a USB keyboard is the sole keyboard implementation in an Intel Architecture system, it must provide boot support as specified in “Startup Support Requirements” of Chapter 2, “System Component Requirements,” and as defined in Universal Serial Bus PC Legacy Compatibility Specification, Version 0.9 or later. This support must provide the ability for the user to enter the system's BIOS setup program and provide enough functionality to get a USB-aware operating system installed and booted. On a DEC Alpha system, the keyboard must work as the input device using the ARC interfaces.

Serial port meets requirements for bus and device classes

Required

A serial port implementation that uses a non-legacy bus must meet the specific device class requirements for that bus. For example, a USB serial port implementation must comply with all related USB specifications, including:

• Universal Serial Bus Specification, Version 1.0 or later.
  
  
• Universal Serial Bus Class Definition for Communication Devices, Version 1.0 or later.

The “Standard Serial Interface Circuit Emulation” appendix in the USB Class Definition for Communication Devices specifically addresses serial-port compatibility.

If a legacy serial port is implemented in a server system, it must meet the following requirements:

• A 16550A buffered Universal Asynchronous Receiver/Transmitter (UART) or equivalent buffered legacy serial port is required to support high-speed communications while reducing the CPU requirements for servicing the device. The device must be able to support 115.2K baud.
  
  
• A legacy serial port must provide flexible resource configuration and complete dynamic disable capabilities as defined in the Plug and Play External COM Device Specification, Version 1.0. The following are the recommended resource settings for non-PCI devices:
  • Four I/O locations for each port (standard ISA I/O addresses are 3F8h, 2F8h, 3E8h, and 2E8h). Using the standard addresses ensures the proper functioning of software that directly addresses these locations.
    
    
  • Two IRQ signals (standard is PIC-based IRQ 3, IRQ 4). Support of the standard IRQ signals ensures the proper functioning of software written for systems that use standard IRQ signals.

Two IRQs are required for each port. If two serial ports are implemented in the system, the following IRQ assignments are recommended:

• For serial port A: selection between PIC-based IRQ 4 and IRQ 11.
  
  
• For serial port B: selection between PIC-based IRQ 3 and IRQ 10.
  
  
• In the event of an irreconcilable conflict with other serial ports on the system, a legacy serial port must be capable of being disabled by Plug and Play software. This capability allows at least one of the two conflicting serial ports to operate correctly.
  
  
• The BIOS must configure at least one serial port to use either 2F8h or 3F8h. This requirement allows the port to be treated as a boot device by the BIOS so that components can use the port for diagnostic purposes in the event that system debugging is required by either the BIOS or the operating system.

Parallel port meets requirements for bus and device classes

Required for all server types, with ECP support required for SOHO servers

In addition to other capabilities listed here, the parallel port on a SOHO system must support the ECP protocol as defined by the IEEE 1284-1994 specification. This capability allows connections with higher-speed parallel peripherals.

A parallel port implementation that uses USB must comply with all related USB specifications, including the USB core specification and any specific device class specification.

If implemented in a server system, a legacy parallel port must provide flexible resource configuration following the Plug and Play Parallel Port Device Specification, Version 1.0b. Resource requirements must be met for each device of this type on the system. The requirements cannot be split between two ports on the system.

For non-PCI devices, the minimum resource requirements for each parallel port on the system are as follows:

• The parallel port must support ISA I/O addresses of 378h and 278h, plus 3BC or a vendor-assigned I/O address. Using these standard I/O addresses ensures proper functioning of software written for operating systems that directly address these locations.

Recommended: Map the base I/O address to four additional locations.

• The parallel port must support PIC-based IRQ 5 and IRQ 7. Using these standard IRQs ensures proper functioning of software written for operating systems that use standard IRQ signals.

Recommended: Support five additional IRQ signals.

• The parallel port must support two unique DMA channel selections if its design supports block data transfers to memory using DMA controllers. Notice also that the DMA function will not work on a parallel port without an IRQ because the end of a DMA transfer is signaled by an interrupt.

To ensure Plug and Play support for resolution of resource conflicts, a full list of options for all possible configuration combinations must be enumerated, including:

• Options for both extended capabilities port (ECP) mode, which requires an I/O address, an IRQ, and a DMA selection, and standard LPT mode, which requires only an I/O address.
  
  
• Options that specify only the I/O address, which allows Windows NT to assign the IRQ and DMA channel.

On Intel Architecture systems, Windows NT considers the parallel port base address stored in the first BIOS Data Area (BDA) locations to be LPT1. The address stored in the second location is LPT2, and so on. On DEC Alpha systems, the information is in the ARC tree. On all ACPI-based systems, the information is obtained through the ACPI tree.

A legacy parallel port implemented in a server system must also meet the following requirements:

• Enhanced parallel port (EPP) support does not use restricted I/O addresses. Some EPP implementations require eight contiguous I/O ports. If EPP support is implemented, the hardware cannot use the ISA I/O address 3BCh as a base I/O address because VGA devices require use of port 3C0h.
  
  
• Compatibility, nibble mode, and ECP protocols meet IEEE 1284-1994 specifications. Support for a parallel port must include the compatibility mode and nibble mode protocols required by the IEEE 1284-1994 specification for minimum compliance. This support allows other IEEE 1284-compliant devices to be connected without problems.

Recommended: Port supports the ECP protocol as defined by IEEE 1284, allowing connections with higher-speed parallel peripherals. However, if the port can support the compatibility and nibble mode protocols as described earlier, it complies with the Basic and Enterprise class guidelines that allow connection of other IEEE 1284-compliant devices.

• Port connectors meet the minimum requirements defined in the IEEE 1284-I specifications. IEEE 1284-I–compliant ports must use a standard DB25 connector found on existing system parallel port designs. This connector is called an IEEE 1284-A connector in the specification.

IEEE 1284-II–compliant ports must use an IEEE 1284-C connector. This connector is used on both the port and the peripheral device.

• IEEE 1284 peripherals have Plug and Play device IDs. The device ID is described fully in the IEEE 1284 specification. All characters in the device identification string must consist only of ASCII values 20h–7Fh. The device identification string consists of a leading zero, a hexadecimal value that represents the length of the string, and then a set of fields, in ASCII, with a unique identification string.

In addition to the requirements specified in the Plug and Play Parallel Port Device Specification, Version 1.0b, the device ID string must contain the following keys, at a minimum. The keys are case sensitive and can be abbreviated in INF files as indicated.

All MANUFACTURER and MODEL key values must remain unique for each manufacturer. All MANUFACTURER, MODEL, CLASS, and DESCRIPTION key values must remain static for a specific unit; ID values do not change for different hardware configurations. For example, a user adding a memory module to a printer should not change the MODEL key value reported as part of the device identifier. However, if the user adds memory by installing an upgrade kit that requires a different driver or requires the existing driver to behave differently, then changing the MODEL value is acceptable as part of the upgrade installation process.

The CLASS key describes the type of parallel device. The CLASS key can contain the values PRINTER, MODEM, NET, HDC, PCMCIA, MEDIA, FDC, PORTS, SCANNER, or DIGCAM. HDC refers to hard disk controller. MEDIA refers to any multimedia device. FDC refers to floppy disk controller.

The DESCRIPTION key is an ASCII string of up to 128 characters that contains a description of the device that the manufacturer wants to have presented if a device driver is not found for the peripheral.

For information about how the system determines the correct peripheral device driver, see the Windows NT DDK.

Recommended: The CID key can provide a value that exactly matches a peripheral name supported by a device driver shipped with Windows NT Server. The value must match a value listed in the device’s INF file.

System includes emergency repair support

Required

Floppy disk support is recommended for emergency-repair disk purposes; if an OEM does not provide a floppy disk drive for this purpose, an alternate emergency repair method must be provided.

If a floppy disk drive is provided, the recommended support should be a solution based on an external bus, supporting migration away from legacy devices. If implemented as an IDE floppy drive, the drive must comply with ANSI NCITS T10 Multi-Media Command Set-2 (MMC-2).

Primary graphics adapter meets minimum requirements

Required

At a minimum, the adapter must support 800 × 600 × 256 color, following the VESA specification for this mode.

The adapter must also work normally with the default VGA mode driver, which is required for installing the operating system, so the primary adapter must support 4-bit planar VGA mode.