Driver Problems? Questions? Issues?
Put OSR's experience to work for you! Contact us for assistance with:
  • Creating the right design for your requirements
  • Reviewing your existing driver code
  • Analyzing driver reliability/performance issues
  • Custom training mixed with consulting and focused directly on your specific areas of interest/concern.
Check us out. OSR, the Windows driver experts.

OSR Seminars


Go Back   OSR Online Lists > ntdev
Welcome, Guest
You must login to post to this list
  Message 1 of 5  
21 May 18 18:01
R0b0t1
xxxxxx@gmail.com
Join Date: 24 Mar 2017
Posts To This List: 108
Driver Details of USB3 Debugging

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 --
  Message 2 of 5  
22 May 18 00:46
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11955
Driver Details of USB3 Debugging

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.
  Message 3 of 5  
22 May 18 01:23
R0b0t1
xxxxxx@gmail.com
Join Date: 24 Mar 2017
Posts To This List: 108
Driver Details of USB3 Debugging

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. <...excess quoted lines suppressed...>
  Message 4 of 5  
22 May 18 02:14
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11955
Driver Details of USB3 Debugging

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.
  Message 5 of 5  
22 May 18 14:34
Diane
xxxxxx@gmail.com
Join Date: 03 Jan 2013
Posts To This List: 12
Driver Details of USB3 Debugging

>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 <xxxxx@lists.osr.com> wrote: > 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. > <...excess quoted lines suppressed...> --
Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You must login to OSR Online AND be a member of the ntdev list to be able to post.

All times are GMT -5. The time now is 23:38.


Copyright ©2015, OSR Open Systems Resources, Inc.
Based on vBulletin Copyright ©2000 - 2005, Jelsoft Enterprises Ltd.
Modified under license