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

[Albert ARIBAUD]

Hello Anatolij,

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

I think the USB code might be mis-using udelay(), then. Here's why I do:

- the semantics of udelay(n) are AFAIUI "delay at least n
  microseconds", but nothing says it won't delay more, especially for
  small wait times where the setup/cleanup part of udelay() will
  obviously get a bigger share of the execution time than the actual
  delaying. 

- OTOH, the problems you witness seem to imply that the USB code is
  expecting udelay(n) to "wait for at least n microseconds but no more
  than some unspecified limit", since if udelay /does/ take too long,
  the code fails because its expectation is not met.

Did you find out why a longer delay() causes the USB code to fail? For
instance, is udelay() used for synchronizing to an external event, and
delaying too much makes the code miss the event?

> HTH,
> 
> Anatolij

Amicalement,
-- 
Albert.