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.
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 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.
Dear Remy Bohmer, In message <[EMAIL PROTECTED]> you wrote: > > >> > U-Boot> usb storage > >> > Device 0: not available > > What about this one ? Isn't this supposed to say something else ? > > 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. > 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. > 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. 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]. Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] Uncertain fortune is thoroughly mastered by the equity of the calcu- lation. - Blaise Pascal ___ 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 samedi 20 septembre 2008 à 11:38 +0200, Remy Bohmer a écrit : > 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 ;- Sorry for that :) [...] > 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...) Right. However the two board fail with slight different errors iirc. > 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. Sure. However, I've double checked the Linux initialisation code for the usb host on the AT91 boards and the U-Boot counterparts and there are only a few differences (some VBus GPIOs to set on the AT91SAM9263, an additionnal clock for AT91SAM9261), and I cannot find anything which could go wrong here. > 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. Sure. [...] > 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 do have a SAM9263 in front of me waiting for your experimental patches :-) And I can do some extra tests on other Atmel boards, but this will have to wait a week or so because I won't have access to them before then. > 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. I tested with 2 different USB sticks, a very old 256 MB one and a more recent 1 GB. They behave exactly the same. > 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 See below. > 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. Stelian. 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 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 Configuration: 0 - Interfaces: 0 Bus Powered 0mA U-Boot> usb storage No storage devices, perhaps not 'usb start'ed..? U-Boot> usb re tree Device Tree: 1 Hub (12MBit/s, 0mA) | OHCI Root Hub | |+-0 See Interface (12MBit/s, 0mA) U-Boot> boot [...] at91_ohci at91_ohci: AT91 OHCI at91_ohci at91_ohci: new USB bus registered, assigned bus number 1 at91_ohci at91_ohci: irq 29, io mem 0x00a0 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 2 ports detected Initializing USB Mass Storage driver... usb 1-1: new full speed USB device using at91_ohci and address 2 usb 1-1: configuration #1 chosen from 1 choice scsi0 : SCSI emulation for USB Mass Storage devices usbcore: registered new interface driver usb-storage USB Mass Storage support registered. [...] scsi 0:0:0:0: Direct-Access USB 2.0 Mobile Disk N4S 1.00 PQ: 0 ANSI: 2 sd 0:0:0:0: [sda] 507904 512-byte hardware sectors (260 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Assuming drive cache: write through sd 0:0:0:0: [sda] 507904 512-byte hardware sectors (260 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Assuming drive cache: write through sda: sda1 sd 0:0:0:0: [sda] Attached SCSI removable disk [...] at91sam9263ek login: root [EMAIL PROTECTED]:~$ lsusb -v Bus 001 Device 002: ID 126f:1325 TwinMOS Mobile Disk Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x126f TwinMOS idProduct 0x1325 Mobile Disk bcdDevice1.00 iManufacturer 16 TTI-WDE iProduct 32 USB 2.0 Mobile Disk iSerial48 FF04112100886 bNumConfigurations 1 Configuration Descriptor: bLeng
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 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.
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.
On Fri, Sep 19, 2008 at 11:45:44AM +0200, Remy Bohmer wrote: > >> > 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. Are you guys working on top of git? Doesn't the following commit fix this already? 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.
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 Stelian, >> 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 I am happy to hear that :-))) So, Markus, please do not let this issue stop you from integrating these patches :-)) >> > U-Boot> usb storage >> > Device 0: not available > What about this one ? Isn't this supposed to say something else ? I get these messages also, and I did not considered that to be a problem, because everything works... I got these messages from the beginning, even when USB worked on a single USB stick when I compiled everything with GCC 3.4. I will look into it, but I want to make clear that it is not something I broke with my patches. >> > 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 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. But, there are USB sticks out there that contain actually 2 devices with an internal hub. Some of these work, and some of these do not. It has to do with U-boot only capable of handling 1 USB storage device at a time. An example of such sticks can be found here (there may also be other manufacturers): http://www.pendrivestore.com/products/pendriveusb2/index.shtml (Notice that from this manufacturer none of the 1GB editions seem to work, however the 8GB and 256 MB versions work properly) > 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 ;-))) 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, > 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.
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.
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.
Dear Remy, I added your patches to the USB custodian repository. As I consider these bugfixes I'll send a pull before the next release. I succesfully tested them on sequoia, but it would be nice to get some more feedback from the others who reported problems. 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.
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
[U-Boot] [patch 0/3] Improve stability USB memory sticks for the common OHCI USB layer.
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... -- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
