Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting... Please check out the Community Guidelines in the
Announcements and Administration Category.

Driver Details of USB3 Debugging

R0b0t1R0b0t1 Posts: 130
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

Comments

  • Tim_RobertsTim_Roberts Posts: 12,616
    On May 21, 2018, at 3:00 PM, xxxxx@gmail.com <xxxxx@lists.osr.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.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • R0b0t1R0b0t1 Posts: 130
    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 <xxxxx@lists.osr.com> wrote:
    > On May 21, 2018, at 3:00 PM, xxxxx@gmail.com <xxxxx@lists.osr.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://www.osronline.com/showlists.cfm?list=ntdev>;
    >
    > MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
    > Details at <http://www.osr.com/seminars>;
    >
    > To unsubscribe, visit the List Server section of OSR Online at <http://www.osronline.com/page.cfm?name=ListServer>;
  • Tim_RobertsTim_Roberts Posts: 12,616
    On May 21, 2018, at 10:22 PM, xxxxx@gmail.com <xxxxx@lists.osr.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.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • DianeDiane Posts: 12
    >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
    >
    > To unsubscribe, visit the List Server section of OSR Online at <
    > http://www.osronline.com/page.cfm?name=ListServer>;
    >
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!