OHCI + OTG

Hello All!

I have two general questions about OHCI/EHCI and OTG programming:

  1. Could you please recommend me some good sources revealing programming
    OHCI host controller’s chip and On-the-Go protocols for Windows XP/2003?
    Does MS provide some sources/samples for this issue?

  2. I’d like to play with the real OHCI/EHCI host controllers on my Windows
    machine (even inside the VMware) until I receive a real hardware. Is it a
    stupid idea? How to properly disable standard Windows EHCI host controller’s
    driver and USBD to play with this hardware on my own?

Many thanks,

Mike

xxxxx@pigeonpoint.com wrote:

I have two general questions about OHCI/EHCI and OTG programming:

  1. Could you please recommend me some good sources revealing
    programming OHCI host controller’s chip and On-the-Go protocols for
    Windows XP/2003? Does MS provide some sources/samples for this issue?

I have never encountered a motherboard USB controller that supported
OTG. Almost without exception, OTG support is only available in chips
targeted at the embedded processor market.

  1. I’d like to play with the real OHCI/EHCI host controllers on my
    Windows machine (even inside the VMware) until I receive a real
    hardware. Is it a stupid idea? How to properly disable standard
    Windows EHCI host controller’s driver and USBD to play with this
    hardware on my own?

You can certainly disable the host controller device in device manager
and handle it yourself, but EHCI is an absurdly complicated spec. This
is not something you are going to “play with”.


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

It’s very rare for anybody to have to write a USB Host Controller Driver, right? The only people who need to do this are people who (a) Are trying to support a new operating system, (b) Are trying to support a new controller on an existing operating system… think XHCI here.

As Tim said, EHCI is a monstrously annoying specification. OTOH, the good news is that you can write an OHCI controller driver for an existing USB V2.0 Host Controller and just IGNORE EHCI… because every EHCI includes (multiple) OHCI or UHCI devices.

Soooooooooo… tell us more about what you’re really looking to do, and maybe we can help you.

Peter
OSR

Hi Peter, Tim!

Thank you for the response!
I need to design and develop an OHCI driver for a proprietary chip. I didn’t
do this before and you are correct saying that this chance happens rather
rarely. I’ve learned the appropriate USB/OHCI/OTG specs and now I’m looking
for a possibility to play with the real hardware. This should be done for
Windows XP and this is why I’m concerned about Windows (even there are nice
sources for Linux).
And I need somebody’s advice on this issue, somebody who already worked on
this topic closely.

Thanks, regards!
Mike

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Monday, November 09, 2009 10:33 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] OHCI + OTG

It’s very rare for anybody to have to write a USB Host Controller Driver,
right? The only people who need to do this are people who (a) Are trying to
support a new operating system, (b) Are trying to support a new controller
on an existing operating system… think XHCI here.

As Tim said, EHCI is a monstrously annoying specification. OTOH, the good
news is that you can write an OHCI controller driver for an existing USB
V2.0 Host Controller and just IGNORE EHCI… because every EHCI includes
(multiple) OHCI or UHCI devices.

Soooooooooo… tell us more about what you’re really looking to do, and
maybe we can help you.

Peter
OSR


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

Hey Mike,

I’m still have trouble understanding what you need to do… but in any case, let me make a few observations:

a) Like Tim said, you can play with any system that has an OHCI in it, just by substituting your driver for the Windows OHCI driver in device manager. Start by disabling the Windwos OHCI driver (ON ALL THE OHCI CONTROLLERS).

b) You said you’re developing “an OHCI driver for a proprietary chip” – If the interface is OHCI and identifies as an OHCI HCD, and you try to bring-up this device on Windows then it’ll be claimed by the standard Windows OHCI driver by default, right?

Personally, I’ve done a UHCI HCD but not an OHCI (looked at it, rather similar). The troubles *I* ran into were (a) the differences between what the docs say you CAN do, and the SPECIFIC way Windows does things… existing devices that interface with USB often test with Windows and expect the HCD to act just like Windows acts, regardless of what the USB spec says, (b) dealing with legacy issues, hardware bugs, interfacing with the BIOS during boot, and (for me) general ICH-dependent annoyances. I mean, how many people have written a UHCI (in my case) or OHCI (in your case) HCD that’s suppose to work on a system that doesn’t have a working EHCI?

Hope that helps a bit,

Peter
OSR

wrote in message news:xxxxx@ntdev…
>
> I have two general questions about OHCI/EHCI and OTG programming:
>
> 1. Could you please recommend me some good sources revealing programming
> OHCI host controller’s chip and On-the-Go protocols for Windows XP/2003?
> Does MS provide some sources/samples for this issue?

IIRC, the only bit of wisdom revealed by MS on the OTG was that no shipping
Windows
version supports OTG in device (slave) mode.
Even if the controller is OTG capable, Windows always is the host.

Regards,
–pa

Hi Peter, see my comment below.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Tuesday, November 10, 2009 12:44 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] OHCI + OTG

Hey Mike,

I’m still have trouble understanding what you need to do… but in any case,
let me make a few observations:

a) Like Tim said, you can play with any system that has an OHCI in it, just
by substituting your driver for the Windows OHCI driver in device manager.
Start by disabling the Windwos OHCI driver (ON ALL THE OHCI CONTROLLERS).

MA I’m going to use this way.

b) You said you’re developing “an OHCI driver for a proprietary chip” – If
the interface is OHCI and identifies as an OHCI HCD, and you try to bring-up
this device on Windows then it’ll be claimed by the standard Windows OHCI
driver by default, right?

MA Right.

Personally, I’ve done a UHCI HCD but not an OHCI (looked at it, rather
similar). The troubles *I* ran into were (a) the differences between what
the docs say you CAN do, and the SPECIFIC way Windows does things…
existing devices that interface with USB often test with Windows and expect
the HCD to act just like Windows acts, regardless of what the USB spec says,
(b) dealing with legacy issues, hardware bugs, interfacing with the BIOS
during boot, and (for me) general ICH-dependent annoyances. I mean, how
many people have written a UHCI (in my case) or OHCI (in your case) HCD
that’s suppose to work on a system that doesn’t have a working EHCI?

Hope that helps a bit,

MA You are correct here, OHCI is simpler then UHCI but this fact doesn’t
help me much =) Anyway thank you for the help!

Peter
OSR


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

Mike wrote:

b) You said you’re developing “an OHCI driver for a proprietary chip” – If
the interface is OHCI and identifies as an OHCI HCD, and you try to bring-up
this device on Windows then it’ll be claimed by the standard Windows OHCI
driver by default, right?

MA Right.

MA You are correct here, OHCI is simpler then UHCI but this fact doesn’t
help me much =) Anyway thank you for the help!

Right. I’m not sure you’re really aware of what you’re up against here.

OHCI is a standard. All OHCI controllers are proprietary chips, but
because they follow the standard, Microsoft can write a single OCHI host
controller driver that drives them all. As long as you follow the
standard, nothing else is required of you. No coding, no driver,
nothing. It just plugs and plays. That’s what standards are for. If
you need a custom driver for your device to work, then it’s not really OHCI.

As for OTG, that’s another kettle of fish entirely. With host
controllers, at least there is an infrastructure in place. Even if you
have to write your own host controller driver, the rest of the operating
system knows how to handle power management and device node creation and
driver assignment and IRP communication, etc. That’s all present.
However, there is absolutely no pre-existing infrastructure that allows
a Windows operating system to act as a USB device. There’s simply
nothing in the kernel model to support it. You will be starting
completely from scratch, and that’s a very lonely place to be.

Windows CE can do it, as can Linux. What is it that you are actually
planning to build here?


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