Hopefully this is on-topic for this reflector ...
> lots of question about how to talk
> to an ATA/ATAPI device over a USB connection.
...
> Does any public doc exits or is this all
secret/proprietary?
A project like a Usb/Ide bridge involves many levels
of specification ...
1) I'd say the "core" specs that say how to share
amperes and bits are fully public:
http://www.usb.org/http://www.usb.org/developers/http://www.usb.org/developers/docs.html
2) I'd say the "class" specs that say how to copy a
Scsi Cdb out, how to copy how much data which way, how
to copy back in status and residue are fully public:
http://www.usb.org/http://www.usb.org/developers/http://www.usb.org/developers/docs.htmlhttp://www.usb.org/developers/devclass.htmlhttp://www.usb.org/developers/devclass_docs.html#approvedhttp://www.usb.org/developers/data/devclass/usbmassover_11.pdfhttp://www.usb.org/developers/data/devclass/usbmassbulk_10.pdfmailto:email@hidden
I'd say these specs are more fully public than any
other analogous specification for connecting mass
storage.
2a) Vs parallel Scsi, Ata, Atapi, FireWire, the Usb
bInterfaceProtocol x50 spec says precisely how to
represent the reality that real hosts and real devices
disagree over how many bytes to move which way.
2b) Vs. Ansi & Ieee, the Usb bInterfaceProtocol x50
spec, and the core Usb specs, are final public
standards in softcopy, Not merely final drafts.
> I have never seen a public document
> that describes how ATA... commands
> are executed over such a connection.
3) AFAIK there is no standard notation for writing
down together all the bits of an Ata Cdb, much less a
standard for copying an Ata Cdb out over Usb.
By "Ata Cdb" I mean the byte values to write to ports
x1F7,x1F1..1F6,x3F6 and Pio/Dma/UDma Intrq/Not
distinctions over protocol.
There is a place in Usb Mass reserved for such
inventions. A Usb Mass device with an Ata command set
would report a new bInterfaceSubClass code, a code
chosen from among the many reserved codes. I think I
remember a range larger than x10..FF remains reserved
to date. Achieving interoperability with Apple
bootBios and/or MacOS and so on might practically be
difficult ... I can't quite remember if they say x 08
XX 50 means any flavour of Scsi or if they just say x
08 00..06 50 to mean Scsi.
4) I'd say there is no more concrete spec than an
executable implementation, and at least as free as Gpl
is the Linux implementation of bInterfaceProtocol x50:
http://www2.one-eyed-alien.net/~mdharm/linux-usb/http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/linux-usb/storage/http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/linux-usb/storage/unusual_devs.h?rev=HEAD&content-type=text/vnd.viewcvs-markup
> I have never seen a public document
> that describes how ...ATAPI commands
> are executed over such a connection.
5) If you will permit me to use Usb plug 'n play
terms, I can quickly nutshell what we have Not yet
covered.
So far we've told a designer of a generic Usb Mass
Storage device or host how to deserve the privilege of
reporting/supporting core-level bcdUsb = 2.0, and
class-level bInterfaceClass = x08 Mass Storage,
bInterfaceProtocol = x50 BulkOnlyTransport ...
... but we haven't decided the class-level
bInterfaceSubClass "command set".
I personally invented bInterfaceSubClass code x06 to
say out loud that the Usb plug 'n pray descriptor is
the wrong place to try and say what the command set
is. Scsi op x12 Inquiry fills that role, with such
fields as the bytes[x02] ansiVersion and the
(bytes[x00] & x1F) peripheralDeviceType.
In 1998..1999, while implementations were shipping in
advance of the bInterfaceProtocol x50 spec, the name
for code x06 was something more like "the Scsi of
Apple, Linux, Microsoft, Phoenix, Sun". But then I
missed a meeting or two and the name became drab:
"Transparent Scsi".
Originally, I was trying to make a clear and conscious
distinction between Scsi in the real world and the
pretty fantasies that Ansi T10 publish. In the real
world, the need to interoperate is not negotiable: the
brutal reality is that she who ships first wins. I
think the committee judged that much truth to be
impolitic.
I contend vehemently that in fact there is no
reasonably accurate public spec for what Scsi/ Atapi/
etc. Cdb's mean. "Reasonably" here is no doubt my
most contentious word choice. At
<http://members.aol.com/plscsi/> I present the seed of
an effort to make the truth of this contention more
glaringly obvious.
From my personal history of pain, I well know the Sff
Atapi standards are even more fictional than Ansi Scsi
standards.
Off the top of my head, I remember the fiction that
Sff had the authority to change the Dbd bit of
ModeSense to become active lo, the fiction that the S
of a C:H:S capacity could exceed x3F, and the fiction
that Atapi requires Ansi-reserved mode page x1B to
exist.
Personally I'm reasonably ignorant of Ata, but I'm
confident enough that people are people to imagine
that the published Ata standards are equally
fictional, at least until I'm taught better.
> I have never seen a public document
> that describes how ATA... commands
> are executed over such a connection.
6)
With no public standard to define Ata or Scsi with
reasonable accuracy, we can hardly claim to have a
public standard for translation from Scsi to Ata.
We're also missing a public standard for the
translation from Pc Bios to Ata. And the Apple boot
Bios translation to Ata shipped significantly broken
on occasion e.g. if you ask a classic iMac to write a
block, you write garbage (see
http://members.aol.com/plforth/moforth/index.html).
To date, every Scsi to Ata translation I have seen
that was designed without involving me appears
trivially to me to be obviously in conflict with the
public final drafts of Ansi T10. I wish I had a way
of knowing if My translations appear trivially
Incorrect to other people.
7)
Are you yet amused?
Great fun talking, thank you again, what you saw here
is my second draft of an answer, hopefully now
sufficiently to-the-point and no longer intolerably
polemic.
I am Very interested in connecting with the few other
people on Earth who find interesting such obscure
topics like what bytes really do appear as the offset
4 additionalLength of op x12 Inquiry. So if you see
any way maybe we can continue this conversation,
please do feel free to try.
I think I will myself forward an anonymised version of
this to all the more or less public Usb Mass
reflectors I know of (Apple, Linux, and Usb Dwg), to
try and provoke correction there.
... Pat LaVarre email@hidden
http://members.aol.com/plscsi/
>>> ... 03/15/02 11:09AM >>>
I have been getting lots of question about how to talk
to an ATA/ATAPI device over a USB connection. I have
never seen a public document that describes how
ATA/ATAPI commands are executed over such a
connection. Does any public doc exits or is this all
secret/proprietary?
Thanks!
...
Subject: (usb-mass 120) native speakers of Usb define
UsbMass in one page?
From: email@hidden
DateTime: 12/10/01 1:50pm
Hey, hi, I think I just stumbled onto a one page
sketch of bInterfaceProtocol x50 BBB, attached here as
the 4,872 bytes of bbbftp.txt.
The trick here is to say how one could apply core Usb
idiomatically to support BBB, then sketch how not
idiomatic BBB actually is, then explain why.
Anybody see anything in UsbMass Chapter 6 that I've
left out or misrepresented?
I like this sketch because I think it begins to
explain the vehemence with which half of us defended
our sides in the debates which we never resolved.
Here we find cause to claim that no one person among
us consistently defended only idiomatic Usb.
Instead we see idiomatic Usb never moves extra bytes
in, always swallows an indefinite count of packets
out, never STALLs to cut data transfer short, always
STALLs to make anything but an all good CSW persist
just long enough to allow queueing, and never even
hints at our idea of persistently STALLing thru a
ClearStall request.
Like this/ hate this, what? Pat LaVarre
P.S. Me, I gleaned a fresh appreciation for what
idiomatic large-latency mass storage protocol might
look like from studying Internet ftp near
<http://www.ietf.org/rfc/rfc959.txt>.)
[[[ P.P.S. In March 2002, I see, in the attached from
December 2001, the text "for any pure failure
(bCSWStatus = x01 but zero bCSWDataTransferLength)"
did say bCSWDataTransferLength but should have said
dCSWResidue, not bCBWDataTransferLength. ]]]
Yahoo! Sports - live college hoops coverage
http://sports.yahoo.com/
// // // 1. Idiomatic UsbMass
Suppose every bus trace included CBW out, data out, data in, CSW in, and ended each of these four transfers with a short/zero-length packet.
Now suddenly we can have all of the 13 cases look the same in a bus trace: always, in a consistent order, we see four bursts of N full packets followed by 1 short/zero-length packet.
By the Usb assymetry of only the host ever asking to move data, the bus trace always includes the (Ho - Do) bytes of (Do < Ho) but never includes the (Do - Ho) bytes of (Ho < Do) and never includes the (Di - Hi) bytes of (Hi < Di). Some of the (Hi - Di) bytes of (Di < Hi) could appear but never should, since if they do appear they make fuzzy the question of what Di was.
We can distinguish all thirteen cases without STALL, without padding, without turnaround delays. And as yet we have no evil options.
Easy to let the host queue CBW's if you like. If you also want in-order error recovery, then require the device to STALL the CSW In pipe before passing back in nonzero bCSWStatus or dCSWDataResidue. Require the host to flush the CBW and DataOut pipes before clearing the STALL. Require the device to discard output received while the CSW In pipe is STALLed.
Wanna reduce pointless bulk NAKs? Flag the CBW to say the dCBWDataTransferLength there is only the quantity that the host will move before changing over to poll an interrupt pipe instead of a bulk pipe. Then require the evice to pass back an interrupt to say how much more data has become available and to say if the CSW is available. Then require the host to ask to move everything available before again waiting for an interrupt.
// // // 2. HOW Not Idiomatic Is UsbMass
2a) No data moves out if Hi, no data moves in if Ho, no data either way if Hn. Not even a zero-length packet.
2b) No idiomatic zero length-packet after data if H = D.
2c) Option to move in any count of bytes between Di and Hi if Dn < Hi or Di < Hi, rather than just the idiomatic Di. If moving any Di + N altogether less than Hi, IN STALL required. Option for the device to insert an idiomatic zero-length packet moving in only if otherwise ending < Hi with a full packet.
2d) Option for OUT STALL if Do < Ho, rather than swallowing any quantity of data out.
2e) Device actually required to move CSW in for any pure failure (bCSWStatus = x01 but zero bCSWDataTransferLength) without IN STALL. Option to move CSW of any phase (bCSWStatus = x02) error without IN STALL.
2f) No queueing. On paper, CBWOut:DataOut and DataIn:CSWIn each have to wait for the other to complete, no matter how many devices have shipped that work if you neglect this restriction.
2g) No interrupts.
// // // 3. WHY Not Idiomatic Is UsbMass
3a) We ended up with enough of a mess that we had to describe each of the 13 cases separately. Once we did that, then the idea of moving data both ways always have us more to say in the spec, not less: thus a false appearance of greater complexity.
3b) Win95B core Usb couldn't move a bulk zero-length packet out. Deeply ironic for us to care if noone ever implemented bInterfaceProtocol x50 UsbMass to run on the Win95B core Usb or on some other platform that choked over the deeply idiomatic core idea of a bulk zero-length packet out. The Win95 from Iomega, for example, replaces Win95B core Usb, rather than trying to explain its limitations to the customer.
3c) Rumour said some hosts wouldn't retire a whole scatter/gather list on receiving a short packet in. But some of us preferred transferring garbage over having to STALL to cut data transfer short.
3d) Only some of the device folk trusted the host folk enough to design the device accept always moving Ho (up to 4GiB) out before moving a CSW back in.
3e) Some of us wanted H = D failures to move cross the bus without STALLing. Scsi makes failure common for normal situations like "media still not present", but some devices make STALL recovery expensive by choking unless you delay 100's of ms when clearing STALLs. And only less than all of us liked to trigger on STALL to see phase errors.
3f) We've never shown queueing to buy us much. We got so used to auto-clearing STALL to make a STALL work like a short packet should that we haven't thought through using a single extra STALL to make errors persist just long enough. In particular, what's meant as the first CSW STALL may appear as a data In STALL if you believe some hosts keep reading a scatter/gather list past the first short/zero packet In.
3g) Nobody tells a clear story on how wasteful a bulk IN NAK or bulk out PING NAK is vs. an interrupt NAK. The fact that Usb2 changed to allow the PING NAK in place of the OUT NAK that pointless carries a data payload suggests that UsbMass isn't the only device class designed to provoke a lot of NAK?
_______________________________________________
usb mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/usb
Do not post admin requests to the list. They will be ignored.
