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

[Maxime Ripard <maxime.ripard@free-electrons.com>]

Hi,

On Sat, Nov 22, 2014 at 12:40:58AM +0100, Anatolij Gustschin wrote:
> 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...

Yeah, Eric made me think about that too. What's odd is that it
actually fails when there's no device plugged in.

> The device found is the controller's root hub device, not the
> USB storage device. "usb info" should show more about it.

Ok, I'll confirm this then.

> > 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.

Hmmm, that's very interesting :)

I'll test the time our udelay takes, and let you know about what I
find there.

Thanks a lot!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20141124/d1e20e42/attachment.pgp>