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.rip...@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
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
