Hi experts
I need to develop a virtual host controller driver. I have found several similar projects like USBIP, but their codes for windows side is quite not enough.
I have experience about developing a bus driver(toaster), but I’m a newbie about USB driver.The most of samples in WDK is USB device driver not host or root hub.
Could you please give me some advice or document about how to develop a host controller driver?
Thank u all
These are seriously complicated drivers.
IF you want an idea of how complicated, take a look at some code from Linux (like the OTG driver from Synopsys). The host side of that is very big, very fiddly, but will give you an idea of what you will have to do.
Of course such a driver is hardware specific, and for each the register map will vary (it is a PCI driver in fact) so sample code wont help you here.
There is an open source usb controller driver for the xen hypervisor.in the
open source version of xen pv drives developed by James Harper, here
http://xenbits.xensource.com/ext/win-pvdrivers/. It looks like no work has
been done since 2014. It might give you some clues as to how complicated
this is.
Mark Roddy
On Wed, May 3, 2017 at 11:40 PM, wrote:
> Hi experts
> I need to develop a virtual host controller driver. I have found several
> similar projects like USBIP, but their codes for windows side is quite not
> enough.
> I have experience about developing a bus driver(toaster), but I’m a
> newbie about USB driver.The most of samples in WDK is USB device driver not
> host or root hub.
> Could you please give me some advice or document about how to develop a
> host controller driver?
> Thank u all
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer>
></http:></http:>
You might also take a look at this information from Microsoft: https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/developing-windows-drivers-for-usb-host-controllers
If you can implement the driver using their UCX framework it would simplify task quite a bit.
To reiterate what others have said, writing a USB host driver is very challenging.
Is this driver going into a production environment? Does it need to support all the existing USB devices?
Something you may not have planned or scheduled for is device compatibility testing. Even if your driver follows all the appropriate specs, you are going to run into a lot of devices that don’t work and need special workarounds.
I can tell you from personal experience that task is never complete, there is always one more strange device out there!
This is the most memorable issue I have seen.
During compatibility testing of our host controller, customer found a mouse that didn’t work. After getting a hold of this mouse, shipped in from asia, I took some usb traces to see what was happening. Not seeing anything obvious in the trace, I took a trace of the mouse on an EHCI port where it worked fine. The two traces looked the same until the point at which in the failing case the mouse just stopped responding. After much experimentation and naval gazing I finally discovered that this mouse expected specific USB control requests in a specific order. In the MSFT stack that was a get report descriptor request that happened during enumeration. If the mouse didn’t see what it was expecting then it would just hang.
The workaround? Detect this particular VID/PID and insert the needed get report descriptor request at the appropriate time in the enumeration sequence.
Eric
Yes UCX should help smooth out the massively undocumented aspects of the
architecture. And I concur on the horror stories the developer will
experience trying to attain equivalency to an in-box experience. Expect
around 2 years of development to get to something roughly equivalent. How
UCX affects that effort is unknown to me as I did all my work prior to its
existence.
Also you need a usb analyzer, real one, not some software only thing.
Mark Roddy
On Thu, May 4, 2017 at 5:23 PM, wrote:
> You might also take a look at this information from Microsoft:
> https://docs.microsoft.com/en-us/windows-hardware/drivers/
> usbcon/developing-windows-drivers-for-usb-host-controllers
> If you can implement the driver using their UCX framework it would
> simplify task quite a bit.
>
> To reiterate what others have said, writing a USB host driver is very
> challenging.
> Is this driver going into a production environment? Does it need to
> support all the existing USB devices?
> Something you may not have planned or scheduled for is device
> compatibility testing. Even if your driver follows all the appropriate
> specs, you are going to run into a lot of devices that don’t work and need
> special workarounds.
> I can tell you from personal experience that task is never complete, there
> is always one more strange device out there!
>
>
> This is the most memorable issue I have seen.
> During compatibility testing of our host controller, customer found a
> mouse that didn’t work. After getting a hold of this mouse, shipped in
> from asia, I took some usb traces to see what was happening. Not seeing
> anything obvious in the trace, I took a trace of the mouse on an EHCI port
> where it worked fine. The two traces looked the same until the point at
> which in the failing case the mouse just stopped responding. After much
> experimentation and naval gazing I finally discovered that this mouse
> expected specific USB control requests in a specific order. In the MSFT
> stack that was a get report descriptor request that happened during
> enumeration. If the mouse didn’t see what it was expecting then it would
> just hang.
> The workaround? Detect this particular VID/PID and insert the needed get
> report descriptor request at the appropriate time in the enumeration
> sequence.
>
> Eric
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer>
></http:></http:>
Thank you for our information.
It looks like UCX is my best choice, even through it doesn’t support windows 7.
@Eric, had exactly the same issue on a Broadcom BSP USB device with WIndows 10, due to the change in the way windows 10 enumerated a device it failed. Digging into the linux code for it it was clear the state machine was very rigid.
Re UCX, is this working? I tried to use the UFX interface recently and didnt get very far with it. (Seems ot be intentionally disabled oin windows 10 IoT),
Great points in this thread.
While we were praising the USB spec in another thread as a model of clarity and usefulness, it’s absolutely true that there’s another level of controller compatibility over and above the spec.
It can really be maddening. It all comes down to needing to create host controller/hub drivers that “do what the in-box Windows drivers do.” And, as Mr. Roddy said, this requires a good USB analyzer. What I often resorted to what monitoring how Windows enumerated a given device and then replicating that behavior.
P
And as Eric pointed out the vageries of USB host hardware are wide and manifest.
I spent a lot of time working on the Linux OTG driver for the Synopsys DWC core. It is very buggy hardware, very timing dependant, and on any kind of power up needs many resets to function correctly. Not to mention causing interrupt storms when FS devices were connected. That was a fiddly one to fix.
And then you have to deal with split transactions…
It is one big horror story, and without very good support from the host vendor I wouldnt attempt it myself, because you are going to need it.