TUSB9260 firmware: How to install an "MS OS feature descriptor" for a Microsoft compatible-ID for WinUSB driver

By the way, I'm not asking how to do MS os feature descriptors; it's just a matter of putting the proper descriptor data in the proper places in memory, and provide for the configuration endpoint to retrieve it for the USB host when requested.  The posts describe how to do that and we're competent programmers.

What we're asking is how one goes about inserting these new components into the TUSB9260 application firmware, and modifying whatever endpoint code may be necessary, since it's all supposed to be customizable.  Or if someone's already done it, even better.

Regards,

John

Hello John,

The TUSB9261 is an application specific device which main purpose is to be a USB to SATA bridge, thus the firmware provided by TI is intended for serving that purpose only. Normally the source code of the firmware is not provided by TI.

For which purpose are you using the TUSB9260 (application)? Could you explain with more detail about why your application requires WinUSB to interact with the TUSB9260? Perhaps we could provide a different approach/solution instead of using WinUSB.

What is the business opportunity of this?

Best Regards,

Alexis Cortes.

Thanks for your response, Alexis.

We're actually using the mass storage class protocol and the SATA interface; it's just that it's not for a generic drive in the OS.

I work for SerialTek, a small company in San Jose, and we make bus analyzers for SATA, SAS, and other drive interfaces.  We've incorporated the TUSB9260 into our current flagship model and it's doing well in sales channels, but it's not a huge volume kind of product.

We used the USB/SATA bridge chip because SATA is an interface we understand and already support in the instrument, it's high bandwidth to take advantage of USB 3.0 SS, and we have a lot of data to transfer.  It gave us a big leg up in development by satisfying our interface and bandwidth needs without requiring custom protocols on the instrument side or custom drivers on the PC side.  We've been accessing it as a physical block drive, but using a few proprietary commands to execute functions and prepare data transfers.  Though it's worked well, it's required the use of administrator mode and wasn't readily portable to Linux, which we support.

So we've implemented a libusb interface to the MSC device, which we have running now on several platforms.  It required minimal code to execute MSC/SCSI style commands (instead of the open/close/read/write physical drive commands) and we had it up and running in no time because of the resources in the library and in the WinUSB low-level driver it uses.  The only issue is getting the USB device to attach to the standard WinUSB driver in various flavors of Windows.  We have been working with INF files but there are constant complications with Windows insisting on attaching the device to the MSC driver.  We'd like the installation procedure to be as transparent as possible for our customers.

Then we discovered Microsoft Compatible-IDs and realized that if the USB descriptors responded as a WinUSB device, Windows 8 would automatically install the driver without an installation procedure, without an INF, without driver or INF signing, and would never complicate things with the MSC driver.  We just need the firmware to:

1.  Respond to the standard string descriptor index 0xEE request for "OS string descriptor" with the string of our specification.

2.  Respond to the "GET_MS_DESCRIPTOR" request with data from a new descriptor block which is the "Compatible-ID" descriptor. It's less than 100 bytes, most of it zeroed, a half-dozen or so simple fields, and three short string fields.  If space is constrained, at bare minimum it could be implemented in about 40 bytes.

Since you've already implemented several descriptors in the firmware and in your customization-flash tool, We figure this wouldn't be too difficult to add.  It may help others in the future who want to do a similar thing with high-bandwidth SATA data transfers in a custom device, or just want a custom, proprietary access from their application to their storage device without the labor of writing a driver from scratch or the headaches of custom driver installations, especially where customers are concerned.

Let me know if you need any other information.

Regards,

John

Can anyone provide an updated answer to this question? I assume at this point there has been some sample code release to demonstrate how to expose the various MS OS Descriptors supported by Windows. Can anyone provide a link of such a sample?