Abstract This paper provides information about developing a Serial ata miniport driver for the Microsoft® Windows® family of operating systems

Developing a Serial ATA Miniport Driver

This paper provides information about developing a Serial ATA Miniport driver for the Microsoft® Windows® family of operating systems. It provides guidelines for driver developers to design a Serial ATA Miniport driver in the SCSI Miniport driver model that may be easily ported to the Mini ATA model. The Mini ATA driver model will be released into a future Windows operating system.

Windows Hardware Engineering Conference

WinHEC Sponsors’ Disclaimer: The contents of this document have not been authored or confirmed by Microsoft or the WinHEC conference co-sponsors (hereinafter “WinHEC Sponsors”). Accordingly, the information contained in this document does not necessarily represent the views of the WinHEC Sponsors and the WinHEC Sponsors cannot make any representation concerning its accuracy. THE WinHEC SPONSORS MAKE NO WARRANTIES, EXPRESS OR IMPLIED, WITH RESPECT TO THIS INFORMATION.

Microsoft, Windows, and Windows NT are trademarks or registered trademarks of Microsoft Corporation in the United States and/or other countries. Other product and company names mentioned herein may be the trademarks of their respective owners.

Introduction

The target audience for this paper is Driver Developers and SW engineers who are familiar with the Windows storage driver architecture. Familiarity with the SCSI miniport driver architecture is also helpful.

Serial ATA Overview / Advantages

The primary difference of interest to a driver developer, however, is the fact that the technology is now a dedicated point-to-point interface between the drive itself and the Serial ATA controller physical port¹. Thus, what disappears in the driver developed in this design is the concept of a Master and a Slave sharing a single bus². The usage of a Task file interface also becomes unique. Unlike parallel ATA, where the host software is actually writing to Task File registers on the physical drive itself across the ATA bus, Serial ATA cannot do this. Thus, it has adopted the concept of “shadow registers” for the host software to write to/read from. The host, therefore, still thinks that it is writing to a device, but instead is now writing to registers within the Serial ATA controller itself. The transmission of data and status across the SATA bus then occurs in the background, from the host software’s perspective, and the controller updates the software registers on the controller to allow the host software to manage the data transfer. The Parallel ATA register interface is heavily reused in Serial ATA. Status, Command, etc. have identical purposes from the driver developer’s perspective.

Development Environment Overview

Figure 1 Development Environment

Besides supporting normal data transfers to and from the drives (Data DMA), the driver also has been validated using Drive Hot Plug³ and Tagged Command Queuing⁴.

In order to support the advanced features of Serial ATA, the IDE Port driver cannot be used. This is the motivation for a designer to develop a custom driver. The advanced features are also best supported in the SCSI miniport driver model. Thus, the driver described herein was developed as a SCSI miniport driver.

There are several considerations that developers may want to keep in mind as they choose to develop their own Serial ATA driver as described herein. These include the following:

• 
  A designer will likely want to minimize the transition from Windows 2000 and later as much as possible. Thus, a desire to make as much of the driver code as possible abstracted from the dependencies of the current OS should be a goal.
  
• 
  The design should be portable to other processors. For example, using the same software on an XScale processor running Windows CE for an embedded storage solution could be advantageous.
  
• 
  The driver needs to have the ability to support the latest Serial ATA enhancements (TCQ, Hot Plug, etc.).
  
• 
  The driver needs to be designed in a way that minimizes the transition to the ATA miniport driver model.
  
• 
  It is always desirable for a developer to increase the Reliability, Reuse, and Maintainability of the driver.
  
• 
  This driver is NOT intended to support IDE legacy mode! A Serial ATA controller can support the IDE legacy model with the standard IDE driver that comes with a Windows installation CD.
  
• 
  
  
• 
  
  

Driver Architecture

Overview

In addition, the implementation of PIO mode within the driver was limited to usage in commands such as Identify_Device. The focus was to DMA blocks of data to and from the devices. This was successfully accomplished by supporting the commands shown in Table 1.

Table 1 also shows the corresponding ATA commands for which the driver had to translate the SCSI commands into prior to sending them to the drives. Note when looking at this table, that certain SRB requests do not have to particularly lead to the immediate initiation of the corresponding SATA command to the drive. For example, a designer may choose to store the device information acquired from an Identify_Device done during initialization. Then, when the SCSI Port driver sends down requests for service, such as SCSIOP_INQUIRY or SCSIOP_READ_CAPACITY, the Serial ATA Miniport driver may be able to build a response to that request from a saved Identify_Device data structure. Note also that Mode Sense may be built based upon additional error data that is available through extended error registers in Serial ATA.

Table 1 SCSI SRB to Serial ATA Translation Table

A unique approach was chosen to develop this driver in order to better meet all of the goals presented earlier in the Development Environment Overview section. This approach made use of an internal “library” object as shown in Figure 2.

The architecture of the driver is developed in a manner to promote maximum reuse of the software. To this end, the architecture is divided into four high-level component objects as shown in Figure 2. A brief description of the components is as follows:

• 
  OS Specific Driver Module (OSDM) – This module must be developed for every operating system that is intended to be supported. It understands the interfaces required for the OS in which it is supporting, and is very OS specific due to this. This will contain all of the primary miniport driver entry points as defined by the Microsoft Windows DDK, for example, StartIo. It will also provide any translation required to get the OS specific requests into the lower level driver components. The primary translation is the SRB / SCSI CDB to ATA format translation.
  
• 
  SATA General Logic / SATA Controller Logic – These two components comprise the Library, and are intended to provide a standard API to the OS Specific Driver Module (OSDM). They can be designed to be OS independent. The additional intent is to decouple the hardware-specific elements (SATA Controller Logic) from the SATA generic components (SATA General Logic) within the library through an internal API. This will support a model where a different controller could be added with the minimal development effort.
  
