This message is from the T13 list server.
Replying to several emails here... === Curtis Stevens said... >Further, if the host side is designed with independent >state-machines to read data and to send commands the IO and CD >bits become very important. I am aware of some firmware that >works this way... The firmware is not broken because IO and CD >are well defined in the specification as to how they operate >during data transfers. So if the the command is a write command but the device messes up and sets IO and CD to indicate a read command I sure hope this host device will detect the error! === Pat LaVarre said... >As you increase the speed of the engine that moves status back >in, you discover that the engine that moves data reports done >prematurely. For example, maybe the data in has moved in towards >the host from the Dram block fifo but hasn't yet left the Sram >byte fifo, or vice versa: the data out has entered the Sram byte >fifo but hasn't yet reached the Dram buffer fifo. This is the >most common cause I've seen for moving less than the expected >count of data without reporting an ERR. Pat: What in the world are you talking about here? Sounds to me like you are talking about a BAD DEVICE? If we are talking PIO data transfers then the device SHALL NOT set DRQ=0 until after the last word of the DRQ data block has been transferred. If we are talking DMA then the device SHALL NOT set BSY=0 DRQ=0 until the last word of the last DMA burst has been transferred. I don't know about the other here on the T13 list but I really don't care about BROKEN DEVICES. I am not about to propose or support changes to the ATA/ATAPI standards to cover BROKEN DEVICES (or BROKEN HOSTS). === Hale Landis said... > The first time an ATAPI device > has status of BSY=0 and DRQ=1 > it is requesting the "command packet". AND THEN Pat LaVarre said... >Not necessarily. Yes the device "should be" requesting command >out then. Maybe it is, maybe it isn't, the point of the Sff >redundancy design here is to tell us. Pat: What in the world are you talking about? This is one thing in SFF-8020 that has NEVER been in question. If an ATAPI device does not accept the Command Block values for the PACKET command then it should immediately set BSY=0 DRQ=0 and ERR=1 (the value of IO and CD are a don't care because no SCSI command was sent to the device. If an ATAPI device accepts the Command Block values for the PACKET command then it SHALL set BSY=0 and DRQ=1 and receive the SCSI command packet. What happens next depends on what that SCSI command packet contains. Do you really think SFF-8020 allows for other implementations? Do you really think there is some difference between SFF-8020 and ATA/ATAPI-x? Just what are you talking about anyway? === Pat LaVarre asked (when talking about using IO and CD to detect unexpected resets)... >Tell me again what Ansi paragraph I'm violating how? The IO and CD bits exist and are valid only between the time an ATAPI device accepts the PACKET command and until after the time both BSY=0 and DRQ=0 at the end of that PACKET command up until the time the host does the next write to any of the device Command or Control Block registers. There is no IO or CD bit when an ATAPI device executes an ATA command (like A1H, EFH, etc). I would ask what part of the SFF-8020/ATA/ATAPI protocols are you trying to ignore? === *** Hale Landis *** www.ata-atapi.com *** Subscribe/Unsubscribe instructions can be found at www.t13.org.
