develop my own xHCI host controller driver

NTDEV
1

hi, all experts:

I want to develop my own xHCI USB host controller driver.
Before I have experience of USB device, Video capture experience windows driver developing.

But very little of PCI/PCIe experience.

I want to develop my own xHCI USB host controller driver.

I need the following advice:

  1. a framework of this driver,
    I think it is a PCIe WDM driver, where can I find a framework to start this work?

  2. now I have experience of xHCI SPEC, but very little about EHCI, UHCI, or OHCI spec,
    because xHCI replace all the other HCI, should i take other HCI into account or not?

  3. I have Linux code on hand, and also, I have experience to port the linux code to ARM bare mental code to debug my own xHCI IPs,

Can I using the code/data structures from Linux to develop my windows xHCI driver?

  1. should I using WDM or WDF?
    I am familiar with WDM, but not WDF, should I develop xhci by which one?
    I prefer to WDM,
    WDF in my opinion, is not easy to modify,

  2. any other tips you experts can give?

  3. You may ask, Win8 have its native xHCI driver, why should I develop my own?
    I will give you reply, to debug my own xHCI IPs and it is an interesting to write a xHCI driver, which will enhance my windows driver, PCI/PCIe and xHCI understandings.

  4. in the future, I will develop my own UAS( usb attach scsi driver), next step, also it also support by Win8

  5. I am familiar about xHCI spec, but I sill need your advice about the steps of developing a xHCI driver,
    for my experience, my steps focusing on
    first, PCIe frameswroks, interrupts(MSI, or MSI-X)
    then, MMIO xHCI registers accessing
    then, data structures of xHCI, can borrow from Linux
    then, four types transfer, control, bulk, that is asyc then periodic interrupt and iso
    then optimizing.

any other advices.

hope for you advices.

regards,
Wesley.

2

PCI(e) is simple for your purpose. KMDF is easy. xHCI is manageable. Your
biggest problem is you don’t have access to spec for interfacing HCI and
hub – the HCI miniport driver I/F spec.

Other companies did it by:

  1. reverse engineering
  2. working with MSFT to get the HCI miniport spec.

Come on, life is so short, I’m sure you will find other more interesting
things to do than this unless someone pays you a hefty check to do so.

Calvin
On Tue, Nov 6, 2012 at 9:43 PM, wrote:

> hi, all experts:
>
> I want to develop my own xHCI USB host controller driver.
> Before I have experience of USB device, Video capture experience windows
> driver developing.
>
> But very little of PCI/PCIe experience.
>
> I want to develop my own xHCI USB host controller driver.
>
> I need the following advice:
> 1. a framework of this driver,
> I think it is a PCIe WDM driver, where can I find a framework to start
> this work?
>
> 2. now I have experience of xHCI SPEC, but very little about EHCI, UHCI,
> or OHCI spec,
> because xHCI replace all the other HCI, should i take other HCI into
> account or not?
>
> 3. I have Linux code on hand, and also, I have experience to port the
> linux code to ARM bare mental code to debug my own xHCI IPs,
>
> Can I using the code/data structures from Linux to develop my windows
> xHCI driver?
>
> 4. should I using WDM or WDF?
> I am familiar with WDM, but not WDF, should I develop xhci by which one?
> I prefer to WDM,
> WDF in my opinion, is not easy to modify,
>
> 5. any other tips you experts can give?
>
> 6. You may ask, Win8 have its native xHCI driver, why should I develop my
> own?
> I will give you reply, to debug my own xHCI IPs and it is an interesting
> to write a xHCI driver, which will enhance my windows driver, PCI/PCIe and
> xHCI understandings.
>
> 7. in the future, I will develop my own UAS( usb attach scsi driver), next
> step, also it also support by Win8
>
> 9. I am familiar about xHCI spec, but I sill need your advice about the
> steps of developing a xHCI driver,
> for my experience, my steps focusing on
> first, PCIe frameswroks, interrupts(MSI, or MSI-X)
> then, MMIO xHCI registers accessing
> then, data structures of xHCI, can borrow from Linux
> then, four types transfer, control, bulk, that is asyc then periodic
> interrupt and iso
> then optimizing.
>
> any other advices.
>
> hope for you advices.
>
> regards,
> Wesley.
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

3

haha

thank you, Calvin.

PCI(e) is simple for your purpose.
i have no experience of PCIe, any sample source code?

Your biggest problem is you don’t have access to spec for interfacing HCI and
hub – the HCI miniport driver I/F spec.
Sorry, I am not very clear about your original meaning.
xHCI is an interface, which list the registers and their address, why can’t we access it?
There are lots of third part driver supplier, such as MCCI, or NEC has its own xHCI driver, just according to xHCI spec.
For Hub, i think I can also mimic Linux code.

4

If you want to enumerate and load MSFT class drivers and third party client drivers this is a huge task, esp your own hub. If you don’t care about client drivers, it is simpler. Yes, those companies have released drivers after many many man years of development with development teams, not one individual

d

debt from my phone

From: workingmailing@163.com
Sent: 11/6/2012 10:20 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] develop my own xHCI host controller driver

haha

thank you, Calvin.

PCI(e) is simple for your purpose.
i have no experience of PCIe, any sample source code?

