I realize this is a very basic question, but I am very new at this. I need to be able to issue vendor unique commands to a USB hard drive, and I need to do it through the USB interface in Windows. From what I have read, I think I need to write a driver, but where do I start? I am used to writing programs for DOS that access the IDE port directly. Ideally, it would be nice to be able to somehow have a “bridge” between the current DOS programs and the USB device, so I can run the same tests with minimal modifications to the code.
Can someone tell me what I need and where to find the information?
Thanks and best regards,
EQ
I would just open a handle to your device (through GUID_DEVINTERFACE_DISK) and then use IOCTL_SCSI_PASS_THROUGH_DIRECT.
Be prepared to a failure of such a project.
The reason is that most USB->IDE bridge chips (found in the hard drive
external enclosures) can only translate a limited command set, without the
vendor-unique commands.
Well, if you’re an enclosure vendor, then another song 
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntdev…
> I realize this is a very basic question, but I am very new at this. I need
to be able to issue vendor unique commands to a USB hard drive, and I need to
do it through the USB interface in Windows. From what I have read, I think I
need to write a driver, but where do I start? I am used to writing programs
for DOS that access the IDE port directly. Ideally, it would be nice to be
able to somehow have a “bridge” between the current DOS programs and the USB
device, so I can run the same tests with minimal modifications to the code.
>
> Can someone tell me what I need and where to find the information?
>
> Thanks and best regards,
> EQ
>
This is one of the reasons that T10 took the effort of defining an ATA
pass through in the SCSI/ATA Translation Standard.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Friday, February 23, 2007 8:28 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Vendor Unique Commands for USB Storage
Be prepared to a failure of such a project.
The reason is that most USB->IDE bridge chips (found in the hard
drive
external enclosures) can only translate a limited command set, without
the
vendor-unique commands.
Well, if you’re an enclosure vendor, then another song
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntdev…
> I realize this is a very basic question, but I am very new at this. I
need
to be able to issue vendor unique commands to a USB hard drive, and I
need to
do it through the USB interface in Windows. From what I have read, I
think I
need to write a driver, but where do I start? I am used to writing
programs
for DOS that access the IDE port directly. Ideally, it would be nice to
be
able to somehow have a “bridge” between the current DOS programs and the
USB
device, so I can run the same tests with minimal modifications to the
code.
>
> Can someone tell me what I need and where to find the information?
>
> Thanks and best regards,
> EQ
>
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
Yes,
this I can answer off the top of my head having over a year working with the Cypress chips EVERY usb I/O device will only support vendor commands if they are implemented in firmware, not only must the firmware support the command but also the way it responds is dependent on the firmware so even if you do send the “right” stuff anything you get back will probably have no meaning to you unless you have speciffic info for that device 'cept for the standard commands which are the same but have different command numbers ( vendor commands are 0xB0 thru 0xBF ) the standard commands are used to detect, ID, enumerate, etc… a device when plugged in.
Footnote on my prior posting.
Sounds like you want the standard commands not the vendor commands try surfing the Cypress website for the FX2 usb “Technical Reference Manual” it’s a .pdf file about 5 or 6 meg in size.
The part you want is in the first 3 or 4 chapters so you will only need to read a few kbytes of text it’s a discourse on command channel traffic bolth standard & vendor specific it will point you in the right direction or at least tell if what you want is “do-able” - DBB
xxxxx@xitron.com wrote:
this I can answer off the top of my head having over a year working with the Cypress chips EVERY usb I/O device will only support vendor commands if they are implemented in firmware, not only must the firmware support the command but also the way it responds is dependent on the firmware so even if you do send the “right” stuff anything you get back will probably have no meaning to you unless you have speciffic info for that device 'cept for the standard commands which are the same but have different command numbers ( vendor commands are 0xB0 thru 0xBF )
I don’t quite understand what field you’re referring to. Vendor
requests will have a bmRequestType of 0x40, 0x41, 0x42, and 0x43 for
output commands, and 0xC0, 0xC1, 0xC2, and 0xC3 for input commands. B0
through B3 would be class-specific input commands. For the vendor
commands, you can put anything you want in bRequest, wValue, and wIndex.
Now, the reality is that the bmRequestType field is parsed by the
firmware, too, so with custom firmware you could use whatever values you
wanted. Howewer, B0 to B3 could be defined by a particular device class
spec to have a specific meaning. B4 to BF are not valid (strictly by
the spec).
That is, unless I misunderstand you.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Sorry tim,
I only know how Cypress describes this. The 0xB? series of commands are what they recomend for R&D probably BECAUSE they are undefined 'cept 0-4 which the Cypress drivers don’t use ( ok now that I think about it 0&1 may be used ) even so the Cypress docs list most of the useful pre-defined stuff, the vendor specific ones only have meaning to the vendors stuff I doubt Mark wants that since it’s different for every maker & varies from model to model as well, but things like reading ID strings and such are all standard.
xxxxx@xitron.com wrote:
Sorry tim,
I only know how Cypress describes this. The 0xB? series of commands are what they recomend for R&D probably BECAUSE they are undefined 'cept 0-4 which the Cypress drivers don’t use ( ok now that I think about it 0&1 may be used )
Ah, I see where the confusion is coming from. Part of the problem is
your use of the word “command”, which although convenient, is not part
of the USB terminology. You’ll never find a definition for “the 0xB2
command”.
The FX2 parts do recognize several vendor device requests (which have
bmRequestType=0x40) automatically; those requests have bRequest values
in the range 0xA0 to 0xAF. They are used for downloading the firmware
and resetting the 8051, and are recognized even without firmware being
loaded. Any other value of bRequest gets passed to the firmware for
processing.
Even those numbers are strictly a limitation of the FX2.
even so the Cypress docs list most of the useful pre-defined stuff, the vendor specific ones only have meaning to the vendors stuff I doubt Mark wants that since it’s different for every maker & varies from model to model as well, but things like reading ID strings and such are all standard.
In fact, Mark was talking about a USB mass storage device. The USB
Storage Class specification basically layers the SCSI command set on top
of a USB stream. It defines its own set of “vendor commands” that are
separate from the USB concept of “vendor requests”.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Thank you all for your comments. I’ve been looking around to try and figure out how the registers are mapped from the SCSI to the ATA registers. My assumption is that this SCSI command is issued from the host through the USB interface, but what gets written to the registers on the ATA device?
Whatever the USB->ATA bridge wants. Seriously. You have very little
influence over the contents of the ATA registers on any specific command.
Of course, the obvious mapping of READ/WRITE 6/10/12 to READ/WRITE DMA
(EXT) should result in a predictable taskfile, but there’s nothing to keep
the bridge from LBA remapping that renders that assumption invalid. If
you are trying to determine what a particular bridge chip is doing, an
analyzer is your best friend.
If you are trying to write an arbitrary taskfile to the ATA registers on
an ATA device attached through an arbitrary bridge chip, you’ve got a lot
longer row to hoe. Short of a proprietary interface given you by the USB
bridge vendor, either a custom URB or a SCSI CDB, there isn’t any standard
to let you write an arbitrary taskfile right now. The SCSI-ATA
Translation project has some promise, but don’t hold your breath waiting
for it to get deployed everywhere. It’s going to be a while yet before
there is consistent support for it.
Phil
Philip D. Barila
Seagate Technology LLC
(720) 684-1842
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@cox.net
Sent: Tuesday, February 27, 2007 2:59 PM
To: “Windows System Software Devs Interest List”
Subject: RE:[ntdev] Vendor Unique Commands for USB Storage
Thank you all for your comments. I’ve been looking around to try and
figure out how the registers are mapped from the SCSI to the ATA
registers. My assumption is that this SCSI command is issued from the host
through the USB interface, but what gets written to the registers on the
ATA device?