Hello,
Is anyone at liberty to discuss how Windows uses USB3 hardware to allow
itself to be debugged? I am interested in using a PC USB3 controller in
device mode. The interface is very high bandwidth but also very common.
If most XHCI controllers support device mode do previous versions as well?
Is this functionality just not well documented?
How the debugging protocol interfaces with the kernel is probably secret
and not what I am after.
Cheers,
R0b0t1
On May 21, 2018, at 3:00 PM, xxxxx@gmail.com wrote:
>
> Is anyone at liberty to discuss how Windows uses USB3 hardware to allow itself to be debugged?
That’s called the “debug capability” (DbC), and it’s part of the XHCI specification. There are no secrets there, but it’s not useful for any other purpose.
> I am interested in using a PC USB3 controller in device mode. The interface is very high bandwidth but also very common.
Your PC’s XHCI controller cannot be placed into device mode. It is always a host. For kernel debugging, the secret sauce is a special cable that acts like a device on both ends.
Some smaller devices support an ability called “USB OTG” (“On The Go”) that can negotiate a switch between host mode and device mode. Windows Desktop doesn’t support that.
> If most XHCI controllers support device mode do previous versions as well? Is this functionality just not well documented?
Very few USB controllers in desktop machines support device mode. The USB controllers in tablets often do.
> How the debugging protocol interfaces with the kernel is probably secret and not what I am after.
Not really a secret, but not very interesting. It’s the same protocol used over serial and Ethernet.
—
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Thanks for the clarification. I missed the part talking about the
special cable. Luckily I didn’t waste any time trying to debug with a
normal A to A cable.
I am still suprised this trick is being used. Are you able to clarify
how each controller acts like a host? I suppose I can understand
having no software mediated crossover, but there are other parts of
the protocol that I do not think would work over a special cable.
Having read some of the spec it looks like they only implemented a
very limited new protocol. I find this odd. I would have expected USB
IP to be reused more than it is, and for USB OTG IP blocks to have
been modified for use in computers proper.
On Mon, May 21, 2018 at 11:45 PM, xxxxx@probo.com wrote:
> On May 21, 2018, at 3:00 PM, xxxxx@gmail.com wrote:
>>
>> Is anyone at liberty to discuss how Windows uses USB3 hardware to allow itself to be debugged?
>
> That’s called the “debug capability” (DbC), and it’s part of the XHCI specification. There are no secrets there, but it’s not useful for any other purpose.
>
>
>> I am interested in using a PC USB3 controller in device mode. The interface is very high bandwidth but also very common.
>
> Your PC’s XHCI controller cannot be placed into device mode. It is always a host. For kernel debugging, the secret sauce is a special cable that acts like a device on both ends.
>
> Some smaller devices support an ability called “USB OTG” (“On The Go”) that can negotiate a switch between host mode and device mode. Windows Desktop doesn’t support that.
>
>
>> If most XHCI controllers support device mode do previous versions as well? Is this functionality just not well documented?
>
> Very few USB controllers in desktop machines support device mode. The USB controllers in tablets often do.
>
>
>> How the debugging protocol interfaces with the kernel is probably secret and not what I am after.
>
> Not really a secret, but not very interesting. It’s the same protocol used over serial and Ethernet.
> —
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:
>
> 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:</http:></http:></http:>
On May 21, 2018, at 10:22 PM, xxxxx@gmail.com wrote:
>
> Thanks for the clarification. I missed the part talking about the
> special cable. Luckily I didn’t waste any time trying to debug with a
> normal A to A cable.
Well, an A to A cable is not really “normal”. I don’t know what you’d use that for.
> I am still suprised this trick is being used. Are you able to clarify
> how each controller acts like a host?
The two hosts are not electrically connected. The “special sauce” cable has two USB interface chips and a microcontroller that passes data back and forth. Software on the two PCs probably negotiates their own protocol that ends up with one side being a master, but in USB terms, both ends are devices.
> I suppose I can understand having no software mediated crossover, but there are other parts of
> the protocol that I do not think would work over a special cable.
Oh, there is software involved. There’s a processor inside that cable that interface between the two buses, buffering and forwarding packets.
There was a USB debug capability added to EHCI, but it was more or less an afterthought. It never really worked very well, and it was not universally implemented.
> Having read some of the spec it looks like they only implemented a
> very limited new protocol. I find this odd. I would have expected USB
> IP to be reused more than it is, and for USB OTG IP blocks to have
> been modified for use in computers proper.
Interesting point. It’s not trivial to figure out how to incorporate OTG into full Windows. It doesn’t fit well with the driver model. Perhaps it was easier to port the hacked in EHCI debug capability into XHCI.
—
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
>Your PC’s XHCI controller cannot be placed into device mode. It is always
a host. For kernel debugging, the secret sauce is a special cable that
acts like a device on both ends.
The A-A cable for USB3 debug does not have a device embedded. If you look
at section 7.6 of the xHCI spec, it describes requirements for a host DbC
port to look like a device and respond accordingly. This lets the A-A
cables be very inexpensive.
Regards,
Diane
On Mon, May 21, 2018 at 11:14 PM xxxxx@probo.com wrote:
> On May 21, 2018, at 10:22 PM, xxxxx@gmail.com
> wrote:
> >
> > Thanks for the clarification. I missed the part talking about the
> > special cable. Luckily I didn’t waste any time trying to debug with a
> > normal A to A cable.
>
> Well, an A to A cable is not really “normal”. I don’t know what you’d use
> that for.
>
>
> > I am still suprised this trick is being used. Are you able to clarify
> > how each controller acts like a host?
>
> The two hosts are not electrically connected. The “special sauce” cable
> has two USB interface chips and a microcontroller that passes data back and
> forth. Software on the two PCs probably negotiates their own protocol that
> ends up with one side being a master, but in USB terms, both ends are
> devices.
>
>
> > I suppose I can understand having no software mediated crossover, but
> there are other parts of
> > the protocol that I do not think would work over a special cable.
>
> Oh, there is software involved. There’s a processor inside that cable
> that interface between the two buses, buffering and forwarding packets.
>
> There was a USB debug capability added to EHCI, but it was more or less an
> afterthought. It never really worked very well, and it was not universally
> implemented.
>
> > Having read some of the spec it looks like they only implemented a
> > very limited new protocol. I find this odd. I would have expected USB
> > IP to be reused more than it is, and for USB OTG IP blocks to have
> > been modified for use in computers proper.
>
> Interesting point. It’s not trivial to figure out how to incorporate OTG
> into full Windows. It doesn’t fit well with the driver model. Perhaps it
> was easier to port the hacked in EHCI debug capability into XHCI.
> —
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: <
> http://www.osronline.com/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:>