1 out of 1 rated this helpful - Rate this topic

BIOS Settings for Native-Mode-Capable ATA Controllers

Updated: April 14, 2003

On This Page

Gain OS Flexibility by Using Native Mode
Introduction
BIOS and Platform Prerequisites for Switching a Native-Mode-Capable Controller
How Windows Switches an ATA Controller to Native Mode
Designing ATA Controllers for Windows
Call to Action
Related Reading

Gain OS Flexibility by Using Native Mode

The Microsoft Windows XP SP1 and Windows Server 2003 operating systems will switch a native-mode-capable ATA controller from compatible mode to native mode if the BIOS indicates that the controller can be switched, the controller supports native mode and the appropriate registry key is set.

Microsoft is encouraging manufacturers to design their hardware to support switching from compatible mode to native mode because it allows the operating system much more flexibility in assigning resources. This article describes the mechanism used in Windows Server 2003 to switch an ATA controller from compatible to native mode. It also describes how ATA controllers and the BIOS should be designed to support switching controllers to native mode.

Important: Systems that enable the NATA method in the BIOS and registry, but do not have full support will attempt to switch to Native mode and this may cause instability or a system crash.

Top of page

Introduction

Windows XP SP1 and Windows Server 2003 are capable of switching a native-mode-capable ATA controller that defaults to compatible mode to run in native mode.

Native mode allows the operating system much more flexibility in assigning resources. It does not require legacy resources such as fixed interrupts, which is a significant advantage for interrupt-constrained systems such as mobile PCs.

Microsoft is encouraging ATA controller vendors and BIOS manufacturers to design their hardware to support switching from compatible mode to native mode on systems running Windows XP SP1 and Windows Server 2003. Windows XP SP1 and Windows Server 2003 will switch a native-mode-capable ATA controller from compatible mode to native mode if the both the controller and the BIOS indicate that the controller can be switched.

The PCI IDE Controller Specification defines two operating modes in which controllers can operate: Compatible mode and native mode. ATA controllers implement these operating modes according to this specification.

Compatible mode. A controller that operates in compatible mode emulates a legacy IDE controller, which is a non-standard extension of the ISA-based IDE controller. In compatible mode, the controller requires two ISA-style dedicated IRQs (14 and 15) that cannot be shared with other devices. Because compatible mode requires dedicated resources, the ATA controller for the boot device (which is usually integrated in chipsets on the motherboard) is the only controller on a system that is likely to operate in compatible mode.
Native mode. A controller that operates in native mode acts as a true PCI device that does not require dedicated legacy resources and can be configured anywhere in the system. ATA controllers running in native mode use their PCI interrupt for both channels and can share this interrupt with other devices in the system, like any other PCI device. Add-in ATA controllers generally operate in native mode.

Microsoft is encouraging ATA controller vendors and BIOS manufacturers to design their hardware to support switching from compatible mode to native mode on Windows XP SP1 and Windows Server 2003 systems for the following reasons:

Flexibility in locating the ATA controller. Compatible-mode ATA controllers cannot be placed behind PCI-to-PCI bridges because they require legacy resources that cannot be assigned to the bridge. For information, see documents listed at the end of this article.
Increased availability of interrupts. By requiring only one shareable interrupt instead of two non-shareable ones, native-mode controllers significantly decrease the likelihood that a customer will install a device that cannot work because no interrupts are available. Native mode thus provides a significant benefit to users, especially on resource-constrained systems such as mobile PCs.

Previous versions of Windows operating systems were unable to take advantage of native-mode-capable ATA controllers for the following reasons:

Windows Millennium Edition (Windows Me) and Windows 95/98 do not support native mode. The BIOS must find the controller in compatible mode during POST on systems running these versions of Windows.
Windows 2000 and Microsoft Windows NT 4 (as of SP2) support both native mode and compatible mode but cannot dynamically switch a controller from compatible to native mode. If the controller is intended to operate in native mode, the BIOS must find the controller in native mode during POST on systems running these versions of Windows.

These limitations previously meant that a vendor could not support native mode and ship the same BIOS for both Windows 95/98/Me and Windows NT-based systems. The ability of Windows XP SP1 and Windows Server 2003 to dynamically switch from compatible mode to native mode gives system builders the benefits of native mode support without sacrificing compatibility with earlier versions of Windows.

Top of page

BIOS and Platform Prerequisites for Switching a Native-Mode-Capable Controller

