SCSI Execute Command remote procedure at bit level

Pat LaVarre p.lavarre at IEEE.org
Wed Jun 2 08:14:47 PDT 2004


* From the T10 Reflector (t10 at t10.org), posted by:
* Pat LaVarre <p.lavarre at ieee.org>
*
Erick v:

> > The CDB by definition is not complete.
> Is this a reference to http://members.aol.com/plscsi/cdbcomplete.html
> You explained a lot here.  

Good to hear, thank you.

I collect compliments on that explanatory essay (e.g. "very well
written", "would benefit us all if this were required reading for all
interface code developers") along with guessing of how to finish/
distribute it, at:

Subject: CDB Complete (not)
http://plavarre.blog-city.com/read/547918.htm

> > You may decide you want op x3B/ 3C "WRITE"/ "READ" "BUFFER".  That
> > standard option gives you a clear way to set D via a CDB, any time unit
> > attentions are absent.  That lets you survey the thirteen cases easily.
> Could you explain this more in detail, I don't seem to follow correctly.
> by D you mean DATA?

Sorry no.  In SCSI over USB slang,

H "is the count of data bytes the" host asks "to copy".

D is the count of data bytes the device actually agrees to copy.

With an actually compliant device, the t10.org standard option of op
x3B/ 3C sets D in CDB bytes 6:7:8, if I remember correctly, for at least
PDT x05/ 00 = MMC/ SBC = DVD/ HDD.

For SCSI over USB, H is the dCBWDataTransferLength and R is the
dCBWDataResidue.  By definition R = H - D, so we calculate D = H - R.

> > Now suppose the device actually agrees to copy xC0 (192) bytes in.
> > Then the residue is the expected xFF (255) minus the actual xC0 (192)
> > i.e. x3F (63).
>
> The USB CSW only sends 4 BYTE of residue, am I correct. Or is it the
> total residue back as part of the CSW?

Sorry I'm not sure we're communicating.

Yes "the SCSI over USB positive residue" field is the dCSWDataResidue
which is a four byte field of the CSW packet.  The CSW, you will
remember, primarily carries the bCSWStatus chosen from x00 Passed, x01
Autosensed, x02 Other.

The data bytes clocked but not copied are "the positive residue of
bytes", but SCSI over USB reports the existence of such bytes by
counting them, not by reclocking them over the wire.  SCSI over USB can
count at least up to x7FFF:FFFF bytes = 2 Gi - 1 B of positive residue,
indeed arguably up to xFFFF:FFFF bytes = 4 Gi - 1 B.

Did you catch that?  The English (or t10.org slang) phrase "the positive
residue" can mean merely the count of bytes clocked but not copied, or
instead the bytes themselves.  When we resort to English rather than
plain hex, by context you have to guess which meaning is meant.

The data bytes copied but not clocked are "the negative residue", but
SCSI over USB gives no specific way of reporting that they exist, since
they should not.  I have seen to-my-mind out-of-spec SCSI over USB
implementations that in fact stuff a two's complement negative residue
report into the supposedly unsigned dCSWDataResidue field.

> > ----- 5. Hi vs. Do example
> >  > Do I need to wrap this in another USB wrapper?
> > 
> > No can do.
> > 
> > SCSI over USB gives you the bridge no way to copy data the host has not
> > asked you to copy.
> Understood, this is because USB is host based, right?

Yes, same as SCSI over SPI/ IDE, but different from SCSI over FireWire/
Ethernet.

> > SCSI over USB never gives you the bridge permission to send anything
> > unwrapped.  CBW wraps CDB Out.  CSW wraps Status In.  CBW and CSW
> > together appear before and after the Data of the command.
> 
> I think it should go like this. Am I right?
> CBW --> (optional) DATA-OUT --> (optional) DATA-IN --> CSW

Yes.

Witness usbmassbulk_10.pdf "Figure 1" "Command/ Data/ Status Flow", page
13 of 22.

> Now, how do I put the DATA-IN BUFFER from the SCSI service response for
> (ie the INQUIRY) in the above data block?
> 
> Do I make an CBW with the INQUIRY inside it. And then send the SCSI
> DATA-IN BUFFER as the DATA-IN and finish with the CSW with sense GOOD?
> Does this describe an correct INQUIRY over USB?

Yes.

Witness http://www.win.tue.nl/~aeb/linux/usb/traces/winxp/bbb-05-rmb.log

: g_file_storage gadget: bulk-out, length 31:
:      0:  55 53 42 43 10 ad bd 81  24 00 00 00 80 00 0c 12
:     10:  00 00 00 24 00 00 00 00  00 00 00 00 00 00 00
: g_file_storage gadget: SCSI command: INQUIRY;  Dc=12, Di=36;  Hc=12, Hi=36
: g_file_storage gadget: bulk-in, length 36:
:      0:  00 80 02 02 1f 00 00 00  4c 69 6e 75 78 20 20 20
:     10:  46 69 6c 65 2d 53 74 6f  72 20 47 61 64 67 65 74
:     20:  30 32 30 31
: g_file_storage gadget: bulk-in, length 13:
:      0:  55 53 42 53 10 ad bd 81  00 00 00 00 00

> ----- 1. SCSI response defined
> > What is a "SCSI response"?  Is that SAM jargon?
> 
> I mean Service response referring to:
> Service response = Execute Command (IN(I_T_L_x Nexus, CDB, [Data-Out
> Buffer], Task Attributes),
> OUT([Data-In Buffer], [Autosense Data], [Autosense Return Flag],
> Status))
> from SPC2

Clear now thank you.

Pat LaVarre


*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org




More information about the T10 mailing list