Dear all,
I am following up on a post I made earlier in the week on U-Boot hanging (infinite looping) in a particular part of drivers/usb/host/ehci-hcd.c . I also reported that it works for some hubs and not for others.
I have been attempting to debug this problem and I have found something of interest. In one instance, one of the hubs that work has the _same_ chipset of another hub that doesn't work - it has the same product ID and vendor ID. However, there are what looks to be some configuration differences between the devices.
I have attached below what Linux reports for lsusb for both hubs and I have highlighted the differences. Are these differences likely to have any bearing on the operation of the hub? Is there any other testing for information that I can supply that may assist in helping to solve the issue?
Best regards Damien Dusha.
For the "broken" hub (with highlighted differences):
Bus 003 Device 004: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 9 Hub bDeviceSubClass 0 Unused -----------------> bDeviceProtocol 0 Full speed (or root) hub <----------------- DIFFERENT bMaxPacketSize0 64 idVendor 0x05e3 Genesys Logic, Inc. idProduct 0x0608 USB-2.0 4-Port HUB bcdDevice 7.02 iManufacturer 0 iProduct 1 USB2.0 Hub iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0001 1x 1 bytes ---------------> bInterval 255 <----------------------- DIFFERENT Hub Descriptor: bLength 9 bDescriptorType 41 nNbrPorts 4 ------> wHubCharacteristic 0x00e9 <--------------- DIFFERENT ----> Per-port power switching ---> Per-port overcurrent protection ---> Port indicators bPwrOn2PwrGood 50 * 2 milli seconds bHubContrCurrent 100 milli Ampere DeviceRemovable 0x00 PortPwrCtrlMask 0xff Hub Port Status: Port 1: 0000.0100 power Port 2: 0000.0100 power Port 3: 0000.0100 power Port 4: 0000.0100 power Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 9 Hub bDeviceSubClass 0 Unused ------------> bDeviceProtocol 1 Single TT <------------------------ DIFFERENT bMaxPacketSize0 64 bNumConfigurations 1 Device Status: 0x0001 Self Powered
Whereas on the working version of a hub with the same product and vendor ID:
Bus 001 Device 015: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 1 Single TT <---------- DIFFERENT bMaxPacketSize0 64 <snip> Hub Descriptor: bLength 9 bDescriptorType 41 nNbrPorts 4 wHubCharacteristic 0x00e0 <------------- DIFFERENT Ganged power switching Ganged overcurrent protection TT think time 32 FS bits Port indicators <snip> Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 0 Full speed (or root) hub <------------ DIFFERENT bMaxPacketSize0 64 bNumConfigurations 1
On Tue, Sep 22, 2009 at 4:32 PM, Damien Dusha d.dusha@gmail.com wrote:
Dear All,
I am attempting to integrate the USB on the Freescale mpc5121 processor on the mpc5121ads board from Silicon Turnkey for upgrades of kernel, u-boot etc.
I have succeeded in integrating Francesco Rendine 's EHCI patch for the MPC5121 (see http://lists.denx.de/pipermail/u-boot/2009-June/055021.html ) and I have the general functionality of upgrading from a USB stick working straight from the USB, or through some (but not all) USB hubs.
However, I am having problem using the driver with some (but not all) USB hubs. I have some USB hubs that work "out of the box", but I have other hubs that cause booting u-boot to hang after attempting to initialise the USB. The ones that do work, and the ones that fail all fail in the same place the great majority of the time (they succeed very occasionally).
I have traced the hang to the following lines in drivers/usb/host/ehci-hcd.c:
/* Wait for TDs to be processed. */ ts = get_timer(0); vtd = td; do { /* Invalidate dcache */ ehci_invalidate_dcache(&qh_list); token = hc32_to_cpu(vtd->qt_token); if (!(token & 0x80)) break;
/* This was my own line I added to check. The get_timer(ts) always returns 0 and never exits the loop */ debug("get_timer: %d, CONFIG_SYS_HZ: %d\n", get_timer(ts), CONFIG_SYS_HZ); } while (get_timer(ts) < CONFIG_SYS_HZ);
One of the hubs that fails is part of a 4-port USB-Serial converter (it's a hub to 4 FTDI chips) and is described as: Manufacturer ALCOR Product Generic USB Hub
Another of the (mostly) failing hubs is a generic "i-rocks" brand: Manufacturer Product USB2.0 Hub
It happens even when the hubs are self-powered, or connected through a hub that is itself powered externally (we've had power problems from the mpc5121ads board's USB in the past).
The hubs (and USB-Serial adaptors) are perfectly recognised under Linux, if USB is not started in U-Boot and we proceed to a normal Linux boot sequence.
Is anyone able to suggest what might be going wrong, or some further testing that may help reveal the problem?
Best regards Damien Dusha.