1 / 13

Concerns about ATAPI devices using SATA bridges

Concerns about ATAPI devices using SATA bridges. Mark Hartney Silicon Image August 19, 2003 T13 document e013131r0. The conversion to SATA.

imelda-matthews
Télécharger la présentation

Concerns about ATAPI devices using SATA bridges

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Concerns about ATAPI devices using SATA bridges Mark Hartney Silicon Image August 19, 2003 T13 document e013131r0

  2. The conversion to SATA Initial and emerging implementations of ATAPI devices for Serial ATA use bridge silicon, which converts SATA protocol signals from the host to PATA signals for the device This is how the majority of SATA hard disk drives are built today Both HDDs and ATAPI devices will ultimately integrate SATA into their control ASICs over the next few years

  3. Different implementations 3 different scenarios are envisioned, in sequential order: • Use of a separate bridge adapter that plugs into IDE connector of ODD • Integration of bridge silicon onto the ODD PCB • Integration of SATA functionality into the ODD controller

  4. SATA: DMA Packet Commands • A SATA Data FIS is sent to a bridge device that contains a DMA Packet Command • The device bridge does not know whether this packet contains a read or write request • The host controller will know this however since it constructed the command • The expected response to the host controller is different depending on whether the command is a read or write • DMA Activate FIS is expected for a DMA Out packet cmd • Data FIS is expected for a DMA In packet cmd

  5. How can a bridge determine the command direction? • Ideally, by reading the device task file this could be ascertained (eg. IOIN) • Unfortunately, most ATAPI devices do not present the task file correctly when the bridge wants to read it – after DMARQ is asserted. This should be available until DMACK- but is typically returned as 7F or is corrupt Note: for a fully integrated SATA ATAPI controller, there is no ambiguity – only for the bridge cases

  6. So what does the bridge do? • In most cases the host will decide the bridge cannot support DMA commands and will downgrade to PIO • In some cases the bridge may hang and the command will abort

  7. Potential solutions (1) • Decode the packet command in the bridge device: • Requires extra gates and devices in bridge – the host and device already know this data • Hardware decoding would prevent implementation of new commands • Hardware decoding would prevent implementation of vendor specific commands

  8. Potential solutions (2) • Use a separate signal to decode in ATAPI device controller and communicate to the SATA bridge • Requires extra pins on bridge and controller • Requires code to communicate between devices • Does not work for adapter that plugs into PATA device

  9. Potential solutions (3) Have the host communicate direction to the bridge • Host already knows direction, no additional decode required • Works for both adapter and integrated chip scenarios • Requires minor modification to the host driver

  10. Host Driver Change details • Use a previously reserved bit – bit2 in features register for packet commands • BIT 2 becomes DMAIN – set to 1 for reads, 0 for writes • Can enable/disable support with bit in ATAPI Set Features • Eg. – Word 50, bit 13: Set to 1 for devices that support DMAIN bit in Features Register for Packet Command

  11. Host driver considerations • SATA controllers today are written with either legacy ATA drivers or “native SATA drivers” • Many SATA controllers are written in native SATA mode to enable support of HotPlug, SATA error reporting, enhanced features • Discrete controllers typically have their own drivers • Integrated controllers often use legacy drivers for this generation • Legacy drivers would not be able to support this without modification • Native SATA drivers will be required for SATA II feature support – standardization effort with AHCI • Good intercept point for next generation

  12. ATAPI Device Impact • Primary change is to enable support for ATAPI Set Features • Can enable when integrating bridge silicon onto the device • Support is no longer needed for an integrated SATA controller – can be turned off in FW • For PATA devices which might use discrete SATA converter, can enable if there is no problem with DMAIN bit • We have not found any problematic devices to date

  13. Next Steps • We are raising this issue for T-13 committee consideration • We would like to present a proposal at the next meeting in October • We would like to continue discussions with appropriate stakeholders

More Related