Ana səhifə

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

Yüklə 414.5 Kb.
ölçüsü414.5 Kb.

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.


Introduction 3

Serial ATA Overview / Advantages 3

Development Environment Overview 4

Driver Architecture 5

Overview 5

Shared Library Advantages 8

Additional Development Notes 8

Considerations for Porting to the ATA Miniport Driver 9

Conclusion 10

Call to Action and Resources 11

Acronyms and Terms 11

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.


This paper provides information pertaining to the development of a Serial ATA driver in the SCSI Miniport driver model. This is required because the Serial ATA hardware to be driven by the IDE Port driver currently available by Microsoft is not designed to take advantage of the advanced features provided by Serial ATA. This paper proposes an architecture, shares some of the considerations a developer may want to be sensitive to, proposes some design suggestions to minimize any future efforts to port the driver to Mini ATA (to be released in a future Microsoft® Windows® operating system), and discusses some development considerations. In addition, the paper will briefly overview Serial ATA as a technology and summarize some of its advantages over parallel ATA.

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

Prior to exploring the driver architecture, a brief overview of Serial ATA may be helpful in establishing a level of understanding for this paper. Please visit the Serial ATA Web site at for a more in-depth review of Serial ATA. Serial ATA continues to use the ATA command set of Parallel ATA for compatibility. The Parallel ATA/ATAPI specifications can be found at the Web site. The Serial ATA specification provides extensions to the command set defined by Parallel ATA. These additional commands provide extended features specific to Serial ATA. Serial ATA, as the name suggests, has abandoned the parallel bus model and has gone to a serial transfer model. This provides advantages, such as higher speed and the addition of CRC error checking. By using a serial technology, other advantages include smaller cables and lower power usage.

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 port1. Thus, what disappears in the driver developed in this design is the concept of a Master and a Slave sharing a single bus2. 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

The Serial ATA driver that was developed and tested as the foundation for this paper was developed in the environment shown in Figure 1. It was tested using Windows 2000, Windows XP, and Windows Server 2003. The Serial ATA Controller used is a four-port device residing upon the SATA HBA shown in the figure. The design of the software allows the simultaneous access of all four Serial ATA ports.

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 Plug3 and Tagged Command Queuing4.

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


For the reasons outlined in the previous section, this Serial ATA driver has been developed as a SCSI Miniport driver. The focus of this driver development was to provide a driver that could do the fundamental requirement of moving block data to and from the drives, with the additional feature of being able to support Hot Plug. With this in mind, it did not require the support of an enormous number of the commands in the SCSI command set.

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

Miniport Driver SRB Function Code


Code Size

SCSI CDB Operational Codes

Serial ATA Command













Hard Coded



















App Specific


App Specific


App Specific


App Specific


App Specific








Hard Coded to reset port.


Hard Coded to reset port.


App Specific

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:

Library Interface SCSIPort ATAPort

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

The following list recaps the advantages to a developer of a new driver using a library-based architecture:

  • 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.

After reviewing the percentage of code that can be “abstracted” into a library, it was found that ~75% of the total miniport driver code can be moved into this kind of an independent library component. It is also believed that this can be done with no performance impact to the overall driver if designed correctly.

Additional Development Notes

Several other up-front decisions are good to consider when developing your driver. For example, it is recommended that a separate PathId be used for each of the physical ports on the Serial ATA controller. The alternative would be to have one PathId with four TargetId’s, using the example controller of Figure 1. The advantage of separate PathId’s for each of the four physical channels is when a single channel fails, causing the SCSI Port driver to time out on and SRB, then the Port driver will only reset single device that is connected to that channel, as opposed to all four devices if they were all separate TargetId’s behind the same PathId. Thus, a single failure is less likely to bring down all of the drives. This example is exacerbated when one looks into the future and the use of Port Multipliers, which may allow over a dozen devices behind one channel.

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

Change state to Not Present

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:

Serial ATA (Identify_Device) SCSI (Inquiry Data)
SATA Model # Vender ID + Product ID

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-> 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

A critical element to keep in mind in the initial design when planning on eventually porting the driver to the ATA miniport driver model is to design the driver so that data (SRBs) can always be sent from the port driver to the miniport driver. This is because the ATA miniport driver is moving away from the “pull” model of the current SCSI miniport driver and into a “push” model. The pull model is exemplified by the idea that whenever a SCSI miniport driver is ready for another data SRB, it sends a ScsiPortNotification with a NextRequest to ask for it. To more closely simulate a push model along with increasing driver performance, a designer should always perform the NextRequest in StartIo after a command request has been sent to the drive, and before the response to that command has been received and processed. Then, if another SRB comes down for that port from the Port driver and the device is not ready, the miniport driver can simply return the SRB with a busy status and allow the port driver to try again later. The big advantage here is three-fold. First, SATA Tagged Command Queuing can handle many more than one simultaneous commands. But more than that, even if that channel’s queue is full, the port driver may have an SRB ready for another one of the four channels on this controller. Therefore, this model allows for parallel processing of frames across channels. And third, as stated above, the driver will already have some of the kinks worked out when the decision to port to the ATA miniport driver is made.

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:

SRB  IDE Request Block (IRB)
PathId  Channel

TargetId  TargetId [0-14]


Hopefully, upon review of the above information, the development of your miniport driver is a more enjoyable and straightforward experience. And as you utilize some of these suggestions, when the time comes to porting and maintaining your code, I am sure that you will be glad that you have considered some of the enclosed suggestions.

Call to Action and Resources

Call to Action:

  • 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.


Acronyms and Terms

API Application Programming Interface

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


SCSI small computer system interface

SGL Scatter-Gather List

SRB SCSI Request Block

TCQ Tagged Command Queuing

1 As always, exceptions exist, the Serial ATA working group is considering a device, known as a Port Multiplier, which would allow multiple devices behind one physical port. See the Serial ATA website for more details.

2 Again, a compatibility mode is possible in Serial ATA to emulate Master/Slave, but the driver discussed in this paper does not implement that mode. If a controller is configured in that mode, then the IDE Port driver available today by Microsoft will control the devices behind the controller.

3 Drive Hot Plug requires a specifically designed drive bay that supports Serial ATA drive hot plug.

4 This is not command queuing as defined in the ATA/ATAPI specifications, but is the Tagged Command Queuing as defined in the Serial ATA II: Extensions to Serial ATA 1.0 Specification. This form of queuing is closer to SCSI defined Tagged Command Queuing, performs better than the command queuing defined in the baseline ATA/ATAPI specification, and requires Serial ATA drives that support the functionality.

Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur © 2016
rəhbərliyinə müraciət