Re: [U-Boot] [patch 0/3] Improve stability USB memory sticks for the common OHCI USB layer.
Hi Remy, Sorry it took so long but here are the results of the tests on my AT91SAM9261-EK. Le samedi 20 septembre 2008 à 22:14 +0200, Stelian Pop a écrit : 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. Hmm, I can do that, but not before September 29. The stick is fine, it does work ok on the 9261: usb reset (Re)start USB... USB: scanning bus for devices... New Device 0 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x40 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x40 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x40 set address 1 usb_control_msg: request: 0x5, requesttype: 0x0, value 0x1 index 0x0 length 0x0 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x12 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 length 0x8 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 length 0x19 get_conf_no 0 Result 25, wLength 25 if 0, ep 0 ##EP epmaxpacketin[1] = 2 set configuration 1 usb_control_msg: request: 0x9, requesttype: 0x0, value 0x1 index 0x0 length 0x0 new device strings: Mfr=0, Product=1, SerialNumber=0 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x300 index 0x0 length 0xFF USB device number 1 default language ID 0x409 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x301 index 0x409 length 0xFF Manufacturer Product OHCI Root Hub SerialNumber usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 index 0x0 length 0x4 usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 index 0x0 length 0x9 usb_control_msg: request: 0x0, requesttype: 0xA0, value 0x0 index 0x0 length 0x4 usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x1 length 0x0 usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x2 length 0x0 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 usb_control_msg: request: 0x1, requesttype: 0x23, value 0x10 index 0x1 length 0x0 usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x1 length 0x0 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x1 length 0x0 New Device 1 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x40 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x40 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x40 usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x1 length 0x0 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x1 length 0x0 set address 2 usb_control_msg: request: 0x5, requesttype: 0x0, value 0x2 index 0x0 length 0x0 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x12 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 length 0x8 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 length 0x27 get_conf_no 0 Result 39, wLength 39 if 0, ep 0 if 0, ep 1 if 0, ep 2 ##EP epmaxpacketout[1] = 64 ##EP epmaxpacketin[2] = 64 ##EP epmaxpacketin[3] = 64 set configuration 1 usb_control_msg: request: 0x9, requesttype: 0x0, value 0x1 index 0x0 length 0x0 new device strings: Mfr=1, Product=2, SerialNumber=3 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x300 index 0x0 length 0xFF USB device number 2 default language ID 0x409 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x301 index 0x409 length 0xFF usb_control_msg: request: 0x6, requesttype: 0x80, value 0x302 index 0x409 length 0xFF usb_control_msg: request: 0x6, requesttype: 0x80, value 0x303 index 0x409 length 0xFF Manufacturer P Technology Product USB Mass Storage Device SerialNumber 000722 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 length 0x4 2 USB Device(s) found scanning bus for storage devices... usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 length 0x0 usb_control_msg: request: 0x1, requesttype: 0x2, value 0x0 index 0x82 length 0x0 usb_control_msg: request: 0x1, requesttype: 0x2, value 0x0 index 0x1 length 0x0 1 Storage Device(s) found U-Boot usb storage Device 0: Vendor: UT163Rev: 0.00 Prod: USB Flash Disk Type: Removable Hard Disk Capacity: 963.9 MB = 0.9 GB (1974271 x 512) U-Boot U-Boot fatls usb 0 1 . 51878326 download.tgz 20351 tp.tgz 2 file(s), 0 dir(s) U-Boot -- Stelian Pop [EMAIL PROTECTED]
Re: [U-Boot] [patch 0/3] Improve stability USB memory sticks for the common OHCI USB layer.
Hello Stelian, Hmm, I can do that, but not before September 29. The stick is fine, it does work ok on the 9261: Thanks for testing it, it sounds good... But that does mean that there is a SoC dependant issue here... I looked at the code again, and found an oddity that I overlooked before and that I need to investigate some more when I have our USB analyser back. It could explain different behaviour across different OHCI controllers. I will keep you informed when I have more news. (maybe tomorrow, or else beginning next week) Kind Regards, Remy usb reset (Re)start USB... USB: scanning bus for devices... New Device 0 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x40 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x40 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x40 set address 1 usb_control_msg: request: 0x5, requesttype: 0x0, value 0x1 index 0x0 length 0x0 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x12 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 length 0x8 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 length 0x19 get_conf_no 0 Result 25, wLength 25 if 0, ep 0 ##EP epmaxpacketin[1] = 2 set configuration 1 usb_control_msg: request: 0x9, requesttype: 0x0, value 0x1 index 0x0 length 0x0 new device strings: Mfr=0, Product=1, SerialNumber=0 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x300 index 0x0 length 0xFF USB device number 1 default language ID 0x409 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x301 index 0x409 length 0xFF Manufacturer Product OHCI Root Hub SerialNumber usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 index 0x0 length 0x4 usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 index 0x0 length 0x9 usb_control_msg: request: 0x0, requesttype: 0xA0, value 0x0 index 0x0 length 0x4 usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x1 length 0x0 usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x2 length 0x0 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 usb_control_msg: request: 0x1, requesttype: 0x23, value 0x10 index 0x1 length 0x0 usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x1 length 0x0 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x1 length 0x0 New Device 1 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x40 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x40 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x40 usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x1 length 0x0 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x1 length 0x0 set address 2 usb_control_msg: request: 0x5, requesttype: 0x0, value 0x2 index 0x0 length 0x0 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x12 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 length 0x8 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 length 0x27 get_conf_no 0 Result 39, wLength 39 if 0, ep 0 if 0, ep 1 if 0, ep 2 ##EP epmaxpacketout[1] = 64 ##EP epmaxpacketin[2] = 64 ##EP epmaxpacketin[3] = 64 set configuration 1 usb_control_msg: request: 0x9, requesttype: 0x0, value 0x1 index 0x0 length 0x0 new device strings: Mfr=1, Product=2, SerialNumber=3 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x300 index 0x0 length 0xFF USB device number 2 default language ID 0x409 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x301 index 0x409 length 0xFF usb_control_msg: request: 0x6, requesttype: 0x80, value 0x302 index 0x409 length 0xFF usb_control_msg: request: 0x6, requesttype: 0x80, value 0x303 index 0x409 length 0xFF Manufacturer P Technology Product USB Mass Storage Device SerialNumber 000722 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 length 0x4 2 USB Device(s) found scanning bus for storage devices... usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 length 0x0 usb_control_msg: request: 0x1, requesttype: 0x2, value 0x0 index 0x82 length 0x0 usb_control_msg: request: 0x1, requesttype: 0x2, value 0x0 index 0x1 length 0x0 1 Storage Device(s) found U-Boot usb storage Device 0: Vendor: UT163Rev: 0.00 Prod: USB Flash Disk Type: Removable Hard Disk Capacity: 963.9 MB = 0.9 GB (1974271 x
Re: [U-Boot] [patch 0/3] Improve stability USB memory sticks for the common OHCI USB layer.
Hello Wolfgang, I get these messages also, and I did not considered that to be a problem, because everything works... Oh, but this *is* a problem. It is not the normal output of that command. Yeah, I agree, it was a problem, but this is what I meant: During debugging it was not related to the problem I was debugging, therefor I considered it was no problem (for me) at that time... I will look into it, but I want to make clear that it is not something I broke with my patches. OK. But it is an unsolved problem. No, it was already solved in latest git. I started debugging on a 2 week old git version which did not contain that fix. Markus pointed us already to the fix. However, the fix in mainline was not complete, therefor I made a patch to make it complete... (should be in your mailbox) I have tested with USB sticks in the range of 256 MB up to 8 GB. So, the size should not matter. I tested FAT16 and FAT32. Indeed, size should not matter at all. Also, the file system type should not matter at all at this stage. No, but the weird thing is that I had (new) USB sticks in the beginning that only started to work after a reformat... Very strange, but true. Now (with my USB patches) these issues are solved, and it makes no difference anymore... Partitioning might have in influence int he later steps [even though it should not, i. e. any issues popping up there are more items on the list of things that need to be fixed]. Agree. Kind Regards, Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [patch 0/3] Improve stability USB memory sticks for the common OHCI USB layer.
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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [patch 0/3] Improve stability USB memory sticks for the common OHCI USB layer.
Le jeudi 18 septembre 2008 à 16:54 +0200, Remy Bohmer a écrit : Hello Stelian, Hi Remy, I gave your patches a run on an AT91CAP9 and had limited success with them (usb seems to work, usb storage do not): Does it work without the patches? Is it a regression, or still an improvement? It is an improvement, without the patches it doesn't work at all U-Boot usb part print_part of 0 Partition Map for USB device 0 -- Partition Type: DOS Partition Start Sector Num Sectors Type 1 63 1974208 6 print_part of 1 ## Unknown partition table These errors are normal, 'usb part' seems to look for primary partitions on a USB stick that is formatted as a floppy... U-Boot usb storage Device 0: not available What about this one ? Isn't this supposed to say something else ? U-Boot fatinfo usb 0:1 ** Invalid boot device ** I have no explanation for this error, it could be related to the filesystem on the USB stick itself. No, the filesystem is ok. (it's a 1GB stick btw). I do not see any errors that USB itself is not working, the problems I fixed were in the USB area, and they solved all the problems I encountered with USB sticks on AT91SAM9261 (OHCI) I'll try to test on some other AT91SAM9 boards later today, if I find a few minutes... Stelian. -- Stelian Pop [EMAIL PROTECTED] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [patch 0/3] Improve stability USB memory sticks for the common OHCI USB layer.
Hello Stelian, U-Boot usb storage Device 0: not available What about this one ? Isn't this supposed to say something else ? I got it! Currently the IF_TYPE_USB is not handled in the dev_print routine in part.c It is just a info printing issue, not a real functional bug. I am working on a patch. It will be a separate standalone patch. Kind Regards, Remy U-Boot fatinfo usb 0:1 ** Invalid boot device ** I have no explanation for this error, it could be related to the filesystem on the USB stick itself. No, the filesystem is ok. (it's a 1GB stick btw). I do not see any errors that USB itself is not working, the problems I fixed were in the USB area, and they solved all the problems I encountered with USB sticks on AT91SAM9261 (OHCI) I'll try to test on some other AT91SAM9 boards later today, if I find a few minutes... Stelian. -- Stelian Pop [EMAIL PROTECTED] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [patch 0/3] Improve stability USB memory sticks for the common OHCI USB layer.
Hello Markus, Are you guys working on top of git? Doesn't the following commit fix this already? uuuh, I am not updating daily... But, I verified and publish my patches always on latest git, but that is something different than using the latest git in our product on daily base... So, I did not notice this change... Thanks for the hint... Kind Regards, Remy commit 47bebe34ca4e33bab0e822e4ceebbec2590ccbcb Author: Nícolas Carneiro Lebedenco [EMAIL PROTECTED] Date: Thu Sep 4 15:35:46 2008 -0300 Fix dev_print when called from usb_stor_info (usb storage command) Fix output of the usb storage command. It was printing Device 0: not available because IF_TYPE_USB was not included into the switch statement. Signed-off-by: Nicolas Lebedenco [EMAIL PROTECTED] Best regards Markus -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: [EMAIL PROTECTED]) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [patch 0/3] Improve stability USB memory sticks for the common OHCI USB layer.
Le vendredi 19 septembre 2008 à 11:16 +0200, Remy Bohmer a écrit : I'll try to test on some other AT91SAM9 boards later today, if I find a few minutes... Thanks, and I expect to hear some more positive news ;-))) I'm afraid I have more bad news. 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 Stelian. -- Stelian Pop [EMAIL PROTECTED] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [patch 0/3] Improve stability USB memory sticks for the common OHCI USB layer.
Le mardi 16 septembre 2008 à 14:55 +0200, Remy Bohmer a écrit : This series is a set of patches that are required to make USB sticks behave robust while using U-Boot on a OHCI host. Hi, I gave your patches a run on an AT91CAP9 and had limited success with them (usb seems to work, usb storage do not): $ egrep FAT\|USB include/configs/at91cap9adk.h #define CONFIG_CMD_USB 1 /* USB */ #define CONFIG_USB_OHCI_NEW 1 #define CFG_USB_OHCI_CPU_INIT 1 #define CFG_USB_OHCI_REGS_BASE 0x0070 /* AT91_BASE_UHP */ #define CFG_USB_OHCI_SLOT_NAME at91cap9 #define CFG_USB_OHCI_MAX_ROOT_PORTS 2 #define CONFIG_USB_STORAGE 1 #define CONFIG_CMD_FAT 1 ... U-Boot usb reset (Re)start USB... USB: scanning bus for devices... 2 USB Device(s) found scanning bus for storage devices... 1 Storage Device(s) found U-Boot usb info 1: Hub, USB Revision 1.10 - OHCI Root Hub - Class: Hub - PacketSize: 8 Configurations: 1 - Vendor: 0x Product 0x Version 0.0 Configuration: 1 - Interfaces: 1 Self Powered 0mA Interface: 0 - Alternate Setting 0, Endpoints: 1 - Class Hub - Endpoint 1 In Interrupt MaxPacket 2 Interval 255ms 2: Mass Storage, USB Revision 2.0 - P Technology USB Mass Storage Device 000743 - Class: (from Interface) Mass Storage - PacketSize: 64 Configurations: 1 - Vendor: 0x1307 Product 0x0163 Version 1.0 Configuration: 1 - Interfaces: 1 Bus Powered 80mA Interface: 0 - Alternate Setting 0, Endpoints: 3 - Class Mass Storage, Transp. SCSI, Bulk only - Endpoint 1 Out Bulk MaxPacket 64 - Endpoint 2 In Bulk MaxPacket 64 - Endpoint 3 In Interrupt MaxPacket 64 Interval 8ms U-Boot usb part print_part of 0 Partition Map for USB device 0 -- Partition Type: DOS Partition Start Sector Num Sectors Type 1 63 1974208 6 print_part of 1 ## Unknown partition table print_part of 2 ## Unknown partition table print_part of 3
Re: [U-Boot] [patch 0/3] Improve stability USB memory sticks for the common OHCI USB layer.
Hello Stelian, I gave your patches a run on an AT91CAP9 and had limited success with them (usb seems to work, usb storage do not): Does it work without the patches? Is it a regression, or still an improvement? U-Boot usb part print_part of 0 Partition Map for USB device 0 -- Partition Type: DOS Partition Start Sector Num Sectors Type 1 63 1974208 6 print_part of 1 ## Unknown partition table These errors are normal, 'usb part' seems to look for primary partitions on a USB stick that is formatted as a floppy... U-Boot usb storage Device 0: not available U-Boot fatinfo usb 0:1 ** Invalid boot device ** I have no explanation for this error, it could be related to the filesystem on the USB stick itself. I do not see any errors that USB itself is not working, the problems I fixed were in the USB area, and they solved all the problems I encountered with USB sticks on AT91SAM9261 (OHCI) I would expect that it would work much better than before on your CPU... Unfortunately I do not have a test environment for AT91CAP9, so I cannot verify this issue here. Kind Regards, Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [patch 0/3] Improve stability USB memory sticks for the common OHCI USB layer.
Dear Remy, On Tue, Sep 16, 2008 at 02:55:41PM +0200, Remy Bohmer wrote: This series is a set of patches that are required to make USB sticks behave robust while using U-Boot on a OHCI host. Several users complain about ERROR: CTL:TIMEOUT errors while using USB sticks, and while testing many different USB sticks it showed that some were working and many don't. It even showed a compiler dependency while debugging this, where GCC 3.x compilers seemed to work (but not always) and GCC 4.x compilers usually don't. While debugging this (with a USB analyser of course) it turned out that U-boot also made several protocol violations that needed to be solved, these resulted in hanging USB devices and so on. In a mail thread with Stelian Pop on 28 July it was reported of a known error on Atmel cores that it did not work. I tested these series on Atmel AT91SAM9261 Core, with the common OHCI driver, GCC 4.2.3 (Code Sourcery G++ Lite 2008q1-126) REMEMBER: U-boot still supports 1 single USB stick at a time... Nice work! I'll test and push your patches to the USB repo ASAP (within the next couple of days). I'd welcome any feedback especially from the people who reported the problems you describe. Thanks for chasing this down! Best regards Markus -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: [EMAIL PROTECTED]) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
