This message is from the T13 list server.
Pat, Mike's correct. What people should be doing in your example is the following: 1) the host sets an allocation length of 5 in the CDB that is sent via the PACKET command to the device 2) the device receives the command, and ultimately gets the required data 3) the drive transfers 6 bytes of date to the host. The first 5 bytes is the data requested by the CDB, the last is a pad byte (which can have any value). 4) the host is fine with receiving 6 bytes of data across the ATA bus (afterall, there is no byte count limit for DMA, and the host is obligated to pace the drive's transfer rate if it lacks the buffering to handle long transfers). 5) at some level in the software stack in the host it knows that the first 5 bytes are valid and should be passed up to a higher level in the software stack, but that the 6th byte is just a pad byte (and so should be discarded) If you do the above then there is no confusion and everything complies with the standards as that exist today (although I admit that getting to this point is not as obvious as I'd like - yet more business for folks like Hale!) This is fine you may say for the entity in the host that knows about CDBs, but what about my USB to ATA bridge? Well, if you look at the CDB (i.e. see the 5), then you have the same knowledge as the host and can do the above process, returning to the host via USB the 5 bytes. Any bridge with a micro controller today will do this sort of thing. If you do not, then I'd just return the 6 bytes the drive gave you. Some bridges do not have micro controllers, but they do ship device drivers - I'd sure the device driver intercepts the 6th (pad) byte. If you do not do this in the bridge or in a piece of software you supply for the host, then the native host software have to recognize this case and handle it. This is very straightforward, and there is no risk of the host getting any sort of bad data - it can never be confused. Indeed, this is evidently what the PC software stack does today since clearly people ship products and most PCs don't use any soft of bridge or device driver at all. As I stated before, the PACKET command section could use some updating anyway, and putting in some more words to these effects is probably reasonable. It may also be the case that some default software stacks do indeed blow up under this circumstance. The problem here is that no one has pointed out a case where the host is blowing up. If there is information on this aspect I'd appreciate hearing about it. Jim -----Original Message----- From: Eschmann, Michael K [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 30, 2002 11:02 AM To: [EMAIL PROTECTED] Subject: RE: [t13] yes AtapiPio supports odd byte transfers This message is from the T13 list server. But ATA/ATAPI as a transport layer, the data will always come across the boundary as words. The data may have a pad byte, that is driven by fields in the data. You will always get an even number of "Bytes" transferred to/from memory. Anyone doing otherwise has a special case design, such as your USB-ATA bridge. >From your own text: 3 data clocks follow, 6 bytes clock across the bus, and by the AtapiPio protocol both host and device can know they agree to discard just the last byte, leaving a total of 5 bytes, merely because the DRQ byte count was odd. No data gets "quietly copied into the void", the data shows up somewhere and the host or device uses the CDB count of 5 to indicate how many useful bytes are analyzed. All 6 still get transferred! I don't know of any controller that will discard the last byte, unless it is a special-case design (again, your bridge design). I don't see why this is so hard to understand?! MKE. -----Original Message----- From: Pat LaVarre [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 30, 2002 10:25 AM To: [EMAIL PROTECTED] Subject: [t13] yes AtapiPio supports odd byte transfers This message is from the T13 list server. MKE: > ATA/ATAPI can ever stop at an odd-byte boundary? > ... not specifically > due to any ATA/ATAPI interface allowance. I say yes specifically per Ansi text. In detail: Thank you for listening closely and for finding the time to speak up. I am trying hard to politely entertain the idea that I'm confused in more areas than I know, but, here, shortly, flatly: Yes, Ansi AtapiPio does support odd byte transfers. I'm sorry to hear that's not broadly appreciated. Indeed, when trading off Ata vs Atapi, I'd say a key advantage Ata holds is that this committee has very sensibly maintained that nearly all data transfers be whole block transfers. In Ata, we have only block transfers and (obsolete) long block transfers. In Atapi, we have a third kind of transfer: the non-block transfer. Before now, I don't remember hearing the existence of fully arbitrary non-block total transfer lengths seriously disputed here. Before now, only when the English gets vague did I see us raise the idea that AtapiPio doesn't transfer odd bytes. I'm so painfully familiar with how often Atapi commands do involve odd byte counts because in the real world, Win95B Atapi did not sustain the odd byte transfers that blesses Ansi on paper, so devices designed to work with more robust hosts had plug 'n play troubles there that I was paid to fix. (As of Win98, Win Atapi life suddenly became less frustrating because Microsoft suddenly added odd byte count support.) A concrete example is the common Cdb x 12 0 0 0 05 0 i.e. an op x12 Inquiry for up to 5 bytes. By Scsi, any device that has 5 or more bytes available is supposed to interpret this Cdb to mean move precisely 5 bytes in - an odd number. In AtapiPio, this works, no worries. Most commonly, there is exactly one DRQ INTRQ,the C/D I/O is then x02 DataIn, the x1F5:1F4 Cylinder (aka byte count) is 5. Not 4. Not 6. Yes 5. By Ansi text. 3 data clocks follow, 6 bytes clock across the bus, and by the AtapiPio protocol both host and device can know they agree to discard just the last byte, leaving a total of 5 bytes, merely because the DRQ byte count was odd. By Ansi text. What's missing from AtapiDma, vs. AtapiPio, is a corresponding expression of "residue" i.e. the agreed count of bytes to quietly copy into the void. I can only guess why x 12 0 0 0 05 0 is common. Clearly, the Cdb x 12 0 0 0 24 0 works better: that's the Cdb that Windows sends, and nothing plugs 'n plays so well as TalkLikeWindows. All the same, in my painfully limited experience, outside of Windows, outside of block commands, then the most popular technique for ensuring beforehand that the host and device do agree how many bytes will transfer is to stutter reads. That is, first read a header believed to be always available, then interpret that header to decide how much more to read the second time. In the case of op x12 Inquiry, the "additional length" byte is at offset 4. So to read just enough of the header to get the additional length is to read 5 bytes. So we see the Cdb x 12 0 0 0 05 0. If the byte at offset 4 is even, for example x8C, then next we see another odd length transfer, for example the Cdb x 12 0 0 0 91 0. Am I yet more clear than mud? Yes, Ansi AtapiPio does support odd byte transfers. Hope this helps, thanks in advance. Pat LaVarre >>> "Eschmann, Michael K" <[EMAIL PROTECTED]> 01/30/02 08:51 AM >>> This message is from the T13 list server. Pat, why do you insist that ATA/ATAPI can ever stop at an odd-byte boundary? It transfers data as atomic words (except for CFA, which I hope you aren't gonna confuse matters by talking about that). You may be getting this on the host-side of a USB-to-ATA/ATAPI bridge, but not specifically due to any ATA/ATAPI interface allowance. Your nsistence that this happens on ATA unnecessarily perpetuates these threads. MKE. Subscribe/Unsubscribe instructions can be found at www.t13.org. Subscribe/Unsubscribe instructions can be found at www.t13.org. Subscribe/Unsubscribe instructions can be found at www.t13.org.
