Hi Maxime,
On Thu, 20 Nov 2014 17:49:17 +0100 Maxime Ripard maxime.ripard@free-electrons.com wrote:
Hi,
I'm currently working on 2014.07, on a custom TI AM335x based board.
Everything works great so far, except when we're trying to have USB host working.
The board has the MUSB1 controller wired as USB Host only, with the following configuration:
#define CONFIG_USB_MUSB_DSPS #define CONFIG_ARCH_MISC_INIT #define CONFIG_MUSB_PIO_ONLY #define CONFIG_MUSB_DISABLE_BULK_COMBINE_SPLIT #define CONFIG_MUSB_HOST #define CONFIG_MUSB_DSPS #define CONFIG_AM335X_USB1 #define CONFIG_AM335X_USB1_MODE MUSB_HOST
#ifdef CONFIG_MUSB_HOST #define CONFIG_CMD_USB #define CONFIG_USB_STORAGE #define CONFIG_USB_HOST_ETHER #define CONFIG_USB_ETHER_ASIX #endif
I'm not familiar with AM335x, so I can't say if this configuration is okay.
Whenever we try to scan the USB controller and that a device is attached, we get the following output:
U-Boot# usb start (Re)start USB... USB0: scanning bus 0 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found scanning usb for ethernet devices... 0 Ethernet Device(s) found
The device itself being a USB key, it's somewhat odd that it enumerates the device, but doesn't find the storage device...
The device found is the controller's root hub device, not the USB storage device. "usb info" should show more about it.
The same USB port with the same device works fine under Linux.
The VBUS pin is still up after running the command, so it's not really a matter of power being shut down on the bus.
I'm kind of running out of idea on what to test next. The differences between u-boot's musb-new and Linux' own musb driver seems thin and to make sense, so I don't think the driver itself is to blame.
Anyone experienced such a thing?
We experienced similar thing this week, but on an imx6dl based board. Quite a lot of debugging and comparison with USB host operation under Linux didn't really help much. Finally we found the issue with the timer implementation, udelay(1) took too much time, about 35 usec. Whereas one would expect it to take about 1 usec, ideally. EHCI-HCD, USB-Hub and Storage drivers in U-Boot use udelay()/mdelay() quite extensively. Reworking the timer implementation for our platform resulted in udelay(1) times taking about 2.5 usec. This was enough for USB driver code to work again.
HTH,
Anatolij