[U-Boot] [patch 0/3] Improve stability USB memory sticks for the common OHCI USB layer.

Remy Bohmer linux at bohmer.net
Sat Sep 20 11:38:58 CEST 2008


Hello Stelian,

>> Thanks, and I expect to hear some more positive news ;-)))
> I'm afraid I have more bad news.

Grmbl, Now my weekend is ruined ;-))))

> I updated my tree to the latest git. I use the ELDK 4.1 arm compiler.
> Tested on an AT91SAM9263, with two different USB sticks:
> U-Boot> usb reset
> (Re)start USB...
> USB:   scanning bus for devices... ERROR:  USB-error: DEVICENOTRESPONDING: Device did not respond to token (IN) or did not provide a handshake (OUT) (5)
> ERROR: USB-error: DEVICENOTRESPONDING: Device did not respond to token (IN) or did not provide a handshake (OUT) (5)
> ERROR:  USB-error: DEVICENOTRESPONDING: Device did not respond to token (IN) or did not provide a handshake (OUT) (5)
> ERROR: USB-error: DEVICENOTRESPONDING: Device did not respond to token (IN) or did not provide a handshake (OUT) (5)
> USB device not accepting new address (error=20)
> 2 USB Device(s) found
>       scanning bus for storage devices... 0 Storage Device(s) found
> Without your 3 patches applied, I get:
> U-Boot> usb start
> (Re)start USB...
> USB:   scanning bus for devices...
>      USB device not responding, giving up (status=20)
> 2 USB Device(s) found
>       scanning bus for storage devices... 0 Storage Device(s) found

Okay, let's summarize this:
With and without patches it does not work on AT91CAP9 and AT91SAM9263...
(Without my patches you get a less detailed error message...)

There can be several reasons for this:
* The USB code never worked on AT91CAP9 and AT91SAM9263 with mainline,
so it could be possible that there is some initialisation missing for
CAP9 and SAM9263, possible for more CPU's also that did not work
before with GCC 3.x.
Does not mean the patches are bad, but does mean that it could be
possible/likely that these patches do not fix all problems for all
boards and all sticks.
* Your USB sticks behave (slightly) different than the sticks I tested.
Looking at the error code you get, it seems that the USB stick stops
responding, after some time of valid communication, at least 5 control
requests to EP0 happen successfully before setting the address, so
there was communication which died for some reason. This error code is
reported by the OHCI controller itself and is out of hands of
software, so we can exclude a lot of SW. Notice that just before
setting the address the 2nd device reset is done, maybe there is some
additional timeout after reset is required for some USB devices.

I want to invest some time in it to debug these issues also, but then
I will need your help, because I do not have a SAM9263, CAP9 board so
I cannot reproduce your problems here.

I have several ideas where to look, and can create some experimental
patches, but before I do that and bother you unnecessary, I would like
to get some more information from you about which USB sticks you are
using.

Can you please provide me the output of: (even if the command fails)
* usb info
* usb storage
* usb tree
* and if possible a 'lsusb -v' output from linux of your USB sticks

Also, it would be very helpful if you would test your sticks on a
SAM9261, because that SoC _must_ work. (I tested on AT91SAM9261-EK,
and custom board)
Then we can relate the problem to a specific USB stick, or to a certain SoC.


Kind Regards,

Remy


More information about the U-Boot mailing list