[LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
stern at rowland.harvard.edu
Mon Dec 11 15:53:19 CET 2006
On Thu, 7 Dec 2006, Peter Stuge wrote:
> On Wed, Dec 06, 2006 at 01:08:14PM -0800, Lu, Yinghai wrote:
> > -----Original Message-----
> > From: Andi Kleen [mailto:ak at suse.de]
> > Sent: Wednesday, December 06, 2006 12:59 PM
> > >I haven't looked how the other usb_debug works -- if it's polled
> > >too then it wouldn't have much advantage.
> > Need to verify if the two sides of debug cable are identical.
In fact they are not. They are almost identical but not exactly the same.
> I got my device yesterday and after a small plugfest I can confirm
> that only one end of the device enumerates when connected to an ICH7
> EHCI driven by 2.6.19.
This is incorrect. Both sides will enumerate. In fact, both sides will
enumerate even at full speed (when plugged in to a UHCI controller instead
The difference is that the device will accept power only from one side --
let's call it the A side (the side to the right when you have the PLX logo
The device is bus-powered, so nothing will happen if the A side isn't
plugged in. But if it is then both the A and B sides will enumerate.
Their descriptors are almost the same; only the serial numbers are
different. The A side's serial number string is "1", and the B side's
serial number string is "0". Oddly enough, both sides use the same string
index number for the descriptor (3).
> Bus 001 Device 027: ID 0525:127a Netchip Technology, Inc.
> Device Descriptor:
> bLength 18
> bDescriptorType 1
> bcdUSB 2.00
> bDeviceClass 255 Vendor Specific Class
> bDeviceSubClass 0
> bDeviceProtocol 0
> bMaxPacketSize0 64
> idVendor 0x0525 Netchip Technology, Inc.
> idProduct 0x127a
> bcdDevice 1.01
> iManufacturer 1 NetChip
> iProduct 2 NetChip TurboCONNECT 2.0
> iSerial 3 1
> The device is in fact not self-powered.
> My theory is that the same set of descriptors are used for both ends,
> but one end has been locked to address 127 in order to work with
> simpler debug port drivers that assume it will be there.
No, you are wrong. The device will accept any address on either side.
> I guess that the self-powered error is also to simplify life for
> debug port drivers. IIRC most if not all USB power management
> concerns are noops for debug ports.
I don't see how it would make life any simpler, but the device certainly
does lie about its power source.
More information about the coreboot