• 
  Generic / SATA Logic – This block implements all the algorithms and routines that are independent of the controller, the OS, and the Architecture. It will provide functional objects like the “target device”, “request queues”, etc. This is the location where newer SATA features (like Port Multiplier, enclosure management, etc) may be implemented.
  
• 
  SATA Controller Logic – This block represents all the controller-specific code. It contains only that part of the code/logic that is dependent on the controller chip, such as specific register formats and memory locations.
  
• 
  OS Service Layer – The intent of this layer is to provide an OS independent service call interface into the SATA General Logic / SATA Controller Logic layers and translate these OS-type calls into the OS calls as required by the target OS. Thus, this is also an OS-dependent layer that will have to be unique for each OS being targeted. Examples of translations that may be in this layer are as follows:
  

MicrosecondSleep  ScsiPortStallExecution  AtaPortStallExecution

PciMemWriteDataPort  ScsiPortWriteRegisterBufferUchar  AtaPortWriteRegisterBufferUchar

PciMemWrite8  ScsiPortWriteRegisterBufferUchar  AtaPortWriteRegisterBufferUchar

PciMemWrite16  ScsiPortWriteRegisterBufferUshort  AtaPortWriteRegisterBufferUshort

Figure 2 High Level Driver Architecture

Figure 3 shows how typical data might flow through the driver built in this type of architecture. Note that even though the figure shows a separate entry and exit point, both go to the SCSI Port driver. The OSL is simply the service routines, such as PCI reads and writes, where the OSDM may be typically looked at as the primary Port interface routines, such as StartIo.

Figure 3 Driver Data Flow

Shared Library Advantages

• 
  Major reuse source of code as a developer ports from current OS, such as Windows 2000 to future OS’s that may contain embedded solutions and unique architectures, such as embedded Windows CE.
  
• 
  Major reuse source as a developer ports the driver from the SCSI miniport driver model to the ATA miniport driver model that is planned for release in a future OS.
  
• 
  With a common code component, maintainability and reliability are increased.
  
• 
  Easier to make a transition to a new controller device.
  

Additional Development Notes

During integration, it was found that it was easy for the software to become confused during Hot Plug Events. This is because the software maintains a state for each device (Present or Not Present). Initially, a simple algorithm was used to manage this state flag. It was similar to the following:

If (StateChange) Then

{

If (Present) Then

Else Change state to Present

}
The problem with this simple algorithm is that if there are any hardware failures or spurious events, then the driver loses track of its current state. Thus, to make the driver more reliable, whenever a StateChange event occurs, all devices are rescanned, thus eliminating any ambiguity.

Another challenge in translating a SCSI SRB to Serial ATA and back is to determine the best way to format Identify_Device information back into SCSI Inquiry response format. Translating and building the Inquiry out of the Identify_Device may look similar to the following:

Revision Product Revision Level

F/W Rev + Serial # Vender Specific (If used)
Note that the fields are of dissimilar size. Thus, designers must choose to do their best in determining the best way of formatting the information into the available space. In addition, the following fields are hard-coded within the SCSI Inquiry Data response back to the Port driver:
pSCSI_Inq-> DeviceType = DIRECT_ACCESS_DEVICE;

pSCSI_Inq-> DeviceTypeQualifier = DEVICE_CONNECTED;

pSCSI_Inq-> Versions = SCSI_II;

pSCSI_Inq-> ResponseDataFormat = SCSI_II;

Although Serial ATA effectively obsoletes Ultra DMA, the driver should still call Set_Features to set this feature (to ATA_UDMA_MODE4 or ATA_UDMA_MODE5, for example) because some of the drives out there will not work correctly if this is not done.

Considerations for Porting to the ATA Miniport Driver

Another important design consideration for a developer, whether he or she chooses to use a library model as presented herein or not, is where in the software to build the Scatter-Gather List (SGL). The structure of the SGL turns out to be hardware (controller) dependent. The SGLs must be built in the format that the DMA engine in the controller understands. Thus, ideally this would be abstracted from the OS-dependent portions of the driver and would be integrated into the library component. However, the ATA miniport driver is providing the BuildIo function similar to that in StorPort. One of the primary functions of this routine is to provide a way to build SGLs at a lower IRQL, which effectively improves driver efficiency. Thus, it is a good idea to keep the creation of the SGLs within the OSDM so that the transition to the ATA miniport driver is easier.

Finally, it is always nice to re-iterate Port driver variables that have similar or identical functions between the SCSI miniport driver model and the ATA miniport driver model. The three of primary usage are as follows:

SCSI Mini ATA
SRB  IDE Request Block (IRB)
PathId  Channel

TargetId  TargetId [0-14]

Conclusion

Call to Action and Resources

• 
  For device manufacturers: Be aware of the upcoming ATA Miniport driver model and plan your driver developments to support this new model for Serial ATA devices.
  
• 
  For driver developers: Develop drivers up front planning for usage in future OS’s and even in other hardware environments, such as Microsoft® Windows® CE on XScale.
  

• 
  To provide feedback about Developing a Serial ATA Miniport driver, please send e-mail to donald.b.harbin@intel.com.
  

Acronyms and Terms

ATA Advanced Technology Attachment

CRC cyclic redundancy check

HBA Host Bus Adapter

IDE Integrated Device Electronics

OS operating system

OSDM OS Specific Device Module

OSL OS Service Layer

SATA Serial ATA

SCSI small computer system interface

SGL Scatter-Gather List

SRB SCSI Request Block