Hi Anatolij,
On Sat, Nov 22, 2014 at 12:40:58AM +0100, Anatolij Gustschin wrote:
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 just gave it a try.
mdelay(1000) and udelay (1000 * 1000) are both taking around 1s (1.0002... for udelay, 1.13... for mdelay).
udelay(1) on the other hand takes around 151us, which seems to be the same overhead we saw for udelay(1000 * 1000).
While that looks really high with regard to what you were saying, but I just tested it with a beaglebone black that have similar delay values, and yet the usb storage works as expected. So I don't think it's really the issue there :/
Maxime