Switching a controller to native mode requires the support of the controller, the platform, and the BIOS. In order for Windows XP SP1 and Windows Server 2003 to switch an ATA controller from compatible mode to native mode, the following must be true:

The controller must indicate in its programming interface that both channels can be switched to native mode. Windows XP SP1 and Windows Server 2003 do not support switching only one IDE channel to native mode. See the PCI IDE Controller Specification Revision 1.0 for details.
The BIOS must support ACPI and must provide interrupt routing information for the PCI ATA Controller because it will be using its PCI interrupt in native mode. This is accomplished using the _PRT object as described in ACPI 1.0b.
Windows XP SP1 and Windows Server 2003 will not return the controller to compatible mode after a soft reset occurs, so the POST code in the BIOS must be written to handle finding the controller in native mode. For compatibility with operating systems that do not support native mode (for example, a system that is set up for dual boot of Windows XP SP1 and Windows Me), it is recommended that the BIOS return the controller to compatible mode during POST. It should be noted that IRQ 14 and 15 might have been reused by other PCI or ISA-style devices and thus the POST code might need to reconfigure the interrupt routing accordingly.
The platform must be wired such that IRQ 14 and 15 can be reallocated to PCI or ISA-style devices just like any other IRQs in the machine. If restrictions apply on how these interrupts can be used, then the controller should be left in compatible mode. After the controller is in native mode, it is assumed that these interrupts are available for reuse. For example:
- ACPI device objects that specify IRQ 14/15 in their _PRS methods must work if assigned to IRQ 14/15.
- If the platform supports add-on devices that consume interrupts such as ISA, PNPISA, or PCMCIA cards, the platform vendor must account for the possibility that these cards might ask for IRQ 14 or 15 and get it after the controller has been switched into native mode. If these cards will be unable to interrupt on IRQ 14 or 15 due to the wiring on the motherboard, aspects of the IRQ routing mechanism in the hardware, or some other reason, then the platform should not indicate support for switching to native mode using the ACPI method described in this article.

If all of the above prerequisites are met, the BIOS/platform must indicate its ability to handle switching the controller by providing an ACPI control method named NATA on the parent device of the PCI ATA controller. The control method must evaluate to a list of _ADR style package of integers that indicate which controllers can safely be switched to native mode.

The system must also indicate support in the registry by setting the registry key HKLM/CurrentControlSet/Control/Pnp/Pci/EnableNativeModeATA to any non 0 value. 0 or the absence of the value will disable NATA.

If all of the above prerequisites are not tested, do not implement the NATA on shipping Systems. Poor implementations will cause boot device failures, sleep state transition failures and other problems on Windows XP SP1 and Windows Server 2003.

The following AML code example illustrates the NATA entry that matches the _ADR of the device:

Score(\_SB_) {































    Device(PCI0) {































        ...































        Name(NATA, Package() { 0x001f0001 })        































        ...































        Device(IDE) {































            Name(_ADR, 0x001f0001)































            ...































        }































    }































}

Top of page

How Windows Switches an ATA Controller to Native Mode

In Windows XP SP1 and Windows Server 2003, the PCI bus driver detects ATA controllers during boot. The PCI bus driver sets the controllers configuration registers to enable it for native mode if both of the following statements are true:

The detected controller supports native mode
The BIOS indicates that it can handle switching the controller by implementing the NATA control method described earlier in this article

Placing the device in native mode when it is detected and before the ATAPI component is loaded avoids problems related to dealing with active transactions and edge-triggered versus level-triggered interrupts.

The following steps describe the process of switching an ATA controller from compatible to native mode:

The user powers on the system.
The loader runs through the BIOS and loads the kernel and other necessary operating system components into memory.
The Windows kernel starts.
The PCI bus driver enumerates the system.
For each ATA controller enumerated, the PCI bus driver checks the Programming Interface register of the IDE controller to see if it supports switching both channels to native mode.
The PCI bus driver checks whether the BIOS/platform supports switching the controller by checking the NATA method described earlier in this article.

If an ATA controller does not indicate that it is native-mode-capable, or if the BIOS NATA control method is missing or does not list that device, the PCI bus driver does not switch the controller and it is assigned legacy resources.

If both the controller and the BIOS indicate that the controller can be switched, the process of switching the controller begins with the next step.
The IO/MEM/Busmaster decodes are disabled for the device.
The PCI bus driver sets the operating mode bits of the Programming Interface byte to switch the controller to native mode.
Important: When the controller is set to native mode, it must quiet itself and must not decode I/O resources or generate interrupts until the operating system has enabled the ports in the PCI configuration header. The IO/MEM/BusMaster bits will be disabled before the mode change, but it is not possible to disable interrupts on the device. The device must not generate interrupts (either legacy or native mode) while the decodes are disabled in the command register.

