Hi all,

I am adding EHCI support to the MX.31 Soc. I got an error from the ehci-hcd controller, that seems (apparently!) to not depend by the Soc I am using.

"usb start" works as expected:

CPU: Freescale i.MX31 at 398 MHz Board: DAVE/DENX Qong DRAM: 256 MiB FLASH: 128 MiB NAND: 128 MiB In: serial Out: serial Err: serial FPGA: version register = 0.8.7 Net: dnet0 Hit any key to stop autoboot: 0 => usb start (Re)start USB... USB: Writing USBH2 port 0x40004020 Writing USBH2 port 0x40004020 Register 10011 NbrPorts 1 USB EHCI 1.00 scanning bus for devices... 2 USB Device(s) found scanning bus for storage devices... 1 Storage Device(s) found

And usb info reports correct values: => usb info 1: Hub, USB Revision 2.0 - u-boot EHCI Host Controller - Class: Hub - PacketSize: 64 Configurations: 1 - Vendor: 0x0000 Product 0x0000 Version 1.0 Configuration: 1 - Interfaces: 1 Self Powered 0mA Interface: 0 - Alternate Setting 0, Endpoints: 1 - Class Hub - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms

2: Mass Storage, USB Revision 2.0 - Kingston DataTraveler 2.0 001D0F0A94C25B89070F1158 - Class: (from Interface) Mass Storage - PacketSize: 64 Configurations: 1 - Vendor: 0x0930 Product 0x6545 Version 1.0 Configuration: 1 - Interfaces: 1 Bus Powered 200mA Interface: 0 - Alternate Setting 0, Endpoints: 2 - Class Mass Storage, Transp. SCSI, Bulk only - Endpoint 1 In Bulk MaxPacket 512 - Endpoint 2 Out Bulk MaxPacket 512

I can read the directory structure of the USB stick:

=> fatload usb 0 80000000 doc/qong-hm.pdf reading doc/qong-hm.pdf

or load some files:

fatload usb 0 80000000 doc/qong-hm.pdf reading doc/qong-hm.pdf

3145354 bytes read

until the following error is raised:

EHCI fail timeout STD_ASS reset

The error does not happen each time. Sometimes at the first fatls/fatload attempt, sometimes I need several tries to get it. When it happens, the usb controller becomes unavailable and I have to reset the system. I traced the value of the usbsts (status) register when the error occurs:

handshake fails 0xa088

The AS bit is really set, and it does not go away as it is supposed to do. The RCL (reclamation) and FRI (frame list rollover) are set too, but I do not know if they are a consequence of the fact the ASE bit is not reset by the controller or a cause.

I found in the ML someone reporting the same error, but it seems to me it was related to USB on PCI controllers, and that is not my case.

Any hints ?

Stefano