This section summarizes requirements related to other buses.
42 Any subsystems implementing I2O meet standards and Hardware Design Guide requirements
If I2O is implemented in a system, it must meet the requirements defined in this guide and in the I2O Architecture Specification, Version 1.5 or higher, available from the I2O Special Interest Group (SIG) at http://www.i2osig.org.
If I2O is implemented on a system, the system BIOS must support any I2O devices in the system in the following cases:
An I2O-capable system that includes no I2O-intelligent devices, whether provided on the system board or as add-on devices. The system can have an installed adapter that is I2O-ready or I2O-compliant, and the BIOS must initialize the device as a multifunction device. The system cannot boot from this I2O device, because the BIOS does not support initialization of I2O bootable device.
An I2O-ready system that has some sort of intelligence on the system board or on an add-on adapter that enables the sending and receiving of messages as defined in the I2O specification. This intelligence can be an off-the-shelf processor or an application-specific integrated circuit (ASIC) when it is on the system board, or it can be included as an add-on adapter. In this case, the system BIOS must support initializing and configuring the device, including
support for multifunction PCI. Initialization and configuration of a PCI device does not imply that the system BIOS supports compliant I2O initialization of boot devices or that the system can boot from an I2O device.
An I2O-compliant system that includes support for initializing and booting from I2O devices, whether provided on the system board or as add-on devices. The system as a whole must be able to pass I2O compliance testing with Windows NT 5.0.
43 System does not include ISA expansion devices
This requirement does not preclude the inclusion of ISA expansion slots in a server system. An ISA expansion device in this context is defined as being an expansion adapter or device installed in an ISA slot. Also, ISA (embedded or expansion) is not allowed for network adapters, storage controllers, or graphics adapters on any system type.
No ISA expansion devices are allowed, with specific exemptions for the following classes of ISA expansion devices:
Out-of-band systems management devices
Internal modem cards
The intent of these exemptions is to provide a transition period for these specific technologies as they migrate to deterministic bus designs; it is anticipated that these exemptions will not be present in future versions of these guidelines.
The benefits of an ISA-free system include improved performance, easier and more stable system configuration, and lower support costs.
It is recommended that system designers consider not providing the ISA bus in server systems and that all hardware vendors plan for migration away from ISA in their 1998 product lines.
44 System includes APIC support
This requirement does not apply for RISC-based servers. The server must include APIC support and the support must be in compliance with ACPI 1.0, implemented by reporting the interrupt mechanism using the INT_MODEL field of the Fixed ACPI Description Table (Section 5.2.5) and including the Multiple APIC Description Table (Section 5.2.8). Features such as targeted interrupts, broadcast interrupts, and prior-owner interrupts must be supported. Intel Architecture processor implementations can use the Intel APIC component.
Implementation of APIC support on server systems provides a greater number of IRQ resources, even within traditional server architectures.
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.
45 Device driver and installation meet Hardware Design Guide requirements
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 must 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.
All configuration settings must be 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.
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, and all other copyright and version information must be correct for the manufacturer.
Driver installation and removal must use Windows-based methods as defined in the Windows NT DDK.
The device driver must be able to be removed using Windows-based software, which can be managed 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 Win32 SDK. Also, any software components and registry entries installed during driver installation must be removed during driver installation.
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.
It must be possible for the device’s driver to be installed using a mechanism such as a script or special software for supplying required parameters without the user being present.
A Windows Help file must be provided if special driver parameters are used. This requirement is to ensure 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, and the Help file must contain relevant information to assist the user. The guidelines for implementing Help are defined in the Windows NT DDK.
For any device for which WDM-based support is provided in the operating system, the manufacturer-supplied driver must be a WDM minidriver.
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.
46 Keyboard and mouse connections meet requirements for bus and device classes
These requirements depend on the type of connection designed into the system. These requirements 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 to ensure the proper functioning of software written for legacy systems, which expect 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 Personal System/2 specification, published by IBM.
Use an 8042 chip (or equivalent) 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 USB Specification, Version 1.0 or higher
Meet requirements in USB Human Interface Device Class Specifications, Version 1.0 or higher
Implement minidriver support based on WDM HID class support in the operating system
If a USB keyboard is the sole keyboard implementation in an Intel Architecture system, it must support the USB Boot Device specification. The system BIOS must provide boot support as specified in the “Startup Support Requirements” section of Chapter 2, “Basic System Component Requirements,” and as defined in Universal Serial Bus PC Legacy Compatibility Specification, Version 0.9 or higher. On a RISC-based system, the keyboard must work as the input device using the ARC interfaces.
47 Serial port meets requirements for bus and device classes
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 higher (also known as the USB core specification)
Universal Serial Bus Device Class Definition for Communication Devices, Version 1.0 or higher
The “Standard Serial Interface Circuit Emulation” appendix in the USB Device 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, 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 IRQs can be assigned as follows:
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 and is intended to be usable by components as a diagnostic port in the event that system debugging is required by either the BIOS or the operating system.
48 Parallel port meets requirements for bus and device classes
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:
Required: Support ISA I/O addresses of 378h, 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.
Required: 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.
Required: Support two unique DMA channel selections if the parallel port 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 RISC-based 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.
It is recommended that the port also support the ECP protocol as defined by IEEE 1284 to allow connections with higher-speed parallel peripherals. However, if the port can support the compatibility and nibble mode protocols as described earlier, it will be compliant with the Basic server 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.
The parallel port design must provide enough space between the connectors and the surrounding enclosure to allow for a mating connector, connector shell, and latch assembly. The IEEE 1284 specification recommends an IEEE 1284‑C connector for all new ports and devices.
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.
Required key
|
Abbreviated string
|
|
MANUFACTURER
|
MFG
|
MODEL
|
MDL
|
CLASS
|
CLS
|
DESCRIPTION
|
DES
|
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 (that is, 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 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.
49 System includes emergency repair support
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, it is recommended that support for floppy disk drives be provided using a solution based on an external bus to support migration away from legacy devices. If implemented as an IDE floppy drive, the drive must be compliant with SFF 8070i.
50 Primary graphics adapter meets minimum requirements
At a minimum, the adapter must support 800 × 600 × 256 color.
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.
Chapter 4
Basic Networking and Communications Requirements
This chapter defines basic feature requirements for network adapters and other communications hardware. See also the related requirements for remote new system setup and service boot support using Dynamic Host Configuration Protocol (DHCP) and Trivial File Transfer Protocol (TFTP) as defined in the “Manageability Requirements” section of Chapter 7, “Reliability, Availability, and Serviceability Requirements.”
In this guide, all network communications devices are based on the same Network Driver Interface Specification (NDIS) 5.0 requirements, which includes requirements for power management and Plug and Play capabilities.
Tips for selecting high-performance network adapters. For manufacturers who want to select high-performance components, the following are design features to look for in network adapters:
Adapter uses bus mastering.
PCI adapter properly supports higher-level PCI commands for intelligent data transfer.
Drivers tuned for 32‑bit performance; that is, 32‑bit alignments on the adapter do not interface with 16‑bit alignments on odd addresses.
NDIS 5.0 represents a number of extensions to the interface described in NDIS 3.0 and 4.0. The basic requirements, services, terminology, and architecture of these earlier versions also apply to NDIS 5.0. The new NDIS architecture is included in Windows 98 and in Windows NT 5.0, and is documented in the Windows NT 5.0 DDK.
NDIS 5.0 consists of all functionality defined in NDIS 4.0, plus the following extensions:
NDIS power management, required for network power management and network wake up
Plug and Play, which previously was supported only under Windows 95 and later versions, but is now also applicable to Windows NT 5.0 network drivers
Windows hardware instrumentation support for structured, cross-platform management of NDIS miniports and their associated adapters
Simplified network INF format across Windows operating systems, based on the Windows 95 INF format
De-serialized miniport for improved performance on Windows NT multiprocessor systems
Task-offload mechanisms for tasks such as Transmission Control Protocol/ Internet Protocol (TCP/IP) checksum, Point-to-Point Protocol (PPP) compression/encryption, and Fast Packet Forwarding
Broadcast media extension, required for broadcast components
Connection-oriented NDIS, required for native access to connection-oriented media such as Asynchronous Transfer Mode (ATM) and asymmetric digital subscriber line (ADSL), and WDM support for streaming over connection-oriented media
Support for Quality of Service (QOS) when supported by the media
Intermediate driver support, which is required for broadcast components, virtual local area networks (LANs), LAN emulation over new media (ATM, satellite or broadcast television, and so on), packet scheduling for QOS, and NDIS support over WDM-supported buses such as IEEE 1394
Previously, NDIS primarily supported network adapter driver development and deployment of connectionless network media such as Ethernet, Token Ring, ArcNet, and Fiber Distributed Data Interface (FDDI). NDIS 5.0 extends this interface to provide efficient support for connection-oriented media such as ATM and ISDN, plus support for QOS and isochronous data transfer for media that supports QOS. The new architecture also enables support for streaming of multimedia data such as audio and video over the NDIS media.
Note: NDIS 5.0 features are accessible only by using the NDIS miniport driver model and are not supported for full MAC drivers. Information about the miniport driver model is included in the Windows NT 5.0 DDK.
|
