[U-Boot] USB Host not enumerating properly on AM335x-based board

Anatolij Gustschin agust at denx.de
Sat Nov 22 00:40:58 CET 2014


Hi Maxime,

On Thu, 20 Nov 2014 17:49:17 +0100
Maxime Ripard <maxime.ripard at 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


More information about the U-Boot mailing list