Startup Support Requirements - A reference for Designing Servers and Peripherals for the Microsoft® Windows nt®...

Startup Support Requirements
This section defines the BIOS and other requirements to support system startup.
11 System BIOS meets boot support requirements
This requirement does not apply for RISC-based servers. Notice that the Extended System Configuration Data (ESCD) calling interface is not supported by Windows NT 5.0.
The requirements for boot support include the following:
Support for unique system ID structure. The unique system ID structure is described in “Attachment B: Preboot Execution Environment” of Network PC System Design Guidelines, Version 1.0b or higher.
Support for preboot execution environment. If a server provides support for network adapters that provide remote boot capabilities using DHCP and TFTP, the server must also provide support for preboot execution environment as described in “Attachment B: Preboot Execution Environment” of Network PC System Design Guidelines, Version 1.0b or higher.
Implementation of security such as a preboot password. This is provided to protect enable and disable capabilities for hardware components before the operating system boots. At a minimum, User and Administrator levels of password protection must be provided in the BIOS.
This capability prevents end users from accidentally or purposefully circumventing operating system-level security and control as applied by an administrator.
BIOS boot support for CD‑ROM. If a server includes a CD‑ROM, the system BIOS or option ROM must support the No Emulation mode in El Torito—Bootable CD‑ROM Format Specification, Version 1.0, by IBM and Phoenix Technologies Ltd., or an equivalent method that supports the Windows NT CD‑ROM installation process.
BIOS boot support for network adapter. If a server provides support for BIOS boot from a network adapter, the system BIOS must comply with the requirements defined in Sections 3 and 4 (as they apply to Plug and Play devices) of the Compaq, Phoenix, Intel BIOS Boot Specification, Version 1.01 or higher, which describes the requirements for Initial Program Load (IPL) devices.
BIOS boot support for USB keyboard. For a server that includes a USB keyboard as the only keyboard in the system, the system BIOS must provide boot support as defined in Universal Serial Bus PC Legacy Compatibility Specification, Version 0.9 or higher.
Implementation of BIOS updates. System administrators must be able to upgrade BIOS ROMs to a new image through OEM-provided programs using either (1) the remote new system setup mechanism that will be downloaded and executed at boot time or (2) normal file access and execution methods when the system is fully booted into the normal operating system environment.
Recommended: If option ROMs are provided, they should also be capable of being updated.
Recommended: Implement a mechanism to authenticate the requester of the update programming. Implement a mechanism to validate that the program arrived intact after download.
A working group is developing a mechanism to implement this requirement for non‑volatile storage update capabilities. For information, see http://www.teleport.com/~nsispec/.
System BIOS support for console redirection of a serial port. This capability provides support during system startup for debugging and troubleshooting activities. The BIOS 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 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.
Plug and Play Requirements
This section defines the specific requirements for Plug and Play.
12 System and device configuration meet Plug and Play requirements
Optional: Support for legacy Plug and Play technology.
Windows NT Server 5.0 implements complete support for Plug and Play configuration. Each bus and device provided in a server system must meet the current Plug and Play specifications related to its class, including requirements defined in Section 6 of the ACPI 1.0 specification and the clarifications published for some Plug and Play specifications. This includes requirements for automatic device configuration, resource allocation, and dynamic disable capabilities.
For information about new Plug and Play support under Windows NT 5.0, see the Windows NT 5.0 DDK.
The following are current version numbers for all Plug and Play specifications:
PCI Local Bus Specification, Revision 2.1
Plug and Play External COM Device Specification, Version 1.0
Plug and Play Industry Standard Architecture (ISA) Specification, Version 1.0a, plus Clarification to Plug and Play ISA Specification, Version 1.0a
Plug and Play Parallel Port Device Specification, Version 1.0b
Plug and Play Small Computer System Interface Specification, Version 1.0
Universal Serial Bus Specification, Version 1.0
Note: Standard system devices are excluded from the Plug and Play requirement. The system can reserve static resources for devices such as programmable interrupt controllers (PICs) 1 and 2, timer (8254‑2), keyboard controller (8042), real-time clock, DMA page registers, and DMA controllers 1 and 2. For systems based on Intel Architecture processors, these fixed resources are located at I/O addresses under 100h and can also include a Non-Maskable Interrupt (NMI). Also, this requirement does not apply to devices that are completely invisible to the operating system, such as out-of-band systems management devices or I2O hidden devices; however, these devices still must properly reserve resources using ACPI methods to avoid potential conflicts.
13 Unique Plug and Play device ID provided for each system device and add‑on device
Each device connected to an expansion bus must be able to supply its own unique identifier, as defined in the current Plug and Play specification for the bus that it uses. The following defines the specific requirements for Plug and Play device IDs:
Each separate function or device on the system board must be separately enumerated, so each must provide a device identifier in the manner required for the bus it uses.
If a device on an expansion card is enumerated by the BIOS, it must have a unique ID and its own resources according to the device-ID requirements for the bus to which the card is connected. This includes devices that are separately enumerated on multifunction cards or multifunction chips.
The following are exceptions to this requirement:
Legacy devices attached to the ISA bus on the system board do not have unique Plug and Play IDs—for example, serial ports, parallel ports, or PS/2-compatible port devices. The method for device identification is defined in Plug and Play ISA Specification, Version 1.0a and the ACPI 1.0 specification.
Some multifunction devices (such as Super I/O) might include devices that do not have unique Plug and Play IDs or unique PCI Subsystem IDs, but that are supported by drivers provided with the Windows NT operating system.
A device such as a multifunction PCI device that supports a number of functions but uses only a single set of relocatable resources does not have to provide separate identifiers for each function included on the device.
Some devices are completely invisible to or are not managed by the operating system, such as out-of-band systems management devices or I2O system and I2O hidden devices. Such devices are exempt from this requirement, but these devices still must properly reserve resources using ACPI methods to avoid potential conflicts.
In addition, if an OEM uses a proprietary mechanism to assign asset or serial numbers to hardware, this information must be available to the operating system using Windows hardware instrumentation technology.
14 Option ROMs meet Plug and Play requirements
This feature does not apply for RISC-based servers. These recommendations apply whether the device is present on the system board or is provided through an expansion card. Related option ROM recommendations are also defined later in this guide for specific bus classes and specific devices, such as SCSI and graphics adapters, respectively.
Option ROMs are usually located on cards used as system boot devices. During the boot process, option ROMs initialize the boot devices, which provide the primary input, primary output, and IPL device to boot the system. However, Plug and Play option ROMs can be used to supply the Plug and Play expansion header to devices other than boot devices, enabling them to initialize both devices when the system boots.
To design an option ROM with Plug and Play capabilities, follow the requirements described in the Plug and Play BIOS Specification, Version 1.0a, and Clarification to Plug and Play BIOS Specification, Version 1.0a, which describe the Plug and Play expansion header and the interaction between the system BIOS and the option ROM.
15 “PNP” vendor code is used only to define a legacy device’s CompatibleID
All legacy devices not enumerated by the system board interface must not use “PNP” in their vendor and device codes. The PNP vendor code is reserved for Microsoft and vendors whose hardware is specifically assigned a particular ID. Other hardware can use a PNP code only when defining a device’s CompatibleID (CID) and only after first indicating the device’s HardwareID in the Plug and Play header.
Use of CIDs is strongly recommended for devices that use device drivers provided with the Windows NT operating system, such as a standard COM port (PNP0500).
Chapter 3
Basic Bus and Device Requirements
This chapter defines specific requirements for buses and devices provided in a Basic server system.
Tips for selecting I/O performance components. For manufacturers who want to select high-performance components for server systems, the following are design features to look for in I/O components:
The system has minimal or no reliance on ISA.
Adapter supports bus mastering.
PCI adapter properly supports higher-level PCI commands for efficient data transfer.
Drivers are tuned for 32‑bit performance; that is, 32‑bit alignments on the adapter do not interface with 16‑bit alignments on odd addresses.
All devices and controllers must be capable of being identified and configured by software through the defined bus mechanisms.
|