Your biggest problem is you don’t have access to spec for interfacing HCI and
hub – the HCI miniport driver I/F spec.
Sorry, I am not very clear about your original meaning.
xHCI is an interface, which list the registers and their address, why can’t we access it?
There are lots of third part driver supplier, such as MCCI, or NEC has its own xHCI driver, just according to xHCI spec.
For Hub, i think I can also mimic Linux code.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

5

in my experience.

Windows driver is stacked.

Such as device driver, class driver, USBDI, xHCD, the stack loading and unloading is OS manager’s responsibility but not one single driver’s.

Am I wrong on this concept?

6

I don’t think you’re familiar enough with Windows to understand what Mr. Guan and Mr. Holan have said.

Think about how the xhci stack works: The xhci Host Controller Driver (the HCD) does the work of talking to the controller – this is the smaller part of the problem. You can put together a prototype proof of concept of this thing with some knowledge of the spec and some effort.

Node that while the HCD enumerates root hubs, it’s the hubs that actually enumerate devices. The interesting part is in the clever and proprietary way in which the HUB driver and the HCD interact. That’s why the answer to:

Is “Well, no… not so much.”

And that’s why when you say

It’s clear you don’t fully understand the challenge involved.

Build your own xhci driver? If you’ll be content to support just one or two devices, the drivers for which you write yourself, as a demo/proof of concept… then you can do this. If you want to make a set of drivers that actually WORK in the general case… forget it.

Just so we’re clear that I’m not just guessing: I’ve written, from scratch, drivers for both an HCD and USB Hub that were intended to be “for general use” in a research operating system. Writing the HCD was amusing, and I wish that I had more time to “do it right” as opposed to “getting something done for this code sprint”, but that’s another story. Writing the Hub driver was mostly a pain in the ass… and I didn’t learn much, well, except for the fact that writing a USB Hub driver is mostly a pain in the ass.

Peter
OSR

7

that’s right.

When I port the Linux xHCI and hub code to ARM based bare metal code, hub parts is the most confusing one.

And I think now I have understand what you and others’ opinion:

  1. in order to interact with class drivers and device drivers, the USB3 root hub or external hub drivers need to supply the same interface as what MSFT do.
    Just as USBDI supply the interface listed in WDK helps, hub driver should also supply this list for USBDI to invoke.

But I was figure, can we just use “IoCallDriver” to pass request from one stack to another lower stack, it is my original thinking.
USB hub driver Iocalldriver to call xHCI driver.

MCCI supply very detail interface of its xHCD driver, and Can I mimic it?

  1. should xHCD and USB3 hub driver both act as bus driver to enumerate PDOs on it?
8

workingmailing@163.com wrote:

And I think now I have understand what you and others’ opinion:

  1. in order to interact with class drivers and device drivers, the USB3 root hub or external hub drivers need to supply the same interface as what MSFT do.
    Just as USBDI supply the interface listed in WDK helps, hub driver should also supply this list for USBDI to invoke.

But I was figure, can we just use “IoCallDriver” to pass request from one stack to another lower stack, it is my original thinking.
USB hub driver Iocalldriver to call xHCI driver.

Well, yes, that’s how drivers always communicate. However, there are
also private interfaces, using IRP_MN_QUERY_INTERFACE, where two drivers
exchange a set of function pointers. I’m not convinced the private
interfaces between Microsoft’s HCD and Microsoft’s hub driver are all
fully documented.

MCCI supply very detail interface of its xHCD driver, and Can I mimic it?

  1. should xHCD and USB3 hub driver both act as bus driver to enumerate PDOs on it?

Of course. The HCD has to create PDOs for the hub devices. That’s how
the hub drivers get loaded.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

9

The interfaces between the hub and HCI driver are not fully documented.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Thursday, November 8, 2012 10:34 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] develop my own xHCI host controller driver

workingmailing@163.com wrote:

And I think now I have understand what you and others’ opinion:

  1. in order to interact with class drivers and device drivers, the USB3 root hub or external hub drivers need to supply the same interface as what MSFT do.
    Just as USBDI supply the interface listed in WDK helps, hub driver should also supply this list for USBDI to invoke.

But I was figure, can we just use “IoCallDriver” to pass request from one stack to another lower stack, it is my original thinking.
USB hub driver Iocalldriver to call xHCI driver.

Well, yes, that’s how drivers always communicate. However, there are also private interfaces, using IRP_MN_QUERY_INTERFACE, where two drivers exchange a set of function pointers. I’m not convinced the private interfaces between Microsoft’s HCD and Microsoft’s hub driver are all fully documented.

MCCI supply very detail interface of its xHCD driver, and Can I mimic it?

  1. should xHCD and USB3 hub driver both act as bus driver to enumerate PDOs on it?

Of course. The HCD has to create PDOs for the hub devices. That’s how the hub drivers get loaded.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

10

I would have thought what I said previously was abundantly clear:


Note that while the HCD enumerates root hubs, it’s the hubs that actually
enumerate devices. The interesting part is in the clever and proprietary way in
which the HUB driver and the HCD interact.

Apparently what I said was not clear to the OP. I find this a lot in this forum. I clearly have work to do in terms of my communication skills.

Peter
OSR