I wanted to know which physical port of my multiple USB controllers have the debug capability. There was no way to find that easily, so I created a tool which will do most of the work for the user.
Example output: The following PCI devices support a USB debug port (says lspci): 0000:00:1d.7 The following PCI devices support a USB debug port (says the kernel): 0000:00:1d.7 PCI device 0000:00:1d.7, USB bus 3, USB physical port 1 Currently connected high-speed devices: /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/6p, 480M |__ Port 2: Dev 20, If 0, Class=stor., Driver=usb-storage, 480M
The output can be improved, but it's a good start.
Regards, Carl-Daniel
On Tue, 09 Sep 2008 03:31:00 +0200, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
I wanted to know which physical port of my multiple USB controllers have the debug capability. There was no way to find that easily, so I created a tool which will do most of the work for the user.
Example output: The following PCI devices support a USB debug port (says lspci): 0000:00:1d.7 The following PCI devices support a USB debug port (says the kernel): 0000:00:1d.7 PCI device 0000:00:1d.7, USB bus 3, USB physical port 1 Currently connected high-speed devices: /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/6p, 480M |__ Port 2: Dev 20, If 0, Class=stor., Driver=usb-storage, 480M
The output can be improved, but it's a good start.
Doesn't lspci -vvv tell you? It does for me on the ICH4
00:1d.7 USB Controller: Intel Corp. 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 02) (prog-if 20 [EHCI]) Subsystem: Unknown device bc8a:4610 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin D routed to IRQ 11 Region 0: Memory at feb7fc00 (32-bit, non-prefetchable) [size=1K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] Debug port
On Mon, Sep 8, 2008 at 9:48 PM, Joseph Smith joe@settoplinux.org wrote:
On Tue, 09 Sep 2008 03:31:00 +0200, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
I wanted to know which physical port of my multiple USB controllers have the debug capability. There was no way to find that easily, so I created a tool which will do most of the work for the user.
Example output: The following PCI devices support a USB debug port (says lspci): 0000:00:1d.7 The following PCI devices support a USB debug port (says the kernel): 0000:00:1d.7 PCI device 0000:00:1d.7, USB bus 3, USB physical port 1 Currently connected high-speed devices: /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/6p, 480M |__ Port 2: Dev 20, If 0, Class=stor., Driver=usb-storage, 480M
The output can be improved, but it's a good start.
Doesn't lspci -vvv tell you? It does for me on the ICH4
00:1d.7 USB Controller: Intel Corp. 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 02) (prog-if 20 [EHCI]) Subsystem: Unknown device bc8a:4610 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin D routed to IRQ 11 Region 0: Memory at feb7fc00 (32-bit, non-prefetchable) [size=1K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] Debug port
But IIRC, only the first port on the controller works as a debug port, and Carl-Daniel's program will let you figure out exactly which port that is, by swapping a USB device between the two ports. Right?
-Corey
On 09.09.2008 03:53, Corey Osgood wrote:
On Mon, Sep 8, 2008 at 9:48 PM, Joseph Smith joe@settoplinux.org wrote:
On Tue, 09 Sep 2008 03:31:00 +0200, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
I wanted to know which physical port of my multiple USB controllers have the debug capability. There was no way to find that easily, so I created a tool which will do most of the work for the user.
Example output: The following PCI devices support a USB debug port (says lspci): 0000:00:1d.7 The following PCI devices support a USB debug port (says the kernel): 0000:00:1d.7 PCI device 0000:00:1d.7, USB bus 3, USB physical port 1 Currently connected high-speed devices: /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/6p, 480M |__ Port 2: Dev 20, If 0, Class=stor., Driver=usb-storage, 480M
The output can be improved, but it's a good start.
Doesn't lspci -vvv tell you? It does for me on the ICH4
00:1d.7 USB Controller: Intel Corp. 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 02) (prog-if 20 [EHCI]) Subsystem: Unknown device bc8a:4610 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin D routed to IRQ 11 Region 0: Memory at feb7fc00 (32-bit, non-prefetchable) [size=1K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] Debug port
But IIRC, only the first port on the controller works as a debug port, and Carl-Daniel's program will let you figure out exactly which port that is, by swapping a USB device between the two ports. Right?
Yes. However, that "first port" limitation does not exist, so you need to retrieve the number of the debug port. And for multiple USB controllers locating the right physical port is downright exhausting.
I'd be interested in the output of my script on your machines and whether it helped you find the right physical port.
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
whether it helped you find the right physical port.
Difficult to verify.
//Peter
I'd be interested in the output of my script on your machines and whether it helped you find the right physical port.
Well it maybe helpfull for someone that has a bunch of physical ports, but my boards only have two physical ports and I already know which one is the debug port/first port. But I could run it for you if you want me to...
On 09.09.2008 04:23, Joseph Smith wrote:
I'd be interested in the output of my script on your machines and whether it helped you find the right physical port.
Well it maybe helpfull for someone that has a bunch of physical ports, but my boards only have two physical ports and I already know which one is the debug port/first port. But I could run it for you if you want me to...
That would be nice. Although the script was mainly written to find the two debug ports on my machine with 14 ports, I hope it is useful for smaller machines.
By the way, do you have a debug cable?
Regards, Carl-Daniel
On 09.09.2008 03:31, Carl-Daniel Hailfinger wrote:
I wanted to know which physical ports of my multiple USB controllers have the debug capability. There was no way to find that easily, so I created a tool which will do most of the work for the user.
Example output: The following PCI devices support a USB debug port (says lspci): 0000:00:1d.7 The following PCI devices support a USB debug port (says the kernel): 0000:00:1d.7 PCI device 0000:00:1d.7, USB bus 3, USB physical port 1 Currently connected high-speed devices: /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/6p, 480M |__ Port 2: Dev 20, If 0, Class=stor., Driver=usb-storage, 480M
The output can be improved, but it's a good start.
Updated version attached. This one works with slightly older lspci versions as well and fixes one bug with multiple cards.
Regards, Carl-Daniel
On Tue, 09 Sep 2008 14:58:02 +0200, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 09.09.2008 04:23, Joseph Smith wrote:
I'd be interested in the output of my script on your machines and whether it helped you find the right physical port.
Well it maybe helpfull for someone that has a bunch of physical ports,
but
my boards only have two physical ports and I already know which one is
the
debug port/first port. But I could run it for you if you want me to...
That would be nice. Although the script was mainly written to find the two debug ports on my machine with 14 ports, I hope it is useful for smaller machines.
By the way, do you have a debug cable?
No, that is a sore subject with me... Remember I wanted to build one, and I got shot down for that...
I still can't justify the price, when a serial cable works just as good.
On Tue, 09 Sep 2008 14:58:02 +0200, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 09.09.2008 04:23, Joseph Smith wrote:
I'd be interested in the output of my script on your machines and whether it helped you find the right physical port.
Well it maybe helpfull for someone that has a bunch of physical ports,
but
my boards only have two physical ports and I already know which one is
the
debug port/first port. But I could run it for you if you want me to...
That would be nice.
Will do.
Although the script was mainly written to find the two debug ports on my machine with 14 ports, I hope it is useful for smaller machines.
14 ports?? You must have a USB machine from hell :-) Cables running every which way :-)
On 09.09.2008 19:16, Joseph Smith wrote:
On Tue, 09 Sep 2008 14:58:02 +0200, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 09.09.2008 04:23, Joseph Smith wrote:
I'd be interested in the output of my script on your machines and whether it helped you find the right physical port.
Well it maybe helpfull for someone that has a bunch of physical ports,
but
my boards only have two physical ports and I already know which one is
the
debug port/first port. But I could run it for you if you want me to...
That would be nice. Although the script was mainly written to find the two debug ports on my machine with 14 ports, I hope it is useful for smaller machines.
By the way, do you have a debug cable?
No, that is a sore subject with me... Remember I wanted to build one, and I got shot down for that...
Yes, I remember that discussion. The main point was that parts+shipping would be almost the current net20dc price+shipping. My apologies if you felt shot down, that surely was not intentional.
I still can't justify the price, when a serial cable works just as good.
Same here. I still hope we can somehow abuse the Geode CS5536 chip to act as a debug device. That would probably be cheaper than building a NET20DC from scratch, especially because Geode based boards can be had rather cheap on ebay.
Regards, Carl-Daniel
On 09.09.2008 19:23, Joseph Smith wrote:
On Tue, 09 Sep 2008 14:58:02 +0200, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 09.09.2008 04:23, Joseph Smith wrote:
I'd be interested in the output of my script on your machines and whether it helped you find the right physical port.
Well it maybe helpfull for someone that has a bunch of physical ports, but my boards only have two physical ports and I already know which one is the debug port/first port. But I could run it for you if you want me to...
That would be nice.
Will do.
Thanks.
Although the script was mainly written to find the two debug ports on my machine with 14 ports, I hope it is useful for smaller machines.
14 ports?? You must have a USB machine from hell :-) Cables running every which way :-)
Actually, I have zero USB devices plugged in. The board has 8 USB ports (including one for debug) and I bought an add-in card (6 ports) which I wanted to test for debug support. I wonder whether I can add two more 6-port cards with one debug port each to that machine. ;-)
My goal is to make sure the coreboot USB debug code works well with plug-in cards. That's needed for boards without serial and without USB debug support (mainly IBM boards).
Regards, Carl-Daniel
Hi,
the challenge is to create a cross-platform tool which tells you about the EHCI USB debug ports in your machine and whether something is attached to them. With existing tools, this is possible only for a few corner cases: specific Linux kernel versions, special kernel configurations and a non-mounted /proc/bus/usb together with a patched lsusb shipped with opensuse.
Suggestion: Create a patch for lspci and make sure upstream merges it. That would at least take care of being independent on available dmesg output from a recent, but not too recent kernel. With a patched lspci (similar to the recent VPD patches) it is possible to display the USB debug physical port number. After that, you just have to write a new tool from scratch which can display the USB devices attached to a given controller and physical port.
On 09.09.2008 03:31, Carl-Daniel Hailfinger wrote:
I wanted to know which physical port of my multiple USB controllers have the debug capability. There was no way to find that easily, so I created a tool which will do most of the work for the user.
Example output: The following PCI devices support a USB debug port (says lspci): 0000:00:1d.7 The following PCI devices support a USB debug port (says the kernel): 0000:00:1d.7 PCI device 0000:00:1d.7, USB bus 3, USB physical port 1 Currently connected high-speed devices: /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/6p, 480M |__ Port 2: Dev 20, If 0, Class=stor., Driver=usb-storage, 480M
The output can be improved, but it's a good start.
New version. Example output: The following PCI devices support a USB debug port (says lspci): 0000:00:0b.1 0000:04:08.3 The following PCI devices support a USB debug port (says the kernel): 0000:00:0b.1 0000:04:08.3 Common subset is: 0000:00:0b.1 0000:04:08.3 The following debug ports exist: PCI device 0000:00:0b.1, USB bus 1, USB physical port 1 Attached devices: PCI device 0000:04:08.3, USB bus 3, USB physical port 1 Attached devices: Bus 03 Port 1 Dev 11, If 0, Class=stor., Driver=usb-storage, 480M Currently connected high-speed devices: Bus 03 Port 1 Dev 11, If 0, Class=stor., Driver=usb-storage, 480M Bus 03 Port 4 Dev 13, If 0, Class=stor., Driver=usb-storage, 480M
This only works if /proc/bus/usb is not mounted and if your lsusb can cope with that. Basically, lsusb has two different output formats, depending on whether /proc/bus/usb is available. Besides that, lsusb has lots of other quirks which make it near unusable. If you look at the script, you'll notice lots of code is only there to get the output format of various tools in shape. lsusb is the worst offender there.
Regards, Carl-Daniel
2008-09-09 15:21 GMT+02:00 Carl-Daniel Hailfinger
Updated version attached. This one works with slightly older lspci versions as well and fixes one bug with multiple cards.
Updated version attached. This one works around grep behaviour.
-
Carl-Daniel Hailfinger -
Corey Osgood -
Idwer Vollering -
Joseph Smith -
Peter Stuge