This message is from the T13 list server.
Mark, Curtis, all, The original question came up in a discussion about correct PATA emulation of a SATA host controller. Let me give an example. For simplicity, let me make some assumptions just for the example: - host is a PC using legacy software not aware of SATA - host software communicates through the task file registers with the device - software uses interrupts to wait on BSY/DRQ changes - interrupt generation is enabled in device (nIEN == 0) - both host and device use a sector size of 512 bytes - software wants to transfer 2 sectors from the device in PIO mode using the READ SECTORS command Regardless of the HBA/device combination being PATA or SATA I would expect the following sequence: 1 Host software programs the task file and finally writes the READ SECTORS command to the command register 2 Device sets BSY = 1, and host software waits for the first DRQ data block being ready for transfer (interrupt) 3 After some time, device sets BSY = 0 and DRQ = 1 and triggers interrupt 4 Host sees interrupt, reads status register: BSY == 0 and DRQ == 1 5 Host reads 512 bytes (first DRQ data block) from data register 6 Device sets BSY = 1, and host software waits for the second DRQ data block being ready for transfer (interrupt) 7 After some time, device sets BSY = 0 and DRQ = 1 and triggers interrupt 8 Host sees interrupt, reads status register: BSY == 0 and DRQ == 1 9 Host reads 512 bytes (second DRQ data block) from data register 10 Device sets BSY = 0 and DRQ = 0 Now the issue: I have been told that in SATA the device is allowed to answer the above READ SECTORS command (Register FIS Host to Device) with a PIO Setup FIS with a transfer count of 1024 and a Data FIS Device to Host with 1024 bytes data payload. Everything in the above example would work fine until 6. At this point the host software assumes the first DRQ data block is done and waits for the next interrupt. The device though, obviously assumes a DRQ data block of 2 sectors and a) is stuck trying to send the rest of the Data FIS in case the host FIFO is too small. b) thinks the transfer is finished in case the host FIFO could absorb the whole Data FIS. Anyway, the host software will wait forever for the next interrupt which will not occur because the device will not send another PIO Setup FIS. And this is all because host and device did not agree on the size of a DRQ data block. If the DRQ data block definition was still the one that it was in ATA/ATAPI-6 r3b, a host and a device complying to the spec would agree on the DRQ data block and the SATA device would be forced to send two pairs of PIO Setup FIS/Data FIS transferring one sector each. Note that it does not matter whether the sector size is 512 bytes or not. It only matters that host and device agree on the DRQ data block size being one sector for a READ SECTORS command. No? Regards, Alex. > Because on serial ATA a data block may be more than 512 bytes. Also that definition is chock full of parallel specific terminology. All the information is there, it's just moved to specific areas. Those words in IDENTIFY DEVICE are still fully described. > > ________________________________ > > From: [EMAIL PROTECTED] on behalf of Alexander Krebs > Sent: Tue 7/5/2005 2:17 AM > To: [email protected] > Subject: [t13] DRQ data block definition > > > > This message is from the T13 list server. > > > Hi all, > > Does anybody know why the definition of the term "DRQ data block" > changed from > > ATA/ATAPI-7, vol 1, rev 3c > 3.1.42 DRQ data block: This term describes a unit of data words transferred during a single assertion of DRQ when using PIO data transfer. A data block is transferred between the host and the device as a complete unit. For all PIO data transfer commands except READ MULTIPLE, WRITE MULTIPLE, and PACKET, a DRQ data block is one sector, 512 bytes. For READ MULTIPLE and WRITE MULTIPLE commands the DRQ data block is the number of sectors indicated in word 59 of the IDENTIFY DEVICE response. For PACKET command the DRQ data block for transfer of the command packet is the number of bytes indicated in word 0 of the IDENTIFY PACKET DEVICE response. > > to > > ATA/ATAPI-7, vol 1, rev 3d > 3.1.44 DRQ data block: This term describes a unit of data words transferred during a single assertion of DRQ when using PIO data transfer. > > ? > > Given the lost sentences in ATA/ATAPI-7, rev 3d, how shall host and > device determine the exact size of a DRQ data block? Since both host > and device need to agree on the size of a DRQ data block, this is an > essential definition. Did this information move somewhere else? > > Thanks, > Alex. > > > >