This operation is expected to be instantaneous and the operating system does not stall afterward. It is also expected that the interrupt pin register in the PCI Configuration space for this device is accurate. The operating system re-reads this data after previously ignoring it.
The PCI bus driver reports the native-mode-ATA controller together with the rest of the device on the bus.
Plug and Play loads the PCI IDE driver and arbitrates resources (IO ports and a PCI interrupt) for the device.
Plug and Play starts the PCI IDE controller with these resources.
The PCI bus driver programs the BARs in PCI Configuration space and enables IO/Mem/BusMaster decodes.
PCI IDE enumerates the IDE bus and finds the devices attached and the system continues to boot as normal.

An ATA controller running in native mode acts as a true PCI device. After the controller is switched, interrupts 14 and 15 and other legacy resources required by the controller while it was running in compatible mode are freed. Any interrupt can be assigned to the controller and the controller can share interrupts with other devices on the system.

Top of page

Designing ATA Controllers for Windows

To support native-mode switching on systems that will run Windows XP SP1 or Windows Server 2003, vendors must design native-mode-capable ATA controllers as follows:

Design controllers to be native-mode-capable as defined in the PCI IDE Controller Specification, Revision 1.0, available at http://www.pcisig.com
Set the lower four bits of the Programming Interface byte of the PCI IDE Controller Class Code to indicate that both channels are programmable.
Ensure that the device has valid information in the PCI INTPIN register after the Programming Interface byte is changed.
Do not assume that interrupts 14 and 15 will be dedicated to the controller during runtime, as would be the case with controllers that run only in compatible mode. Review interrupt wiring carefully to ensure that the operating system will be able to share interrupts with other devices.
Do not generate interrupts or decode I/O until the operating system has finished switching modes and enabled ports in PCI configuration space.
Design controllers to honor the decode bits in both native and compatible mode and not decode I/O ports until the I/O decode enable bit is set on the device.

Support for native-mode switching in ATA controllers is currently not a requirement for the Windows Logo Program for hardware. However, vendors should be prepared for this to become a requirement for future versions of Windows.

For ATA controller requirements related to the Windows Logo Program for hardware, see the Microsoft Windows Logo Program System and Device Requirements at
http://msdn.microsoft.com/en-us/windows/hardware/gg463010.aspx

Note: ATA controllers that have been switched to native mode do not resume in native mode after being put into power state D3. When transitioning from D3cold to D0 (fully powered), an internal reset is performed on the controller. If the controller defaults to compatible mode, the PCI bus driver resets the device to native mode.

Only those registers in the common configuration header as described by the PCI Power Management Specification are expected to maintain content after D3cold and S3. These are DeviceID, VendorID, and SubsystemID. For information, see the PCI Power Management Specification at http://www.pcisig.com .

Top of page

Call to Action

BIOS developers should support native-mode switching on systems that will run Windows XP SP1 and Windows Server 2003 as follows:

Implement a NATA control method in the BIOS to indicate to the operating system that the BIOS can handle switching native-mode-capable ATA controllers.
Design the BIOS to handle an IDE controller that was in compatible mode during a previous POST and is in native mode during subsequent POSTs, because the operating system will not return the controller to compatible mode upon system shutdown

Chipset vendors should design ATA controllers to support native-mode switching under Windows XP SP1 and Windows Server 2003 as follows:

Allow switching from compatible mode to native mode.
Set the programmable indicator bits in the Programming Interface byte of the PCI IDE controller class code to indicate that both channels are capable of being switched.
Review wiring design carefully to ensure that the operating system will be able to share interrupts 14 and 15, and do not assume that interrupts 14 and 15 will be dedicated to an ATA controller during runtime.
Do not generate interrupts or decode I/O until the operating system has finished switching modes and enabled ports in PCI configuration space.

Original Equipment manufactures who ship systems with Native Mode IDE support should configure and validate their systems as follows:

Confirm the proper BIOS and chipset support it present in a system.
On pre installs set the registry key HKLM/CurrentControlSet/Control/Pnp/Pci/EnableNativeModeATA to any non 0 value. 0 or the absence of the value will disable NATA

Thoroughly validate the system with a focus on boot and resume scenarios. Poor implementations will cause boot device failures, sleep state transition failures and other problems on Windows XP SP1 and Windows Server 2003.

Top of page