
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