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

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

[Remy Bohmer]

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] [patch 1/3] Fix for USB sticks not working on ARM while using GCC 4.x compilers

[Remy Bohmer]

An embedded and charset-unspecified text was scrubbed...
Name: fix-compiler-dependency-bug.patch
Url: http://lists.denx.de/pipermail/u-boot/attachments/20080916/a7753d4c/attachment.txt 

[U-Boot] [patch 2/3] Refactoring parts of the common USB OHCI code

[Remy Bohmer]

An embedded and charset-unspecified text was scrubbed...
Name: usb_ohci-code-refactoring.patch
Url: http://lists.denx.de/pipermail/u-boot/attachments/20080916/27475289/attachment.txt 

[U-Boot] [patch 3/3] USB layer of U-Boot causes USB protocol errors while using USB memory sticks

[Remy Bohmer]

An embedded and charset-unspecified text was scrubbed...
Name: make-usb-stick-initialisation-robust.patch
Url: http://lists.denx.de/pipermail/u-boot/attachments/20080916/9924f13c/attachment.txt 

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

[Markus Klotzbücher]

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: office at denx.de")

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

[Thao To Hieu]

Dear All,

This is a nice work. I have ported UBoot on TEngine/SH7727 and got this issue. The issue had reported into UBoot mailing list and Remy sent me a patch. And 
"ERROR: CTL:TIMEOUT errors" could be fixed with his patch. Thank you a lot.

Let me test his update patch again and report the result later.

Best regards,

-----Original Message-----
From: Markus Klotzb?cher [mailto:mk at denx.de] 
Sent: Tuesday, September 16, 2008 9:11 PM
To: Remy Bohmer
Cc: u-boot at lists.denx.de; Wolfgang Denk; Thao To Hieu; Nicolas Ferre; Stelian Pop
Subject: Re: [patch 0/3] Improve stability USB memory sticks for the commonOHCI 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: office at denx.de")

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

[Markus Klotzbücher]

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: office at denx.de")

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

[Stelian Pop]

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		0x00700000	/* 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: 0x0000  Product 0x0000 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 00000000000743                                       
 - 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                                                                              
## Unknown partition table                                                                   
                                                                                             
print_part of 4                                                                              
## Unknown partition table                                                                                                                 

U-Boot> usb storage                                                                          
  Device 0: not available                                                                    

U-Boot> fatinfo usb 0:1                                                                      
                                                                                             
** Invalid boot device **                                                                    

-- 
Stelian Pop <stelian@popies.net>

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

[Remy Bohmer]

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] [patch 0/3] Improve stability USB memory sticks for the common OHCI USB layer.

[Remy Bohmer]

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] [patch 0/3] Improve stability USB memory sticks for the common OHCI USB layer.

[Stelian Pop]

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 <stelian@popies.net>

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

[Remy Bohmer]

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] [patch 0/3] Improve stability USB memory sticks for the common OHCI USB layer.

[Remy Bohmer]

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 <stelian@popies.net>
>
>

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

[Markus Klotzbücher]

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 <nicolas.lebedenco@tasksistemas.com.br>
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 <nicolas.lebedenco@tasksistemas.com.br>

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: office at denx.de")

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

[Remy Bohmer]

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 <nicolas.lebedenco@tasksistemas.com.br>
> 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 <nicolas.lebedenco@tasksistemas.com.br>
>
> 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: office at denx.de")
>

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

[Stelian Pop]

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 <stelian@popies.net>

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

[Remy Bohmer]

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] [patch 0/3] Improve stability USB memory sticks for the common OHCI USB layer.

[Stelian Pop]

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: 0x0000  Product 0x0000 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\b \b\b \btree

Device Tree:
  1  Hub (12MBit/s, 0mA)
  |   OHCI Root Hub 
  |
  |\b+-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 0x00a00000
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
root at at91sam9263ek:~$ lsusb -v

Bus 001 Device 002: ID 126f:1325 TwinMOS Mobile Disk
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x126f TwinMOS
  idProduct          0x1325 Mobile Disk
  bcdDevice            1.00
  iManufacturer          16 TTI-WDE     
  iProduct               32 USB 2.0 Mobile Disk    
  iSerial                48 FF04112100886
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           39
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration         64 iCfg
    bmAttributes         0x80
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           3
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk (Zip)
      iInterface             96 BULK
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval             255
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval             255
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0002  1x 2 bytes
        bInterval               1
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  bNumConfigurations      1

Bus 001 Device 001: ID 0000:0000  
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            9 Hub
  bDeviceSubClass         0 Unused
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x0000 
  idProduct          0x0000 
  bcdDevice            2.06
  iManufacturer           3 Linux 2.6.22 ohci_hcd
  iProduct                2 AT91 OHCI
  iSerial                 1 at91
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           25
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower                0mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         9 Hub
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0002  1x 2 bytes
        bInterval             255
Hub Descriptor:
  bLength               9
  bDescriptorType      41
  nNbrPorts             2
  wHubCharacteristic 0x0012
    No power switching (usb 1.0)
    No overcurrent protection
  bPwrOn2PwrGood        2 * 2 milli seconds
  bHubContrCurrent      0 milli Ampere
  DeviceRemovable    0x00
  PortPwrCtrlMask    0x00 
 Hub Port Status:
   Port 1: 0000.0103 power enable connect
   Port 2: 0000.0100 power
root at at91sam9263ek:~$ 

-- 
Stelian Pop <stelian@popies.net>

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

[Wolfgang Denk]

Dear Remy Bohmer,

In message <3efb10970809190216x65954093h52610ba9bfdc6ec7@mail.gmail.com> 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: wd at denx.de
Uncertain fortune is thoroughly mastered by the equity of the  calcu-
lation.                                               - Blaise Pascal

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

[Remy Bohmer]

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] [patch 0/3] Improve stability USB memory sticks for the common OHCI USB layer.

[Stelian Pop]

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 00000000000722
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: UT163    Rev: 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 <stelian@popies.net>

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

[Remy Bohmer]

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 00000000000722
> 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: UT163    Rev: 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 <stelian@popies.net>
>
>