All of lore.kernel.org
 help / color / mirror / Atom feed
* [U-Boot] Issue with USB mass storage (thumb drives)
@ 2016-02-02 10:35 Schrempf Frieder
  2016-02-02 16:28 ` Fabio Estevam
  0 siblings, 1 reply; 52+ messages in thread
From: Schrempf Frieder @ 2016-02-02 10:35 UTC (permalink / raw)
  To: u-boot

Hello,

I'm using U-Boot on a custom i.MX6 board and I'm having problems while 
reading (large) files from USB thumb drives.
I wouldn't really mind if this only happened with some specific USB 
device, but the problem occurs with 3 out of 4 tested thumb drives while 
loading a 100M test file.
The devices that work seem to be rather old ones.

The same issue is also reported here: 
https://community.freescale.com/thread/377911

I can reproduce this behaviour with u-boot-imx v2014.04 and with 
mainline u-boot v2015.10 and v2016.01.

Can someone tell me if this is a known issue?
What could be the reason for this and how can I get this working?

Thanks!


U-Boot 2016.01 (Feb 02 2016 - 10:31:32 +0100)

CPU:   Freescale i.MX6SOLO rev1.3 at 792MHz
CPU:   Industrial temperature grade (-40C to 105C) at 31C
Reset cause: POR
Board: MX6EXCEET
DRAM:  1 GiB
NAND:  256 MiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1
SF: Detected EN25Q80 with page size 256 Bytes, erase size 4 KiB, total 1 MiB
No panel detected: default to Hannstar-XGA
Display: Hannstar-XGA (1024x768)
In:    serial
Out:   serial
Err:   serial
Net:   Found Micrel KS8051/KS8081 PHY
FEC
Hit any key to stop autoboot:  0
=> usb start
starting USB...
USB0:   Port not available.
USB1:   USB EHCI 1.00
scanning bus 1 for devices... 2 USB Device(s) found
        scanning usb for storage devices... 1 Storage Device(s) found
        scanning usb for ethernet devices... 0 Ethernet Device(s) found
=> fatload usb 0 0x18000000 test.file
reading test.file
EHCI timed out on TD - token=0xac008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x128d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x801f8c80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x801f8c80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x801f8c80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x801f8c80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
Error reading cluster
** Unable to read file test.file **

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
  2016-02-02 10:35 [U-Boot] Issue with USB mass storage (thumb drives) Schrempf Frieder
@ 2016-02-02 16:28 ` Fabio Estevam
  2016-02-02 16:39   ` Marek Vasut
  0 siblings, 1 reply; 52+ messages in thread
From: Fabio Estevam @ 2016-02-02 16:28 UTC (permalink / raw)
  To: u-boot

Adding Marek in case he has any ideas.

On Tue, Feb 2, 2016 at 8:35 AM, Schrempf Frieder
<frieder.schrempf@exceet.de> wrote:
> Hello,
>
> I'm using U-Boot on a custom i.MX6 board and I'm having problems while
> reading (large) files from USB thumb drives.
> I wouldn't really mind if this only happened with some specific USB
> device, but the problem occurs with 3 out of 4 tested thumb drives while
> loading a 100M test file.
> The devices that work seem to be rather old ones.
>
> The same issue is also reported here:
> https://community.freescale.com/thread/377911
>
> I can reproduce this behaviour with u-boot-imx v2014.04 and with
> mainline u-boot v2015.10 and v2016.01.
>
> Can someone tell me if this is a known issue?
> What could be the reason for this and how can I get this working?
>
> Thanks!
>
>
> U-Boot 2016.01 (Feb 02 2016 - 10:31:32 +0100)
>
> CPU:   Freescale i.MX6SOLO rev1.3 at 792MHz
> CPU:   Industrial temperature grade (-40C to 105C) at 31C
> Reset cause: POR
> Board: MX6EXCEET
> DRAM:  1 GiB
> NAND:  256 MiB
> MMC:   FSL_SDHC: 0, FSL_SDHC: 1
> SF: Detected EN25Q80 with page size 256 Bytes, erase size 4 KiB, total 1 MiB
> No panel detected: default to Hannstar-XGA
> Display: Hannstar-XGA (1024x768)
> In:    serial
> Out:   serial
> Err:   serial
> Net:   Found Micrel KS8051/KS8081 PHY
> FEC
> Hit any key to stop autoboot:  0
> => usb start
> starting USB...
> USB0:   Port not available.
> USB1:   USB EHCI 1.00
> scanning bus 1 for devices... 2 USB Device(s) found
>         scanning usb for storage devices... 1 Storage Device(s) found
>         scanning usb for ethernet devices... 0 Ethernet Device(s) found
> => fatload usb 0 0x18000000 test.file
> reading test.file
> EHCI timed out on TD - token=0xac008d80
> EHCI timed out on TD - token=0x80008d80
> EHCI timed out on TD - token=0x80008d80
> EHCI timed out on TD - token=0x80008d80
> EHCI timed out on TD - token=0x128d80
> EHCI timed out on TD - token=0x80008d80
> EHCI timed out on TD - token=0x80008d80
> EHCI timed out on TD - token=0x80008d80
> EHCI timed out on TD - token=0x801f8c80
> EHCI timed out on TD - token=0x80008d80
> EHCI timed out on TD - token=0x80008d80
> EHCI timed out on TD - token=0x80008d80
> EHCI timed out on TD - token=0x801f8c80
> EHCI timed out on TD - token=0x80008d80
> EHCI timed out on TD - token=0x80008d80
> EHCI timed out on TD - token=0x80008d80
> EHCI timed out on TD - token=0x801f8c80
> EHCI timed out on TD - token=0x80008d80
> EHCI timed out on TD - token=0x80008d80
> EHCI timed out on TD - token=0x80008d80
> EHCI timed out on TD - token=0x801f8c80
> EHCI timed out on TD - token=0x80008d80
> EHCI timed out on TD - token=0x80008d80
> EHCI timed out on TD - token=0x80008d80
> Error reading cluster
> ** Unable to read file test.file **

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
  2016-02-02 16:28 ` Fabio Estevam
@ 2016-02-02 16:39   ` Marek Vasut
  2016-02-03  7:40     ` Schrempf Frieder
  0 siblings, 1 reply; 52+ messages in thread
From: Marek Vasut @ 2016-02-02 16:39 UTC (permalink / raw)
  To: u-boot

On Tuesday, February 02, 2016 at 05:28:42 PM, Fabio Estevam wrote:
> Adding Marek in case he has any ideas.
> 
> On Tue, Feb 2, 2016 at 8:35 AM, Schrempf Frieder
> 
> <frieder.schrempf@exceet.de> wrote:
> > Hello,
> > 
> > I'm using U-Boot on a custom i.MX6 board and I'm having problems while
> > reading (large) files from USB thumb drives.
> > I wouldn't really mind if this only happened with some specific USB
> > device, but the problem occurs with 3 out of 4 tested thumb drives while
> > loading a 100M test file.
> > The devices that work seem to be rather old ones.
> > 
> > The same issue is also reported here:
> > https://community.freescale.com/thread/377911
> > 
> > I can reproduce this behaviour with u-boot-imx v2014.04 and with
> > mainline u-boot v2015.10 and v2016.01.
> > 
> > Can someone tell me if this is a known issue?
> > What could be the reason for this and how can I get this working?
> > 
> > Thanks!
> > 
> > 
> > U-Boot 2016.01 (Feb 02 2016 - 10:31:32 +0100)
> > 
> > CPU:   Freescale i.MX6SOLO rev1.3 at 792MHz
> > CPU:   Industrial temperature grade (-40C to 105C) at 31C
> > Reset cause: POR
> > Board: MX6EXCEET
> > DRAM:  1 GiB
> > NAND:  256 MiB
> > MMC:   FSL_SDHC: 0, FSL_SDHC: 1
> > SF: Detected EN25Q80 with page size 256 Bytes, erase size 4 KiB, total 1
> > MiB No panel detected: default to Hannstar-XGA
> > Display: Hannstar-XGA (1024x768)
> > In:    serial
> > Out:   serial
> > Err:   serial
> > Net:   Found Micrel KS8051/KS8081 PHY
> > FEC
> > Hit any key to stop autoboot:  0
> > => usb start
> > starting USB...
> > USB0:   Port not available.
> > USB1:   USB EHCI 1.00
> > scanning bus 1 for devices... 2 USB Device(s) found
> > 
> >         scanning usb for storage devices... 1 Storage Device(s) found
> >         scanning usb for ethernet devices... 0 Ethernet Device(s) found
> > 
> > => fatload usb 0 0x18000000 test.file
> > reading test.file
> > EHCI timed out on TD - token=0xac008d80
> > EHCI timed out on TD - token=0x80008d80
> > EHCI timed out on TD - token=0x80008d80
> > EHCI timed out on TD - token=0x80008d80
> > EHCI timed out on TD - token=0x128d80
> > EHCI timed out on TD - token=0x80008d80
> > EHCI timed out on TD - token=0x80008d80
> > EHCI timed out on TD - token=0x80008d80
> > EHCI timed out on TD - token=0x801f8c80
> > EHCI timed out on TD - token=0x80008d80
> > EHCI timed out on TD - token=0x80008d80
> > EHCI timed out on TD - token=0x80008d80
> > EHCI timed out on TD - token=0x801f8c80
> > EHCI timed out on TD - token=0x80008d80
> > EHCI timed out on TD - token=0x80008d80
> > EHCI timed out on TD - token=0x80008d80
> > EHCI timed out on TD - token=0x801f8c80
> > EHCI timed out on TD - token=0x80008d80
> > EHCI timed out on TD - token=0x80008d80
> > EHCI timed out on TD - token=0x80008d80
> > EHCI timed out on TD - token=0x801f8c80
> > EHCI timed out on TD - token=0x80008d80
> > EHCI timed out on TD - token=0x80008d80
> > EHCI timed out on TD - token=0x80008d80
> > Error reading cluster
> > ** Unable to read file test.file **

What happens if you do 'dcache off' and then read the file ?

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
  2016-02-02 16:39   ` Marek Vasut
@ 2016-02-03  7:40     ` Schrempf Frieder
  2016-02-03  7:45       ` Hannes Schmelzer
  2016-02-03  9:40       ` Marek Vasut
  0 siblings, 2 replies; 52+ messages in thread
From: Schrempf Frieder @ 2016-02-03  7:40 UTC (permalink / raw)
  To: u-boot

On 02.02.2016 17:39, Marek Vasut wrote:
> On Tuesday, February 02, 2016 at 05:28:42 PM, Fabio Estevam wrote:
>> Adding Marek in case he has any ideas.
>>
>> On Tue, Feb 2, 2016 at 8:35 AM, Schrempf Frieder
>>
>> <frieder.schrempf@exceet.de> wrote:
>>> Hello,
>>>
>>> I'm using U-Boot on a custom i.MX6 board and I'm having problems while
>>> reading (large) files from USB thumb drives.
>>> I wouldn't really mind if this only happened with some specific USB
>>> device, but the problem occurs with 3 out of 4 tested thumb drives while
>>> loading a 100M test file.
>>> The devices that work seem to be rather old ones.
>>>
>>> The same issue is also reported here:
>>> https://community.freescale.com/thread/377911
>>>
>>> I can reproduce this behaviour with u-boot-imx v2014.04 and with
>>> mainline u-boot v2015.10 and v2016.01.
>>>
>>> Can someone tell me if this is a known issue?
>>> What could be the reason for this and how can I get this working?
>>>
>>> Thanks!
>>>
>>>
>>> U-Boot 2016.01 (Feb 02 2016 - 10:31:32 +0100)
>>>
>>> CPU:   Freescale i.MX6SOLO rev1.3 at 792MHz
>>> CPU:   Industrial temperature grade (-40C to 105C) at 31C
>>> Reset cause: POR
>>> Board: MX6EXCEET
>>> DRAM:  1 GiB
>>> NAND:  256 MiB
>>> MMC:   FSL_SDHC: 0, FSL_SDHC: 1
>>> SF: Detected EN25Q80 with page size 256 Bytes, erase size 4 KiB, total 1
>>> MiB No panel detected: default to Hannstar-XGA
>>> Display: Hannstar-XGA (1024x768)
>>> In:    serial
>>> Out:   serial
>>> Err:   serial
>>> Net:   Found Micrel KS8051/KS8081 PHY
>>> FEC
>>> Hit any key to stop autoboot:  0
>>> => usb start
>>> starting USB...
>>> USB0:   Port not available.
>>> USB1:   USB EHCI 1.00
>>> scanning bus 1 for devices... 2 USB Device(s) found
>>>
>>>          scanning usb for storage devices... 1 Storage Device(s) found
>>>          scanning usb for ethernet devices... 0 Ethernet Device(s) found
>>>
>>> => fatload usb 0 0x18000000 test.file
>>> reading test.file
>>> EHCI timed out on TD - token=0xac008d80
>>> EHCI timed out on TD - token=0x80008d80
>>> EHCI timed out on TD - token=0x80008d80
>>> EHCI timed out on TD - token=0x80008d80
>>> EHCI timed out on TD - token=0x128d80
>>> EHCI timed out on TD - token=0x80008d80
>>> EHCI timed out on TD - token=0x80008d80
>>> EHCI timed out on TD - token=0x80008d80
>>> EHCI timed out on TD - token=0x801f8c80
>>> EHCI timed out on TD - token=0x80008d80
>>> EHCI timed out on TD - token=0x80008d80
>>> EHCI timed out on TD - token=0x80008d80
>>> EHCI timed out on TD - token=0x801f8c80
>>> EHCI timed out on TD - token=0x80008d80
>>> EHCI timed out on TD - token=0x80008d80
>>> EHCI timed out on TD - token=0x80008d80
>>> EHCI timed out on TD - token=0x801f8c80
>>> EHCI timed out on TD - token=0x80008d80
>>> EHCI timed out on TD - token=0x80008d80
>>> EHCI timed out on TD - token=0x80008d80
>>> EHCI timed out on TD - token=0x801f8c80
>>> EHCI timed out on TD - token=0x80008d80
>>> EHCI timed out on TD - token=0x80008d80
>>> EHCI timed out on TD - token=0x80008d80
>>> Error reading cluster
>>> ** Unable to read file test.file **
> What happens if you do 'dcache off' and then read the file ?
Unfortunately turning off dcache doesn't seem to change the behaviour.
I'm still getting the same error messages.

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
  2016-02-03  7:40     ` Schrempf Frieder
@ 2016-02-03  7:45       ` Hannes Schmelzer
  2016-02-03  9:34         ` Marek Vasut
  2016-02-03  9:40       ` Marek Vasut
  1 sibling, 1 reply; 52+ messages in thread
From: Hannes Schmelzer @ 2016-02-03  7:45 UTC (permalink / raw)
  To: u-boot

Hi there,

i can osberve same strange thing on Xilinx ZYNQ.

But really strange is:
I'm having a couple of USB-sticks on my desk, about 5pcs.
Exactly one of them is working without any trouble.

My testfile is ~16MB, with the magic usb-stick i can read the whole 16MB 
without errors.
With all the other sticks i get this timeouts.

best regards,
Hannes

On 02/03/2016 08:40 AM, Schrempf Frieder wrote:
> On 02.02.2016 17:39, Marek Vasut wrote:
>> On Tuesday, February 02, 2016 at 05:28:42 PM, Fabio Estevam wrote:
>>> Adding Marek in case he has any ideas.
>>>
>>> On Tue, Feb 2, 2016 at 8:35 AM, Schrempf Frieder
>>>
>>> <frieder.schrempf@exceet.de> wrote:
>>>> Hello,
>>>>
>>>> I'm using U-Boot on a custom i.MX6 board and I'm having problems while
>>>> reading (large) files from USB thumb drives.
>>>> I wouldn't really mind if this only happened with some specific USB
>>>> device, but the problem occurs with 3 out of 4 tested thumb drives while
>>>> loading a 100M test file.
>>>> The devices that work seem to be rather old ones.
>>>>
>>>> The same issue is also reported here:
>>>> https://community.freescale.com/thread/377911
>>>>
>>>> I can reproduce this behaviour with u-boot-imx v2014.04 and with
>>>> mainline u-boot v2015.10 and v2016.01.
>>>>
>>>> Can someone tell me if this is a known issue?
>>>> What could be the reason for this and how can I get this working?
>>>>
>>>> Thanks!
>>>>
>>>>
>>>> U-Boot 2016.01 (Feb 02 2016 - 10:31:32 +0100)
>>>>
>>>> CPU:   Freescale i.MX6SOLO rev1.3 at 792MHz
>>>> CPU:   Industrial temperature grade (-40C to 105C) at 31C
>>>> Reset cause: POR
>>>> Board: MX6EXCEET
>>>> DRAM:  1 GiB
>>>> NAND:  256 MiB
>>>> MMC:   FSL_SDHC: 0, FSL_SDHC: 1
>>>> SF: Detected EN25Q80 with page size 256 Bytes, erase size 4 KiB, total 1
>>>> MiB No panel detected: default to Hannstar-XGA
>>>> Display: Hannstar-XGA (1024x768)
>>>> In:    serial
>>>> Out:   serial
>>>> Err:   serial
>>>> Net:   Found Micrel KS8051/KS8081 PHY
>>>> FEC
>>>> Hit any key to stop autoboot:  0
>>>> => usb start
>>>> starting USB...
>>>> USB0:   Port not available.
>>>> USB1:   USB EHCI 1.00
>>>> scanning bus 1 for devices... 2 USB Device(s) found
>>>>
>>>>           scanning usb for storage devices... 1 Storage Device(s) found
>>>>           scanning usb for ethernet devices... 0 Ethernet Device(s) found
>>>>
>>>> => fatload usb 0 0x18000000 test.file
>>>> reading test.file
>>>> EHCI timed out on TD - token=0xac008d80
>>>> EHCI timed out on TD - token=0x80008d80
>>>> EHCI timed out on TD - token=0x80008d80
>>>> EHCI timed out on TD - token=0x80008d80
>>>> EHCI timed out on TD - token=0x128d80
>>>> EHCI timed out on TD - token=0x80008d80
>>>> EHCI timed out on TD - token=0x80008d80
>>>> EHCI timed out on TD - token=0x80008d80
>>>> EHCI timed out on TD - token=0x801f8c80
>>>> EHCI timed out on TD - token=0x80008d80
>>>> EHCI timed out on TD - token=0x80008d80
>>>> EHCI timed out on TD - token=0x80008d80
>>>> EHCI timed out on TD - token=0x801f8c80
>>>> EHCI timed out on TD - token=0x80008d80
>>>> EHCI timed out on TD - token=0x80008d80
>>>> EHCI timed out on TD - token=0x80008d80
>>>> EHCI timed out on TD - token=0x801f8c80
>>>> EHCI timed out on TD - token=0x80008d80
>>>> EHCI timed out on TD - token=0x80008d80
>>>> EHCI timed out on TD - token=0x80008d80
>>>> EHCI timed out on TD - token=0x801f8c80
>>>> EHCI timed out on TD - token=0x80008d80
>>>> EHCI timed out on TD - token=0x80008d80
>>>> EHCI timed out on TD - token=0x80008d80
>>>> Error reading cluster
>>>> ** Unable to read file test.file **
>> What happens if you do 'dcache off' and then read the file ?
> Unfortunately turning off dcache doesn't seem to change the behaviour.
> I'm still getting the same error messages.

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
  2016-02-03  7:45       ` Hannes Schmelzer
@ 2016-02-03  9:34         ` Marek Vasut
  0 siblings, 0 replies; 52+ messages in thread
From: Marek Vasut @ 2016-02-03  9:34 UTC (permalink / raw)
  To: u-boot

On Wednesday, February 03, 2016 at 08:45:27 AM, Hannes Schmelzer wrote:
> Hi there,

Please do not top-post

> i can osberve same strange thing on Xilinx ZYNQ.
> 
> But really strange is:
> I'm having a couple of USB-sticks on my desk, about 5pcs.
> Exactly one of them is working without any trouble.
> 
> My testfile is ~16MB, with the magic usb-stick i can read the whole 16MB
> without errors.
> With all the other sticks i get this timeouts.

CCing Michal for zynq issues.

> best regards,
> Hannes
> 
> On 02/03/2016 08:40 AM, Schrempf Frieder wrote:
> > On 02.02.2016 17:39, Marek Vasut wrote:
> >> On Tuesday, February 02, 2016 at 05:28:42 PM, Fabio Estevam wrote:
> >>> Adding Marek in case he has any ideas.
> >>> 
> >>> On Tue, Feb 2, 2016 at 8:35 AM, Schrempf Frieder
> >>> 
> >>> <frieder.schrempf@exceet.de> wrote:
> >>>> Hello,
> >>>> 
> >>>> I'm using U-Boot on a custom i.MX6 board and I'm having problems while
> >>>> reading (large) files from USB thumb drives.
> >>>> I wouldn't really mind if this only happened with some specific USB
> >>>> device, but the problem occurs with 3 out of 4 tested thumb drives
> >>>> while loading a 100M test file.
> >>>> The devices that work seem to be rather old ones.
> >>>> 
> >>>> The same issue is also reported here:
> >>>> https://community.freescale.com/thread/377911
> >>>> 
> >>>> I can reproduce this behaviour with u-boot-imx v2014.04 and with
> >>>> mainline u-boot v2015.10 and v2016.01.
> >>>> 
> >>>> Can someone tell me if this is a known issue?
> >>>> What could be the reason for this and how can I get this working?
> >>>> 
> >>>> Thanks!
> >>>> 
> >>>> 
> >>>> U-Boot 2016.01 (Feb 02 2016 - 10:31:32 +0100)
> >>>> 
> >>>> CPU:   Freescale i.MX6SOLO rev1.3 at 792MHz
> >>>> CPU:   Industrial temperature grade (-40C to 105C) at 31C
> >>>> Reset cause: POR
> >>>> Board: MX6EXCEET
> >>>> DRAM:  1 GiB
> >>>> NAND:  256 MiB
> >>>> MMC:   FSL_SDHC: 0, FSL_SDHC: 1
> >>>> SF: Detected EN25Q80 with page size 256 Bytes, erase size 4 KiB, total
> >>>> 1 MiB No panel detected: default to Hannstar-XGA
> >>>> Display: Hannstar-XGA (1024x768)
> >>>> In:    serial
> >>>> Out:   serial
> >>>> Err:   serial
> >>>> Net:   Found Micrel KS8051/KS8081 PHY
> >>>> FEC
> >>>> Hit any key to stop autoboot:  0
> >>>> => usb start
> >>>> starting USB...
> >>>> USB0:   Port not available.
> >>>> USB1:   USB EHCI 1.00
> >>>> scanning bus 1 for devices... 2 USB Device(s) found
> >>>> 
> >>>>           scanning usb for storage devices... 1 Storage Device(s)
> >>>>           found scanning usb for ethernet devices... 0 Ethernet
> >>>>           Device(s) found
> >>>> 
> >>>> => fatload usb 0 0x18000000 test.file
> >>>> reading test.file
> >>>> EHCI timed out on TD - token=0xac008d80
> >>>> EHCI timed out on TD - token=0x80008d80
> >>>> EHCI timed out on TD - token=0x80008d80
> >>>> EHCI timed out on TD - token=0x80008d80
> >>>> EHCI timed out on TD - token=0x128d80
> >>>> EHCI timed out on TD - token=0x80008d80
> >>>> EHCI timed out on TD - token=0x80008d80
> >>>> EHCI timed out on TD - token=0x80008d80
> >>>> EHCI timed out on TD - token=0x801f8c80
> >>>> EHCI timed out on TD - token=0x80008d80
> >>>> EHCI timed out on TD - token=0x80008d80
> >>>> EHCI timed out on TD - token=0x80008d80
> >>>> EHCI timed out on TD - token=0x801f8c80
> >>>> EHCI timed out on TD - token=0x80008d80
> >>>> EHCI timed out on TD - token=0x80008d80
> >>>> EHCI timed out on TD - token=0x80008d80
> >>>> EHCI timed out on TD - token=0x801f8c80
> >>>> EHCI timed out on TD - token=0x80008d80
> >>>> EHCI timed out on TD - token=0x80008d80
> >>>> EHCI timed out on TD - token=0x80008d80
> >>>> EHCI timed out on TD - token=0x801f8c80
> >>>> EHCI timed out on TD - token=0x80008d80
> >>>> EHCI timed out on TD - token=0x80008d80
> >>>> EHCI timed out on TD - token=0x80008d80
> >>>> Error reading cluster
> >>>> ** Unable to read file test.file **
> >> 
> >> What happens if you do 'dcache off' and then read the file ?
> > 
> > Unfortunately turning off dcache doesn't seem to change the behaviour.
> > I'm still getting the same error messages.

Best regards,
Marek Vasut

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
  2016-02-03  7:40     ` Schrempf Frieder
  2016-02-03  7:45       ` Hannes Schmelzer
@ 2016-02-03  9:40       ` Marek Vasut
  2016-02-03  9:55         ` Fabio Estevam
  1 sibling, 1 reply; 52+ messages in thread
From: Marek Vasut @ 2016-02-03  9:40 UTC (permalink / raw)
  To: u-boot

On Wednesday, February 03, 2016 at 08:40:00 AM, Schrempf Frieder wrote:
> On 02.02.2016 17:39, Marek Vasut wrote:
> > On Tuesday, February 02, 2016 at 05:28:42 PM, Fabio Estevam wrote:
> >> Adding Marek in case he has any ideas.
> >> 
> >> On Tue, Feb 2, 2016 at 8:35 AM, Schrempf Frieder
> >> 
> >> <frieder.schrempf@exceet.de> wrote:
> >>> Hello,
> >>> 
> >>> I'm using U-Boot on a custom i.MX6 board and I'm having problems while
> >>> reading (large) files from USB thumb drives.
> >>> I wouldn't really mind if this only happened with some specific USB
> >>> device, but the problem occurs with 3 out of 4 tested thumb drives
> >>> while loading a 100M test file.
> >>> The devices that work seem to be rather old ones.
> >>> 
> >>> The same issue is also reported here:
> >>> https://community.freescale.com/thread/377911
> >>> 
> >>> I can reproduce this behaviour with u-boot-imx v2014.04 and with
> >>> mainline u-boot v2015.10 and v2016.01.
> >>> 
> >>> Can someone tell me if this is a known issue?
> >>> What could be the reason for this and how can I get this working?
> >>> 
> >>> Thanks!
> >>> 
> >>> 
> >>> U-Boot 2016.01 (Feb 02 2016 - 10:31:32 +0100)
> >>> 
> >>> CPU:   Freescale i.MX6SOLO rev1.3 at 792MHz
> >>> CPU:   Industrial temperature grade (-40C to 105C) at 31C
> >>> Reset cause: POR
> >>> Board: MX6EXCEET
> >>> DRAM:  1 GiB
> >>> NAND:  256 MiB
> >>> MMC:   FSL_SDHC: 0, FSL_SDHC: 1
> >>> SF: Detected EN25Q80 with page size 256 Bytes, erase size 4 KiB, total
> >>> 1 MiB No panel detected: default to Hannstar-XGA
> >>> Display: Hannstar-XGA (1024x768)
> >>> In:    serial
> >>> Out:   serial
> >>> Err:   serial
> >>> Net:   Found Micrel KS8051/KS8081 PHY
> >>> FEC
> >>> Hit any key to stop autoboot:  0
> >>> => usb start
> >>> starting USB...
> >>> USB0:   Port not available.
> >>> USB1:   USB EHCI 1.00
> >>> scanning bus 1 for devices... 2 USB Device(s) found
> >>> 
> >>>          scanning usb for storage devices... 1 Storage Device(s) found
> >>>          scanning usb for ethernet devices... 0 Ethernet Device(s)
> >>>          found
> >>> 
> >>> => fatload usb 0 0x18000000 test.file
> >>> reading test.file
> >>> EHCI timed out on TD - token=0xac008d80
> >>> EHCI timed out on TD - token=0x80008d80
> >>> EHCI timed out on TD - token=0x80008d80
> >>> EHCI timed out on TD - token=0x80008d80
> >>> EHCI timed out on TD - token=0x128d80
> >>> EHCI timed out on TD - token=0x80008d80
> >>> EHCI timed out on TD - token=0x80008d80
> >>> EHCI timed out on TD - token=0x80008d80
> >>> EHCI timed out on TD - token=0x801f8c80
> >>> EHCI timed out on TD - token=0x80008d80
> >>> EHCI timed out on TD - token=0x80008d80
> >>> EHCI timed out on TD - token=0x80008d80
> >>> EHCI timed out on TD - token=0x801f8c80
> >>> EHCI timed out on TD - token=0x80008d80
> >>> EHCI timed out on TD - token=0x80008d80
> >>> EHCI timed out on TD - token=0x80008d80
> >>> EHCI timed out on TD - token=0x801f8c80
> >>> EHCI timed out on TD - token=0x80008d80
> >>> EHCI timed out on TD - token=0x80008d80
> >>> EHCI timed out on TD - token=0x80008d80
> >>> EHCI timed out on TD - token=0x801f8c80
> >>> EHCI timed out on TD - token=0x80008d80
> >>> EHCI timed out on TD - token=0x80008d80
> >>> EHCI timed out on TD - token=0x80008d80
> >>> Error reading cluster
> >>> ** Unable to read file test.file **
> > 
> > What happens if you do 'dcache off' and then read the file ?
> 
> Unfortunately turning off dcache doesn't seem to change the behaviour.
> I'm still getting the same error messages.

In that case, debug time.

Usual problems are bad routing of the tracks on the board , so try with USB 1.1
hub and if that works, that's your problem.

You can also try "setenv usb_pgood_delay 10000" , this will increase the time
the code takes after reseting root port.

Also try adding #define DEBUG to drivers/usb/host/ehci-hcd.c common/usb.c and 
common/usb_hub.c . You might notice something odd there.

The above output shows that your qTD tokens are not processed , see the active
bit being set. Details in [1] page 54 (Table 3-16).

[1] http://www.intel.com/content/dam/www/public/us/en/documents/technical-
specifications/ehci-specification-for-usb.pdf

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
  2016-02-03  9:40       ` Marek Vasut
@ 2016-02-03  9:55         ` Fabio Estevam
  2016-02-03 10:15           ` Schrempf Frieder
  0 siblings, 1 reply; 52+ messages in thread
From: Fabio Estevam @ 2016-02-03  9:55 UTC (permalink / raw)
  To: u-boot

On Wed, Feb 3, 2016 at 7:40 AM, Marek Vasut <marex@denx.de> wrote:

>
> In that case, debug time.
>
> Usual problems are bad routing of the tracks on the board , so try with USB 1.1
> hub and if that works, that's your problem.

Another suggestion would be to try the 100MB transfer in Linux and see
if this works or not.

That would help us to narrow down whether this is a hardware or
software problem.

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
  2016-02-03  9:55         ` Fabio Estevam
@ 2016-02-03 10:15           ` Schrempf Frieder
  2016-02-03 11:12             ` Marek Vasut
  0 siblings, 1 reply; 52+ messages in thread
From: Schrempf Frieder @ 2016-02-03 10:15 UTC (permalink / raw)
  To: u-boot

On 03.02.2016 10:55, Fabio Estevam wrote:
> On Wed, Feb 3, 2016 at 7:40 AM, Marek Vasut <marex@denx.de> wrote:
>
>> In that case, debug time.
>>
>> Usual problems are bad routing of the tracks on the board , so try with USB 1.1
>> hub and if that works, that's your problem.
> Another suggestion would be to try the 100MB transfer in Linux and see
> if this works or not.
>
> That would help us to narrow down whether this is a hardware or
> software problem.

Thank you Marek and Fabio for your input!

I tried the file transfer in Linux and this seems to work fine.
Also we have been using this hardware for quite some time, also with USB 
mass storage and large files in Linux and I can't remember any problems.
For these reasons I think that the hardware is ok.

I added the DEBUG defines and here are the lines around one of the timeouts.
With my very limited knowledge of how usb works, I can't read much from 
those messages:

dev=4ffa58e0, pipe=c0008483, buffer=4f50a1a0, length=13, req=00000000
TOKEN=0x8d00
dev=4ffa58e0, pipe=c0010403, buffer=4f50a1c0, length=31, req=00000000
TOKEN=0x80008c01
dev=4ffa58e0, pipe=c0008483, buffer=18000000, length=33553920, req=00000000
TOKEN=0x80009d00
dev=4ffa58e0, pipe=c0008483, buffer=4f50a180, length=13, req=00000000
TOKEN=0x8d00
dev=4ffa58e0, pipe=c0010403, buffer=4f50a1c0, length=31, req=00000000
TOKEN=0x8c01
dev=4ffa58e0, pipe=c0008483, buffer=19fffe00, length=33553920, req=00000000
EHCI timed out on TD - token=0xac008d80
dev=4, usbsts=0x40088, p[1]=0x18001205, p[2]=0x0
usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 
length 0x0
dev=4ffa58e0, pipe=80000403, buffer=00000000, length=0, req=4f50a100
req=255 (0xff), type=33 (0x21), value=0 (0x0), index=0
TOKEN=0x8d00
usb_control_msg: request: 0x1, requesttype: 0x2, value 0x0 index 0x81 
length 0x0
dev=4ffa58e0, pipe=80000403, buffer=00000000, length=0, req=4f50a0c0
req=1 (0x1), type=2 (0x2), value=0 (0x0), index=129
TOKEN=0x8d00
usb_control_msg: request: 0x1, requesttype: 0x2, value 0x0 index 0x2 
length 0x0
dev=4ffa58e0, pipe=80000403, buffer=00000000, length=0, req=4f50a0c0
req=1 (0x1), type=2 (0x2), value=0 (0x0), index=2
TOKEN=0x8d00
dev=4ffa58e0, pipe=c0010403, buffer=4f50a1c0, length=31, req=00000000
TOKEN=0x80008c01
dev=4ffa58e0, pipe=c0008483, buffer=4ffb6d40, length=18, req=00000000
TOKEN=0x80008d00
dev=4ffa58e0, pipe=c0008483, buffer=4f50a180, length=13, req=00000000
TOKEN=0x8d00

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
  2016-02-03 10:15           ` Schrempf Frieder
@ 2016-02-03 11:12             ` Marek Vasut
  2016-02-03 11:49               ` Schrempf Frieder
  0 siblings, 1 reply; 52+ messages in thread
From: Marek Vasut @ 2016-02-03 11:12 UTC (permalink / raw)
  To: u-boot

On Wednesday, February 03, 2016 at 11:15:00 AM, Schrempf Frieder wrote:
> On 03.02.2016 10:55, Fabio Estevam wrote:
> > On Wed, Feb 3, 2016 at 7:40 AM, Marek Vasut <marex@denx.de> wrote:
> >> In that case, debug time.
> >> 
> >> Usual problems are bad routing of the tracks on the board , so try with
> >> USB 1.1 hub and if that works, that's your problem.
> > 
> > Another suggestion would be to try the 100MB transfer in Linux and see
> > if this works or not.
> > 
> > That would help us to narrow down whether this is a hardware or
> > software problem.
> 
> Thank you Marek and Fabio for your input!
> 
> I tried the file transfer in Linux and this seems to work fine.
> Also we have been using this hardware for quite some time, also with USB
> mass storage and large files in Linux and I can't remember any problems.
> For these reasons I think that the hardware is ok.
> 
> I added the DEBUG defines and here are the lines around one of the
> timeouts. With my very limited knowledge of how usb works, I can't read
> much from those messages:

It'd help if you shared your patch and the whole output. That way we can
check if something goes wrong at the beginning.

I wonder if we might be facing some misconfiguration of the USB PHY here ?

I don't have a MX6Solo . Fabio, any chance you can try ?

> dev=4ffa58e0, pipe=c0008483, buffer=4f50a1a0, length=13, req=00000000
> TOKEN=0x8d00
> dev=4ffa58e0, pipe=c0010403, buffer=4f50a1c0, length=31, req=00000000
> TOKEN=0x80008c01
> dev=4ffa58e0, pipe=c0008483, buffer=18000000, length=33553920, req=00000000
> TOKEN=0x80009d00
> dev=4ffa58e0, pipe=c0008483, buffer=4f50a180, length=13, req=00000000
> TOKEN=0x8d00
> dev=4ffa58e0, pipe=c0010403, buffer=4f50a1c0, length=31, req=00000000
> TOKEN=0x8c01
> dev=4ffa58e0, pipe=c0008483, buffer=19fffe00, length=33553920, req=00000000
> EHCI timed out on TD - token=0xac008d80
> dev=4, usbsts=0x40088, p[1]=0x18001205, p[2]=0x0
> usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0
> length 0x0
> dev=4ffa58e0, pipe=80000403, buffer=00000000, length=0, req=4f50a100
> req=255 (0xff), type=33 (0x21), value=0 (0x0), index=0
> TOKEN=0x8d00
> usb_control_msg: request: 0x1, requesttype: 0x2, value 0x0 index 0x81
> length 0x0
> dev=4ffa58e0, pipe=80000403, buffer=00000000, length=0, req=4f50a0c0
> req=1 (0x1), type=2 (0x2), value=0 (0x0), index=129
> TOKEN=0x8d00
> usb_control_msg: request: 0x1, requesttype: 0x2, value 0x0 index 0x2
> length 0x0
> dev=4ffa58e0, pipe=80000403, buffer=00000000, length=0, req=4f50a0c0
> req=1 (0x1), type=2 (0x2), value=0 (0x0), index=2
> TOKEN=0x8d00
> dev=4ffa58e0, pipe=c0010403, buffer=4f50a1c0, length=31, req=00000000
> TOKEN=0x80008c01
> dev=4ffa58e0, pipe=c0008483, buffer=4ffb6d40, length=18, req=00000000
> TOKEN=0x80008d00
> dev=4ffa58e0, pipe=c0008483, buffer=4f50a180, length=13, req=00000000
> TOKEN=0x8d00

Best regards,
Marek Vasut

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
  2016-02-03 11:12             ` Marek Vasut
@ 2016-02-03 11:49               ` Schrempf Frieder
  2016-02-03 16:40                 ` Marek Vasut
  0 siblings, 1 reply; 52+ messages in thread
From: Schrempf Frieder @ 2016-02-03 11:49 UTC (permalink / raw)
  To: u-boot

On 03.02.2016 12:12, Marek Vasut wrote:
> On Wednesday, February 03, 2016 at 11:15:00 AM, Schrempf Frieder wrote:
>> On 03.02.2016 10:55, Fabio Estevam wrote:
>>> On Wed, Feb 3, 2016 at 7:40 AM, Marek Vasut <marex@denx.de> wrote:
>>>> In that case, debug time.
>>>>
>>>> Usual problems are bad routing of the tracks on the board , so try with
>>>> USB 1.1 hub and if that works, that's your problem.
>>> Another suggestion would be to try the 100MB transfer in Linux and see
>>> if this works or not.
>>>
>>> That would help us to narrow down whether this is a hardware or
>>> software problem.
>> Thank you Marek and Fabio for your input!
>>
>> I tried the file transfer in Linux and this seems to work fine.
>> Also we have been using this hardware for quite some time, also with USB
>> mass storage and large files in Linux and I can't remember any problems.
>> For these reasons I think that the hardware is ok.
>>
>> I added the DEBUG defines and here are the lines around one of the
>> timeouts. With my very limited knowledge of how usb works, I can't read
>> much from those messages:
> It'd help if you shared your patch and the whole output. That way we can
> check if something goes wrong at the beginning.
>
> I wonder if we might be facing some misconfiguration of the USB PHY here ?
>
> I don't have a MX6Solo . Fabio, any chance you can try ?

Here is the debug log for "usb reset": http://paste.ubuntu.com/14865306/
And here the log for the file transfer (different thumb drive and 
therefore different messages than posted before): 
http://paste.ubuntu.com/14865349/

The only changes to U-Boot I made is adding my board configuration 
(derived from Freescale SabreSD config).
The only difference from the SabreSD config related to USB is, that I 
have set CONFIG_USB_MAX_CONTROLLER_COUNT to 2 instead of 1.

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
  2016-02-03 11:49               ` Schrempf Frieder
@ 2016-02-03 16:40                 ` Marek Vasut
  2016-02-03 19:16                   ` Sergei Temerkhanov
  2016-02-04  8:06                   ` Schrempf Frieder
  0 siblings, 2 replies; 52+ messages in thread
From: Marek Vasut @ 2016-02-03 16:40 UTC (permalink / raw)
  To: u-boot

On Wednesday, February 03, 2016 at 12:49:20 PM, Schrempf Frieder wrote:
> On 03.02.2016 12:12, Marek Vasut wrote:
> > On Wednesday, February 03, 2016 at 11:15:00 AM, Schrempf Frieder wrote:
> >> On 03.02.2016 10:55, Fabio Estevam wrote:
> >>> On Wed, Feb 3, 2016 at 7:40 AM, Marek Vasut <marex@denx.de> wrote:
> >>>> In that case, debug time.
> >>>> 
> >>>> Usual problems are bad routing of the tracks on the board , so try
> >>>> with USB 1.1 hub and if that works, that's your problem.
> >>> 
> >>> Another suggestion would be to try the 100MB transfer in Linux and see
> >>> if this works or not.
> >>> 
> >>> That would help us to narrow down whether this is a hardware or
> >>> software problem.
> >> 
> >> Thank you Marek and Fabio for your input!
> >> 
> >> I tried the file transfer in Linux and this seems to work fine.
> >> Also we have been using this hardware for quite some time, also with USB
> >> mass storage and large files in Linux and I can't remember any problems.
> >> For these reasons I think that the hardware is ok.
> >> 
> >> I added the DEBUG defines and here are the lines around one of the
> >> timeouts. With my very limited knowledge of how usb works, I can't read
> > 
> >> much from those messages:
> > It'd help if you shared your patch and the whole output. That way we can
> > check if something goes wrong at the beginning.
> > 
> > I wonder if we might be facing some misconfiguration of the USB PHY here
> > ?
> > 
> > I don't have a MX6Solo . Fabio, any chance you can try ?
> 
> Here is the debug log for "usb reset": http://paste.ubuntu.com/14865306/
> And here the log for the file transfer (different thumb drive and
> therefore different messages than posted before):
> http://paste.ubuntu.com/14865349/
> 
> The only changes to U-Boot I made is adding my board configuration
> (derived from Freescale SabreSD config).
> The only difference from the SabreSD config related to USB is, that I
> have set CONFIG_USB_MAX_CONTROLLER_COUNT to 2 instead of 1.

The detection seems fine, it even does what it's supposed to do.

You have a USB hub somewhere in there, right ? Is it a powered one or not ?

What I find weird in the later log is that the failure always happens when
the buffer is at 0x19fffe00 . I suppose you're loading to 0x18000000 and you
have 0x20000000 or 512MiB of RAM (?). Try loading to 0x8000000 and see if
that helps. If it does, then you might be overwriting some malloc area of
U-Boot or somesuch .

Best regards,
Marek Vasut

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
  2016-02-03 16:40                 ` Marek Vasut
@ 2016-02-03 19:16                   ` Sergei Temerkhanov
  2016-02-04  8:21                     ` Schrempf Frieder
  2016-02-04  8:06                   ` Schrempf Frieder
  1 sibling, 1 reply; 52+ messages in thread
From: Sergei Temerkhanov @ 2016-02-03 19:16 UTC (permalink / raw)
  To: u-boot

On Wed, Feb 3, 2016 at 8:40 AM, Marek Vasut <marex@denx.de> wrote:
> On Wednesday, February 03, 2016 at 12:49:20 PM, Schrempf Frieder wrote:
>> On 03.02.2016 12:12, Marek Vasut wrote:
>> > On Wednesday, February 03, 2016 at 11:15:00 AM, Schrempf Frieder wrote:
>> >> On 03.02.2016 10:55, Fabio Estevam wrote:
>> >>> On Wed, Feb 3, 2016 at 7:40 AM, Marek Vasut <marex@denx.de> wrote:
>> >>>> In that case, debug time.
>> >>>>
>> >>>> Usual problems are bad routing of the tracks on the board , so try
>> >>>> with USB 1.1 hub and if that works, that's your problem.
>> >>>
>> >>> Another suggestion would be to try the 100MB transfer in Linux and see
>> >>> if this works or not.
>> >>>
>> >>> That would help us to narrow down whether this is a hardware or
>> >>> software problem.

Another thing to try may be limiting the value of USB_MAX_XFER_BLK in
common/usb_storage.c


Regards,
Sergey

>> >>
>> >> Thank you Marek and Fabio for your input!
>> >>
>> >> I tried the file transfer in Linux and this seems to work fine.
>> >> Also we have been using this hardware for quite some time, also with USB
>> >> mass storage and large files in Linux and I can't remember any problems.
>> >> For these reasons I think that the hardware is ok.
>> >>
>> >> I added the DEBUG defines and here are the lines around one of the
>> >> timeouts. With my very limited knowledge of how usb works, I can't read
>> >
>> >> much from those messages:
>> > It'd help if you shared your patch and the whole output. That way we can
>> > check if something goes wrong at the beginning.
>> >
>> > I wonder if we might be facing some misconfiguration of the USB PHY here
>> > ?
>> >
>> > I don't have a MX6Solo . Fabio, any chance you can try ?
>>
>> Here is the debug log for "usb reset": http://paste.ubuntu.com/14865306/
>> And here the log for the file transfer (different thumb drive and
>> therefore different messages than posted before):
>> http://paste.ubuntu.com/14865349/
>>
>> The only changes to U-Boot I made is adding my board configuration
>> (derived from Freescale SabreSD config).
>> The only difference from the SabreSD config related to USB is, that I
>> have set CONFIG_USB_MAX_CONTROLLER_COUNT to 2 instead of 1.
>
> The detection seems fine, it even does what it's supposed to do.
>
> You have a USB hub somewhere in there, right ? Is it a powered one or not ?
>
> What I find weird in the later log is that the failure always happens when
> the buffer is at 0x19fffe00 . I suppose you're loading to 0x18000000 and you
> have 0x20000000 or 512MiB of RAM (?). Try loading to 0x8000000 and see if
> that helps. If it does, then you might be overwriting some malloc area of
> U-Boot or somesuch .
>
> Best regards,
> Marek Vasut
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
  2016-02-03 16:40                 ` Marek Vasut
  2016-02-03 19:16                   ` Sergei Temerkhanov
@ 2016-02-04  8:06                   ` Schrempf Frieder
  1 sibling, 0 replies; 52+ messages in thread
From: Schrempf Frieder @ 2016-02-04  8:06 UTC (permalink / raw)
  To: u-boot

On 03.02.2016 17:40, Marek Vasut wrote:
> On Wednesday, February 03, 2016 at 12:49:20 PM, Schrempf Frieder wrote:
>> On 03.02.2016 12:12, Marek Vasut wrote:
>>> On Wednesday, February 03, 2016 at 11:15:00 AM, Schrempf Frieder wrote:
>>>> On 03.02.2016 10:55, Fabio Estevam wrote:
>>>>> On Wed, Feb 3, 2016 at 7:40 AM, Marek Vasut <marex@denx.de> wrote:
>>>>>> In that case, debug time.
>>>>>>
>>>>>> Usual problems are bad routing of the tracks on the board , so try
>>>>>> with USB 1.1 hub and if that works, that's your problem.
>>>>> Another suggestion would be to try the 100MB transfer in Linux and see
>>>>> if this works or not.
>>>>>
>>>>> That would help us to narrow down whether this is a hardware or
>>>>> software problem.
>>>> Thank you Marek and Fabio for your input!
>>>>
>>>> I tried the file transfer in Linux and this seems to work fine.
>>>> Also we have been using this hardware for quite some time, also with USB
>>>> mass storage and large files in Linux and I can't remember any problems.
>>>> For these reasons I think that the hardware is ok.
>>>>
>>>> I added the DEBUG defines and here are the lines around one of the
>>>> timeouts. With my very limited knowledge of how usb works, I can't read
>>>> much from those messages:
>>> It'd help if you shared your patch and the whole output. That way we can
>>> check if something goes wrong at the beginning.
>>>
>>> I wonder if we might be facing some misconfiguration of the USB PHY here
>>> ?
>>>
>>> I don't have a MX6Solo . Fabio, any chance you can try ?
>> Here is the debug log for "usb reset": http://paste.ubuntu.com/14865306/
>> And here the log for the file transfer (different thumb drive and
>> therefore different messages than posted before):
>> http://paste.ubuntu.com/14865349/
>>
>> The only changes to U-Boot I made is adding my board configuration
>> (derived from Freescale SabreSD config).
>> The only difference from the SabreSD config related to USB is, that I
>> have set CONFIG_USB_MAX_CONTROLLER_COUNT to 2 instead of 1.
> The detection seems fine, it even does what it's supposed to do.
>
> You have a USB hub somewhere in there, right ? Is it a powered one or not ?
>
> What I find weird in the later log is that the failure always happens when
> the buffer is at 0x19fffe00 . I suppose you're loading to 0x18000000 and you
> have 0x20000000 or 512MiB of RAM (?). Try loading to 0x8000000 and see if
> that helps. If it does, then you might be overwriting some malloc area of
> U-Boot or somesuch .

We have two self-powered USB hubs on our board, but we also have boards 
without any hub and I can see the same issue on those.

I tried loading to 0x8000000 and the strange thing is, that it even 
fails on those USB devices, that were previously working while loading 
to 0x18000000.

So reading fails on all USB devices I tried, when loading to 0x8000000 
with a log like this: http://paste.ubuntu.com/14875686/
But when I load to 0x18000000 I have 2 devices with 100% success rate: 
http://paste.ubuntu.com/14875795/
And 1 device with 100% failure rate: http://paste.ubuntu.com/14865349/

I even have 1GiB of RAM on this board.

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
  2016-02-03 19:16                   ` Sergei Temerkhanov
@ 2016-02-04  8:21                     ` Schrempf Frieder
  2016-02-04 11:28                       ` Marek Vasut
  0 siblings, 1 reply; 52+ messages in thread
From: Schrempf Frieder @ 2016-02-04  8:21 UTC (permalink / raw)
  To: u-boot

On 03.02.2016 20:16, Sergei Temerkhanov wrote:
> On Wed, Feb 3, 2016 at 8:40 AM, Marek Vasut <marex@denx.de> wrote:
>> On Wednesday, February 03, 2016 at 12:49:20 PM, Schrempf Frieder wrote:
>>> On 03.02.2016 12:12, Marek Vasut wrote:
>>>> On Wednesday, February 03, 2016 at 11:15:00 AM, Schrempf Frieder wrote:
>>>>> On 03.02.2016 10:55, Fabio Estevam wrote:
>>>>>> On Wed, Feb 3, 2016 at 7:40 AM, Marek Vasut <marex@denx.de> wrote:
>>>>>>> In that case, debug time.
>>>>>>>
>>>>>>> Usual problems are bad routing of the tracks on the board , so try
>>>>>>> with USB 1.1 hub and if that works, that's your problem.
>>>>>> Another suggestion would be to try the 100MB transfer in Linux and see
>>>>>> if this works or not.
>>>>>>
>>>>>> That would help us to narrow down whether this is a hardware or
>>>>>> software problem.
> Another thing to try may be limiting the value of USB_MAX_XFER_BLK in
> common/usb_storage.c

This was a really helpful hint! Thank you Sergei!

I just tried to limit USB_MAX_XFER_BLK to 1/8 of the original value 
(65535 -> 8191) and this time the transfer works without timeouts.

As we have a customer who needs this working as soon as possible my 
question now is how to properly solve this.
Should I generally limit USB_MAX_XFER_BLK in my u-boot to avoid these 
errors? Which value to choose?

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
  2016-02-04  8:21                     ` Schrempf Frieder
@ 2016-02-04 11:28                       ` Marek Vasut
  2016-02-08  8:41                         ` Hannes Schmelzer
  2016-02-18 10:05                         ` Schrempf Frieder
  0 siblings, 2 replies; 52+ messages in thread
From: Marek Vasut @ 2016-02-04 11:28 UTC (permalink / raw)
  To: u-boot

On Thursday, February 04, 2016 at 09:21:08 AM, Schrempf Frieder wrote:
> On 03.02.2016 20:16, Sergei Temerkhanov wrote:
> > On Wed, Feb 3, 2016 at 8:40 AM, Marek Vasut <marex@denx.de> wrote:
> >> On Wednesday, February 03, 2016 at 12:49:20 PM, Schrempf Frieder wrote:
> >>> On 03.02.2016 12:12, Marek Vasut wrote:
> >>>> On Wednesday, February 03, 2016 at 11:15:00 AM, Schrempf Frieder wrote:
> >>>>> On 03.02.2016 10:55, Fabio Estevam wrote:
> >>>>>> On Wed, Feb 3, 2016 at 7:40 AM, Marek Vasut <marex@denx.de> wrote:
> >>>>>>> In that case, debug time.
> >>>>>>> 
> >>>>>>> Usual problems are bad routing of the tracks on the board , so try
> >>>>>>> with USB 1.1 hub and if that works, that's your problem.
> >>>>>> 
> >>>>>> Another suggestion would be to try the 100MB transfer in Linux and
> >>>>>> see if this works or not.
> >>>>>> 
> >>>>>> That would help us to narrow down whether this is a hardware or
> >>>>>> software problem.
> > 
> > Another thing to try may be limiting the value of USB_MAX_XFER_BLK in
> > common/usb_storage.c
> 
> This was a really helpful hint! Thank you Sergei!
> 
> I just tried to limit USB_MAX_XFER_BLK to 1/8 of the original value
> (65535 -> 8191) and this time the transfer works without timeouts.
> 
> As we have a customer who needs this working as soon as possible my
> question now is how to properly solve this.
> Should I generally limit USB_MAX_XFER_BLK in my u-boot to avoid these
> errors? Which value to choose?

Nice! Can you share which sticks are those, ideally brand/type and USB IDs ?

Best regards,
Marek Vasut

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
  2016-02-04 11:28                       ` Marek Vasut
@ 2016-02-08  8:41                         ` Hannes Schmelzer
  2016-02-08 14:58                           ` Marek Vasut
  2016-02-18 10:05                         ` Schrempf Frieder
  1 sibling, 1 reply; 52+ messages in thread
From: Hannes Schmelzer @ 2016-02-08  8:41 UTC (permalink / raw)
  To: u-boot


On 04.02.2016 12:28, Marek Vasut wrote:
> On Thursday, February 04, 2016 at 09:21:08 AM, Schrempf Frieder wrote:
>> On 03.02.2016 20:16, Sergei Temerkhanov wrote:
>>> On Wed, Feb 3, 2016 at 8:40 AM, Marek Vasut <marex@denx.de> wrote:
>>>> On Wednesday, February 03, 2016 at 12:49:20 PM, Schrempf Frieder wrote:
>>>>> On 03.02.2016 12:12, Marek Vasut wrote:
>>>>>> On Wednesday, February 03, 2016 at 11:15:00 AM, Schrempf Frieder wrote:
>>>>>>> On 03.02.2016 10:55, Fabio Estevam wrote:
>>>>>>>> On Wed, Feb 3, 2016 at 7:40 AM, Marek Vasut <marex@denx.de> wrote:
>>>>>>>>> In that case, debug time.
>>>>>>>>>
>>>>>>>>> Usual problems are bad routing of the tracks on the board , so try
>>>>>>>>> with USB 1.1 hub and if that works, that's your problem.
>>>>>>>> Another suggestion would be to try the 100MB transfer in Linux and
>>>>>>>> see if this works or not.
>>>>>>>>
>>>>>>>> That would help us to narrow down whether this is a hardware or
>>>>>>>> software problem.
>>> Another thing to try may be limiting the value of USB_MAX_XFER_BLK in
>>> common/usb_storage.c
>> This was a really helpful hint! Thank you Sergei!
>>
>> I just tried to limit USB_MAX_XFER_BLK to 1/8 of the original value
>> (65535 -> 8191) and this time the transfer works without timeouts.
>>
>> As we have a customer who needs this working as soon as possible my
>> question now is how to properly solve this.
>> Should I generally limit USB_MAX_XFER_BLK in my u-boot to avoid these
>> errors? Which value to choose?
> Nice! Can you share which sticks are those, ideally brand/type and USB IDs ?
Hi,
that tip works also on my ZYNQ board.

There is some comment around this 'magic-define':

/*
  * The U-Boot EHCI driver can handle any transfer length as long as 
there is
  * enough free heap space left, but the SCSI READ(10) and WRITE(10) 
commands are
  * limited to 65535 blocks.
  */

Can i assume that 16MiB free heap space is enough if i want read a 16MiB 
file ?

> Best regards,
> Marek Vasut
best regards,
Hannes

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
  2016-02-08  8:41                         ` Hannes Schmelzer
@ 2016-02-08 14:58                           ` Marek Vasut
  2016-02-12 15:53                             ` Simon Glass
  0 siblings, 1 reply; 52+ messages in thread
From: Marek Vasut @ 2016-02-08 14:58 UTC (permalink / raw)
  To: u-boot

On Monday, February 08, 2016 at 09:41:09 AM, Hannes Schmelzer wrote:
> On 04.02.2016 12:28, Marek Vasut wrote:
> > On Thursday, February 04, 2016 at 09:21:08 AM, Schrempf Frieder wrote:
> >> On 03.02.2016 20:16, Sergei Temerkhanov wrote:
> >>> On Wed, Feb 3, 2016 at 8:40 AM, Marek Vasut <marex@denx.de> wrote:
> >>>> On Wednesday, February 03, 2016 at 12:49:20 PM, Schrempf Frieder wrote:
> >>>>> On 03.02.2016 12:12, Marek Vasut wrote:
> >>>>>> On Wednesday, February 03, 2016 at 11:15:00 AM, Schrempf Frieder wrote:
> >>>>>>> On 03.02.2016 10:55, Fabio Estevam wrote:
> >>>>>>>> On Wed, Feb 3, 2016 at 7:40 AM, Marek Vasut <marex@denx.de> wrote:
> >>>>>>>>> In that case, debug time.
> >>>>>>>>> 
> >>>>>>>>> Usual problems are bad routing of the tracks on the board , so
> >>>>>>>>> try with USB 1.1 hub and if that works, that's your problem.
> >>>>>>>> 
> >>>>>>>> Another suggestion would be to try the 100MB transfer in Linux and
> >>>>>>>> see if this works or not.
> >>>>>>>> 
> >>>>>>>> That would help us to narrow down whether this is a hardware or
> >>>>>>>> software problem.
> >>> 
> >>> Another thing to try may be limiting the value of USB_MAX_XFER_BLK in
> >>> common/usb_storage.c
> >> 
> >> This was a really helpful hint! Thank you Sergei!
> >> 
> >> I just tried to limit USB_MAX_XFER_BLK to 1/8 of the original value
> >> (65535 -> 8191) and this time the transfer works without timeouts.
> >> 
> >> As we have a customer who needs this working as soon as possible my
> >> question now is how to properly solve this.
> >> Should I generally limit USB_MAX_XFER_BLK in my u-boot to avoid these
> >> errors? Which value to choose?
> > 
> > Nice! Can you share which sticks are those, ideally brand/type and USB
> > IDs ?
> 
> Hi,
> that tip works also on my ZYNQ board.
> 
> There is some comment around this 'magic-define':
> 
> /*
>   * The U-Boot EHCI driver can handle any transfer length as long as
> there is
>   * enough free heap space left, but the SCSI READ(10) and WRITE(10)
> commands are
>   * limited to 65535 blocks.
>   */
> 
> Can i assume that 16MiB free heap space is enough if i want read a 16MiB
> file ?

The file is actually not read into a buffer on a heap iirc, but directly to
the target location if that's in RAM.

Best regards,
Marek Vasut

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
  2016-02-08 14:58                           ` Marek Vasut
@ 2016-02-12 15:53                             ` Simon Glass
  2016-02-12 16:04                               ` Hannes Schmelzer
  0 siblings, 1 reply; 52+ messages in thread
From: Simon Glass @ 2016-02-12 15:53 UTC (permalink / raw)
  To: u-boot

Hi,

On 8 February 2016 at 07:58, Marek Vasut <marex@denx.de> wrote:
> On Monday, February 08, 2016 at 09:41:09 AM, Hannes Schmelzer wrote:
>> On 04.02.2016 12:28, Marek Vasut wrote:
>> > On Thursday, February 04, 2016 at 09:21:08 AM, Schrempf Frieder wrote:
>> >> On 03.02.2016 20:16, Sergei Temerkhanov wrote:
>> >>> On Wed, Feb 3, 2016 at 8:40 AM, Marek Vasut <marex@denx.de> wrote:
>> >>>> On Wednesday, February 03, 2016 at 12:49:20 PM, Schrempf Frieder wrote:
>> >>>>> On 03.02.2016 12:12, Marek Vasut wrote:
>> >>>>>> On Wednesday, February 03, 2016 at 11:15:00 AM, Schrempf Frieder wrote:
>> >>>>>>> On 03.02.2016 10:55, Fabio Estevam wrote:
>> >>>>>>>> On Wed, Feb 3, 2016 at 7:40 AM, Marek Vasut <marex@denx.de> wrote:
>> >>>>>>>>> In that case, debug time.
>> >>>>>>>>>
>> >>>>>>>>> Usual problems are bad routing of the tracks on the board , so
>> >>>>>>>>> try with USB 1.1 hub and if that works, that's your problem.
>> >>>>>>>>
>> >>>>>>>> Another suggestion would be to try the 100MB transfer in Linux and
>> >>>>>>>> see if this works or not.
>> >>>>>>>>
>> >>>>>>>> That would help us to narrow down whether this is a hardware or
>> >>>>>>>> software problem.
>> >>>
>> >>> Another thing to try may be limiting the value of USB_MAX_XFER_BLK in
>> >>> common/usb_storage.c
>> >>
>> >> This was a really helpful hint! Thank you Sergei!
>> >>
>> >> I just tried to limit USB_MAX_XFER_BLK to 1/8 of the original value
>> >> (65535 -> 8191) and this time the transfer works without timeouts.
>> >>
>> >> As we have a customer who needs this working as soon as possible my
>> >> question now is how to properly solve this.
>> >> Should I generally limit USB_MAX_XFER_BLK in my u-boot to avoid these
>> >> errors? Which value to choose?
>> >
>> > Nice! Can you share which sticks are those, ideally brand/type and USB
>> > IDs ?
>>
>> Hi,
>> that tip works also on my ZYNQ board.
>>
>> There is some comment around this 'magic-define':
>>
>> /*
>>   * The U-Boot EHCI driver can handle any transfer length as long as
>> there is
>>   * enough free heap space left, but the SCSI READ(10) and WRITE(10)
>> commands are
>>   * limited to 65535 blocks.
>>   */
>>
>> Can i assume that 16MiB free heap space is enough if i want read a 16MiB
>> file ?
>
> The file is actually not read into a buffer on a heap iirc, but directly to
> the target location if that's in RAM.

Is it possible that the timeout is genuinely being exceeded? See
USB_TIMEOUT_MS in ehci_submit_async(). It looks like 5 seconds to load
32MB, which should be plenty.

Perhaps this timeout should be dependent on the data size?

I really can't understand why the problem is address-dependent. I'm
assuming the cache is set up normally.

Regards,
Simon

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
  2016-02-12 15:53                             ` Simon Glass
@ 2016-02-12 16:04                               ` Hannes Schmelzer
  0 siblings, 0 replies; 52+ messages in thread
From: Hannes Schmelzer @ 2016-02-12 16:04 UTC (permalink / raw)
  To: u-boot


On 2016-02-12 16:53, Simon Glass wrote:
> Hi,
>
> On 8 February 2016 at 07:58, Marek Vasut <marex@denx.de> wrote:
>> On Monday, February 08, 2016 at 09:41:09 AM, Hannes Schmelzer wrote:
>>> On 04.02.2016 12:28, Marek Vasut wrote:
>>>> On Thursday, February 04, 2016 at 09:21:08 AM, Schrempf Frieder wrote:
>>>>> On 03.02.2016 20:16, Sergei Temerkhanov wrote:
>>>>>> On Wed, Feb 3, 2016 at 8:40 AM, Marek Vasut <marex@denx.de> wrote:
>>>>>>> On Wednesday, February 03, 2016 at 12:49:20 PM, Schrempf Frieder wrote:
>>>>>>>> On 03.02.2016 12:12, Marek Vasut wrote:
>>>>>>>>> On Wednesday, February 03, 2016 at 11:15:00 AM, Schrempf Frieder wrote:
>>>>>>>>>> On 03.02.2016 10:55, Fabio Estevam wrote:
>>>>>>>>>>> On Wed, Feb 3, 2016 at 7:40 AM, Marek Vasut <marex@denx.de> wrote:
>>>>>>>>>>>> In that case, debug time.
>>>>>>>>>>>>
>>>>>>>>>>>> Usual problems are bad routing of the tracks on the board , so
>>>>>>>>>>>> try with USB 1.1 hub and if that works, that's your problem.
>>>>>>>>>>> Another suggestion would be to try the 100MB transfer in Linux and
>>>>>>>>>>> see if this works or not.
>>>>>>>>>>>
>>>>>>>>>>> That would help us to narrow down whether this is a hardware or
>>>>>>>>>>> software problem.
>>>>>> Another thing to try may be limiting the value of USB_MAX_XFER_BLK in
>>>>>> common/usb_storage.c
>>>>> This was a really helpful hint! Thank you Sergei!
>>>>>
>>>>> I just tried to limit USB_MAX_XFER_BLK to 1/8 of the original value
>>>>> (65535 -> 8191) and this time the transfer works without timeouts.
>>>>>
>>>>> As we have a customer who needs this working as soon as possible my
>>>>> question now is how to properly solve this.
>>>>> Should I generally limit USB_MAX_XFER_BLK in my u-boot to avoid these
>>>>> errors? Which value to choose?
>>>> Nice! Can you share which sticks are those, ideally brand/type and USB
>>>> IDs ?
>>> Hi,
>>> that tip works also on my ZYNQ board.
>>>
>>> There is some comment around this 'magic-define':
>>>
>>> /*
>>>    * The U-Boot EHCI driver can handle any transfer length as long as
>>> there is
>>>    * enough free heap space left, but the SCSI READ(10) and WRITE(10)
>>> commands are
>>>    * limited to 65535 blocks.
>>>    */
>>>
>>> Can i assume that 16MiB free heap space is enough if i want read a 16MiB
>>> file ?
>> The file is actually not read into a buffer on a heap iirc, but directly to
>> the target location if that's in RAM.
> Is it possible that the timeout is genuinely being exceeded? See
> USB_TIMEOUT_MS in ehci_submit_async(). It looks like 5 seconds to load
> 32MB, which should be plenty.
Hi Simon,
thanks for joining. I also have found this USB_TIMOUT in usb.h and 
increesed for
testing purpose this 5s to about 30s ... without wanted result.
It now takes instead 5s this 30s to bring up the timout warning, but 
still with the effect,
that file finally couldn't be read.
> Perhaps this timeout should be dependent on the data size?
Indeed, it depends on size ... but i'm not sure if this size parameter 
is 'wired' with some timeout parameter.
> I really can't understand why the problem is address-dependent. I'm
> assuming the cache is set up normally.
This is confusing me also.
> Regards,
> Simon
Hannes

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
  2016-02-04 11:28                       ` Marek Vasut
  2016-02-08  8:41                         ` Hannes Schmelzer
@ 2016-02-18 10:05                         ` Schrempf Frieder
  2016-02-18 15:32                           ` Marek Vasut
  2016-04-14 13:20                           ` Diego
  1 sibling, 2 replies; 52+ messages in thread
From: Schrempf Frieder @ 2016-02-18 10:05 UTC (permalink / raw)
  To: u-boot

On 04.02.2016 12:28, Marek Vasut wrote:
> On Thursday, February 04, 2016 at 09:21:08 AM, Schrempf Frieder wrote:
>> On 03.02.2016 20:16, Sergei Temerkhanov wrote:
>>> On Wed, Feb 3, 2016 at 8:40 AM, Marek Vasut<marex@denx.de>  wrote:
>>>> On Wednesday, February 03, 2016 at 12:49:20 PM, Schrempf Frieder wrote:
>>>>> On 03.02.2016 12:12, Marek Vasut wrote:
>>>>>> On Wednesday, February 03, 2016 at 11:15:00 AM, Schrempf Frieder wrote:
>>>>>>> On 03.02.2016 10:55, Fabio Estevam wrote:
>>>>>>>> On Wed, Feb 3, 2016 at 7:40 AM, Marek Vasut<marex@denx.de>  wrote:
>>>>>>>>> In that case, debug time.
>>>>>>>>>
>>>>>>>>> Usual problems are bad routing of the tracks on the board , so try
>>>>>>>>> with USB 1.1 hub and if that works, that's your problem.
>>>>>>>> Another suggestion would be to try the 100MB transfer in Linux and
>>>>>>>> see if this works or not.
>>>>>>>>
>>>>>>>> That would help us to narrow down whether this is a hardware or
>>>>>>>> software problem.
>>> Another thing to try may be limiting the value of USB_MAX_XFER_BLK in
>>> common/usb_storage.c
>> This was a really helpful hint! Thank you Sergei!
>>
>> I just tried to limit USB_MAX_XFER_BLK to 1/8 of the original value
>> (65535 -> 8191) and this time the transfer works without timeouts.
>>
>> As we have a customer who needs this working as soon as possible my
>> question now is how to properly solve this.
>> Should I generally limit USB_MAX_XFER_BLK in my u-boot to avoid these
>> errors? Which value to choose?
> Nice! Can you share which sticks are those, ideally brand/type and USB IDs ?
At the moment I have two sticks with the same chip around for which 
setting USB_MAX_XFER_BLK from 65535 to 32767 fixed the file transfer.
Also one of our customers tested a few non-working sticks with this 
change and reported, that it fixed it for him.
Here's a list of those devices, but I guess there are a lot more:

1. Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.) Flash 
Drive, VID: 0x090c, PID: 0x1000
2. Freecom Technologies, VID: 0x07ab, PID: 0xfcf1
3. Newron, VID: 0x8644, PID: 0x800e
4. GEMBIRD PhotoFrame PF-15-1, VID:  0x1908, PID: 0x1320

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
  2016-02-18 10:05                         ` Schrempf Frieder
@ 2016-02-18 15:32                           ` Marek Vasut
  2016-02-18 17:14                             ` Fabio Estevam
  2016-04-14 13:20                           ` Diego
  1 sibling, 1 reply; 52+ messages in thread
From: Marek Vasut @ 2016-02-18 15:32 UTC (permalink / raw)
  To: u-boot

On 02/18/2016 11:05 AM, Schrempf Frieder wrote:
> On 04.02.2016 12:28, Marek Vasut wrote:
>> On Thursday, February 04, 2016 at 09:21:08 AM, Schrempf Frieder wrote:
>>> On 03.02.2016 20:16, Sergei Temerkhanov wrote:
>>>> On Wed, Feb 3, 2016 at 8:40 AM, Marek Vasut<marex@denx.de>  wrote:
>>>>> On Wednesday, February 03, 2016 at 12:49:20 PM, Schrempf Frieder wrote:
>>>>>> On 03.02.2016 12:12, Marek Vasut wrote:
>>>>>>> On Wednesday, February 03, 2016 at 11:15:00 AM, Schrempf Frieder wrote:
>>>>>>>> On 03.02.2016 10:55, Fabio Estevam wrote:
>>>>>>>>> On Wed, Feb 3, 2016 at 7:40 AM, Marek Vasut<marex@denx.de>  wrote:
>>>>>>>>>> In that case, debug time.
>>>>>>>>>>
>>>>>>>>>> Usual problems are bad routing of the tracks on the board , so try
>>>>>>>>>> with USB 1.1 hub and if that works, that's your problem.
>>>>>>>>> Another suggestion would be to try the 100MB transfer in Linux and
>>>>>>>>> see if this works or not.
>>>>>>>>>
>>>>>>>>> That would help us to narrow down whether this is a hardware or
>>>>>>>>> software problem.
>>>> Another thing to try may be limiting the value of USB_MAX_XFER_BLK in
>>>> common/usb_storage.c
>>> This was a really helpful hint! Thank you Sergei!
>>>
>>> I just tried to limit USB_MAX_XFER_BLK to 1/8 of the original value
>>> (65535 -> 8191) and this time the transfer works without timeouts.
>>>
>>> As we have a customer who needs this working as soon as possible my
>>> question now is how to properly solve this.
>>> Should I generally limit USB_MAX_XFER_BLK in my u-boot to avoid these
>>> errors? Which value to choose?
>> Nice! Can you share which sticks are those, ideally brand/type and USB IDs ?
> At the moment I have two sticks with the same chip around for which 
> setting USB_MAX_XFER_BLK from 65535 to 32767 fixed the file transfer.
> Also one of our customers tested a few non-working sticks with this 
> change and reported, that it fixed it for him.
> Here's a list of those devices, but I guess there are a lot more:
> 
> 1. Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.) Flash 
> Drive, VID: 0x090c, PID: 0x1000
> 2. Freecom Technologies, VID: 0x07ab, PID: 0xfcf1
> 3. Newron, VID: 0x8644, PID: 0x800e
> 4. GEMBIRD PhotoFrame PF-15-1, VID:  0x1908, PID: 0x1320
> 
Maybe we need a quirk table then ?

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
  2016-02-18 15:32                           ` Marek Vasut
@ 2016-02-18 17:14                             ` Fabio Estevam
  2016-02-22  7:03                               ` Schrempf Frieder
  0 siblings, 1 reply; 52+ messages in thread
From: Fabio Estevam @ 2016-02-18 17:14 UTC (permalink / raw)
  To: u-boot

On Thu, Feb 18, 2016 at 1:32 PM, Marek Vasut <marex@denx.de> wrote:

>> Also one of our customers tested a few non-working sticks with this
>> change and reported, that it fixed it for him.
>> Here's a list of those devices, but I guess there are a lot more:
>>
>> 1. Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.) Flash
>> Drive, VID: 0x090c, PID: 0x1000
>> 2. Freecom Technologies, VID: 0x07ab, PID: 0xfcf1
>> 3. Newron, VID: 0x8644, PID: 0x800e
>> 4. GEMBIRD PhotoFrame PF-15-1, VID:  0x1908, PID: 0x1320
>>
> Maybe we need a quirk table then ?

It seems the list of affected devices is unknown.

What would be the impact of changing USB_MAX_XFER_BLK from 65535 to 32767?

Would this impact the USB transfer rate? Frieder, do you know?

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
  2016-02-18 17:14                             ` Fabio Estevam
@ 2016-02-22  7:03                               ` Schrempf Frieder
  2016-02-22 17:51                                 ` Maxime Jayat
  0 siblings, 1 reply; 52+ messages in thread
From: Schrempf Frieder @ 2016-02-22  7:03 UTC (permalink / raw)
  To: u-boot

On 18.02.2016 18:14, Fabio Estevam wrote:
> On Thu, Feb 18, 2016 at 1:32 PM, Marek Vasut <marex@denx.de> wrote:
>
>>> Also one of our customers tested a few non-working sticks with this
>>> change and reported, that it fixed it for him.
>>> Here's a list of those devices, but I guess there are a lot more:
>>>
>>> 1. Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.) Flash
>>> Drive, VID: 0x090c, PID: 0x1000
>>> 2. Freecom Technologies, VID: 0x07ab, PID: 0xfcf1
>>> 3. Newron, VID: 0x8644, PID: 0x800e
>>> 4. GEMBIRD PhotoFrame PF-15-1, VID:  0x1908, PID: 0x1320
>>>
>> Maybe we need a quirk table then ?
> It seems the list of affected devices is unknown.
>
> What would be the impact of changing USB_MAX_XFER_BLK from 65535 to 32767?
>
> Would this impact the USB transfer rate? Frieder, do you know?
I don't really know. While testing I had the feeling, that the transfer 
is slightly slower, but I can't tell for sure.

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
  2016-02-22  7:03                               ` Schrempf Frieder
@ 2016-02-22 17:51                                 ` Maxime Jayat
  2016-02-22 17:59                                   ` Fabio Estevam
  0 siblings, 1 reply; 52+ messages in thread
From: Maxime Jayat @ 2016-02-22 17:51 UTC (permalink / raw)
  To: u-boot

Le 22/02/2016 08:03, Schrempf Frieder a ?crit :
> On 18.02.2016 18:14, Fabio Estevam wrote:
>> On Thu, Feb 18, 2016 at 1:32 PM, Marek Vasut <marex@denx.de> wrote:
>>
>>>> Also one of our customers tested a few non-working sticks with this
>>>> change and reported, that it fixed it for him.
>>>> Here's a list of those devices, but I guess there are a lot more:
>>>>
>>>> 1. Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.) Flash
>>>> Drive, VID: 0x090c, PID: 0x1000
>>>> 2. Freecom Technologies, VID: 0x07ab, PID: 0xfcf1
>>>> 3. Newron, VID: 0x8644, PID: 0x800e
>>>> 4. GEMBIRD PhotoFrame PF-15-1, VID:  0x1908, PID: 0x1320
>>>>
>>> Maybe we need a quirk table then ?
>> It seems the list of affected devices is unknown.
>>
>> What would be the impact of changing USB_MAX_XFER_BLK from 65535 to 32767?
>>
>> Would this impact the USB transfer rate? Frieder, do you know?
> I don't really know. While testing I had the feeling, that the transfer 
> is slightly slower, but I can't tell for sure.
> 
Hello,
I was hit by the same problem, where my USB SD card reader would timeout
in U-boot when reading a large file (16 MB). Changing USB_MAX_XFER_BLK
to 32767 fixed the problem but I investigated a little more.
I was curious to see what the Linux kernel used, because it had no
problem reading the file. In Linux, USB_MAX_XFER_BLK corresponds to
max_sector in the scsiglue, which is set to 240 blocks per transfer by
default, and is tunable via sysfs.
There is also a list of unusual devices which needs no higher than 64
blocks per transfer.
The linux USB FAQ has a very interesting entry about this which explains
the rationale for this value:
    http://www.linux-usb.org/FAQ.html#i5

FWIW: my USB card reader is
0bda:0119 Realtek Semiconductor Corp. Storage Device (SD card reader)

I've benchmarked in U-boot the time impact of this change.
For reading my 16764395 bytes file:
USB_MAX_XFER_BLK	Read duration (as reported by U-boot):
64			3578 ms
128			2221 ms
240			1673 ms
32767			1020 ms
65535			974  ms

So there is definitely a strong impact for lower values.

-- 
Maxime Jayat

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
  2016-02-22 17:51                                 ` Maxime Jayat
@ 2016-02-22 17:59                                   ` Fabio Estevam
  2016-02-23  6:38                                     ` Hannes Schmelzer
  0 siblings, 1 reply; 52+ messages in thread
From: Fabio Estevam @ 2016-02-22 17:59 UTC (permalink / raw)
  To: u-boot

On Mon, Feb 22, 2016 at 2:51 PM, Maxime Jayat <jayatmaxime@gmail.com> wrote:

> Hello,
> I was hit by the same problem, where my USB SD card reader would timeout
> in U-boot when reading a large file (16 MB). Changing USB_MAX_XFER_BLK
> to 32767 fixed the problem but I investigated a little more.
> I was curious to see what the Linux kernel used, because it had no
> problem reading the file. In Linux, USB_MAX_XFER_BLK corresponds to
> max_sector in the scsiglue, which is set to 240 blocks per transfer by
> default, and is tunable via sysfs.
> There is also a list of unusual devices which needs no higher than 64
> blocks per transfer.
> The linux USB FAQ has a very interesting entry about this which explains
> the rationale for this value:
>     http://www.linux-usb.org/FAQ.html#i5
>
> FWIW: my USB card reader is
> 0bda:0119 Realtek Semiconductor Corp. Storage Device (SD card reader)
>
> I've benchmarked in U-boot the time impact of this change.
> For reading my 16764395 bytes file:
> USB_MAX_XFER_BLK        Read duration (as reported by U-boot):
> 64                      3578 ms
> 128                     2221 ms
> 240                     1673 ms
> 32767                   1020 ms
> 65535                   974  ms
>
> So there is definitely a strong impact for lower values.

Ok, so with a USB_MAX_XFER_BLK size of 32767 there is not so much of a
performance impact.

Looks like that changing USB_MAX_XFER_BLK from 65535 to 32767 is the way to go.

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
  2016-02-22 17:59                                   ` Fabio Estevam
@ 2016-02-23  6:38                                     ` Hannes Schmelzer
  2016-02-24 17:43                                       ` Marek Vasut
  0 siblings, 1 reply; 52+ messages in thread
From: Hannes Schmelzer @ 2016-02-23  6:38 UTC (permalink / raw)
  To: u-boot

On 22.02.2016 18:59, Fabio Estevam wrote:
> On Mon, Feb 22, 2016 at 2:51 PM, Maxime Jayat <jayatmaxime@gmail.com> wrote:
>
>> Hello,
>> I was hit by the same problem, where my USB SD card reader would timeout
>> in U-boot when reading a large file (16 MB). Changing USB_MAX_XFER_BLK
>> to 32767 fixed the problem but I investigated a little more.
>> I was curious to see what the Linux kernel used, because it had no
>> problem reading the file. In Linux, USB_MAX_XFER_BLK corresponds to
>> max_sector in the scsiglue, which is set to 240 blocks per transfer by
>> default, and is tunable via sysfs.
>> There is also a list of unusual devices which needs no higher than 64
>> blocks per transfer.
>> The linux USB FAQ has a very interesting entry about this which explains
>> the rationale for this value:
>>      http://www.linux-usb.org/FAQ.html#i5
>>
>> FWIW: my USB card reader is
>> 0bda:0119 Realtek Semiconductor Corp. Storage Device (SD card reader)
>>
>> I've benchmarked in U-boot the time impact of this change.
>> For reading my 16764395 bytes file:
>> USB_MAX_XFER_BLK        Read duration (as reported by U-boot):
>> 64                      3578 ms
>> 128                     2221 ms
>> 240                     1673 ms
>> 32767                   1020 ms
>> 65535                   974  ms
>>
>> So there is definitely a strong impact for lower values.
> Ok, so with a USB_MAX_XFER_BLK size of 32767 there is not so much of a
> performance impact.
>
> Looks like that changing USB_MAX_XFER_BLK from 65535 to 32767 is the way to go.
I have configured a value of 8191 some few weeks ago on my zynq board,
there was no negative feedback until yesterday :-(

A colleague of mine told me, that his USB-stick doesn't work. I had a look.

Vendor: 0x1307  Product 0x0165 Version 1.0
I had to reduce the USB_MAX_XFER_BLK downto 2048 to make it work.

I'm not the big usb-expert ... but would it be possible to move away 
from this
#define to some variable which is adapted to the lowest value on the bus.
Is it possible at all to get to right value out of some register ?

regards,
Hannes

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
  2016-02-23  6:38                                     ` Hannes Schmelzer
@ 2016-02-24 17:43                                       ` Marek Vasut
  2016-02-25  4:13                                         ` Simon Glass
  0 siblings, 1 reply; 52+ messages in thread
From: Marek Vasut @ 2016-02-24 17:43 UTC (permalink / raw)
  To: u-boot

On 02/23/2016 07:38 AM, Hannes Schmelzer wrote:
> On 22.02.2016 18:59, Fabio Estevam wrote:
>> On Mon, Feb 22, 2016 at 2:51 PM, Maxime Jayat <jayatmaxime@gmail.com>
>> wrote:
>>
>>> Hello,
>>> I was hit by the same problem, where my USB SD card reader would timeout
>>> in U-boot when reading a large file (16 MB). Changing USB_MAX_XFER_BLK
>>> to 32767 fixed the problem but I investigated a little more.
>>> I was curious to see what the Linux kernel used, because it had no
>>> problem reading the file. In Linux, USB_MAX_XFER_BLK corresponds to
>>> max_sector in the scsiglue, which is set to 240 blocks per transfer by
>>> default, and is tunable via sysfs.
>>> There is also a list of unusual devices which needs no higher than 64
>>> blocks per transfer.
>>> The linux USB FAQ has a very interesting entry about this which explains
>>> the rationale for this value:
>>>      http://www.linux-usb.org/FAQ.html#i5
>>>
>>> FWIW: my USB card reader is
>>> 0bda:0119 Realtek Semiconductor Corp. Storage Device (SD card reader)
>>>
>>> I've benchmarked in U-boot the time impact of this change.
>>> For reading my 16764395 bytes file:
>>> USB_MAX_XFER_BLK        Read duration (as reported by U-boot):
>>> 64                      3578 ms
>>> 128                     2221 ms
>>> 240                     1673 ms
>>> 32767                   1020 ms
>>> 65535                   974  ms
>>>
>>> So there is definitely a strong impact for lower values.
>> Ok, so with a USB_MAX_XFER_BLK size of 32767 there is not so much of a
>> performance impact.
>>
>> Looks like that changing USB_MAX_XFER_BLK from 65535 to 32767 is the
>> way to go.
> I have configured a value of 8191 some few weeks ago on my zynq board,
> there was no negative feedback until yesterday :-(
> 
> A colleague of mine told me, that his USB-stick doesn't work. I had a look.
> 
> Vendor: 0x1307  Product 0x0165 Version 1.0
> I had to reduce the USB_MAX_XFER_BLK downto 2048 to make it work.
> 
> I'm not the big usb-expert ... but would it be possible to move away
> from this
> #define to some variable which is adapted to the lowest value on the bus.
> Is it possible at all to get to right value out of some register ?

We will probably need a quirk table and for the crappy USB sticks, we
will just have to use lower maximum xfer size. I would suggest to add
an environment variable, which would allow to override the max xfer
size. This would help in case the user had a device, which does need
a quirk, but is not yet in a quirk table ; as a temporary work around of
course.

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
  2016-02-24 17:43                                       ` Marek Vasut
@ 2016-02-25  4:13                                         ` Simon Glass
  2016-02-25 17:56                                           ` Marek Vasut
  0 siblings, 1 reply; 52+ messages in thread
From: Simon Glass @ 2016-02-25  4:13 UTC (permalink / raw)
  To: u-boot

Hi,

On 24 February 2016 at 10:43, Marek Vasut <marex@denx.de> wrote:
>
> On 02/23/2016 07:38 AM, Hannes Schmelzer wrote:
> > On 22.02.2016 18:59, Fabio Estevam wrote:
> >> On Mon, Feb 22, 2016 at 2:51 PM, Maxime Jayat <jayatmaxime@gmail.com>
> >> wrote:
> >>
> >>> Hello,
> >>> I was hit by the same problem, where my USB SD card reader would timeout
> >>> in U-boot when reading a large file (16 MB). Changing USB_MAX_XFER_BLK
> >>> to 32767 fixed the problem but I investigated a little more.
> >>> I was curious to see what the Linux kernel used, because it had no
> >>> problem reading the file. In Linux, USB_MAX_XFER_BLK corresponds to
> >>> max_sector in the scsiglue, which is set to 240 blocks per transfer by
> >>> default, and is tunable via sysfs.
> >>> There is also a list of unusual devices which needs no higher than 64
> >>> blocks per transfer.
> >>> The linux USB FAQ has a very interesting entry about this which explains
> >>> the rationale for this value:
> >>>      http://www.linux-usb.org/FAQ.html#i5
> >>>
> >>> FWIW: my USB card reader is
> >>> 0bda:0119 Realtek Semiconductor Corp. Storage Device (SD card reader)
> >>>
> >>> I've benchmarked in U-boot the time impact of this change.
> >>> For reading my 16764395 bytes file:
> >>> USB_MAX_XFER_BLK        Read duration (as reported by U-boot):
> >>> 64                      3578 ms
> >>> 128                     2221 ms
> >>> 240                     1673 ms
> >>> 32767                   1020 ms
> >>> 65535                   974  ms
> >>>
> >>> So there is definitely a strong impact for lower values.
> >> Ok, so with a USB_MAX_XFER_BLK size of 32767 there is not so much of a
> >> performance impact.
> >>
> >> Looks like that changing USB_MAX_XFER_BLK from 65535 to 32767 is the
> >> way to go.
> > I have configured a value of 8191 some few weeks ago on my zynq board,
> > there was no negative feedback until yesterday :-(
> >
> > A colleague of mine told me, that his USB-stick doesn't work. I had a look.
> >
> > Vendor: 0x1307  Product 0x0165 Version 1.0
> > I had to reduce the USB_MAX_XFER_BLK downto 2048 to make it work.
> >
> > I'm not the big usb-expert ... but would it be possible to move away
> > from this
> > #define to some variable which is adapted to the lowest value on the bus.
> > Is it possible at all to get to right value out of some register ?
>
> We will probably need a quirk table and for the crappy USB sticks, we
> will just have to use lower maximum xfer size. I would suggest to add
> an environment variable, which would allow to override the max xfer
> size. This would help in case the user had a device, which does need
> a quirk, but is not yet in a quirk table ; as a temporary work around of
> course.

Yes.

Even better if we can print a message telling the user about this when
we detect this error.

Regards.
Simon

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
  2016-02-25  4:13                                         ` Simon Glass
@ 2016-02-25 17:56                                           ` Marek Vasut
  2016-02-26  1:56                                             ` Simon Glass
  0 siblings, 1 reply; 52+ messages in thread
From: Marek Vasut @ 2016-02-25 17:56 UTC (permalink / raw)
  To: u-boot

On 02/25/2016 05:13 AM, Simon Glass wrote:
> Hi,
> 
> On 24 February 2016 at 10:43, Marek Vasut <marex@denx.de> wrote:
>>
>> On 02/23/2016 07:38 AM, Hannes Schmelzer wrote:
>>> On 22.02.2016 18:59, Fabio Estevam wrote:
>>>> On Mon, Feb 22, 2016 at 2:51 PM, Maxime Jayat <jayatmaxime@gmail.com>
>>>> wrote:
>>>>
>>>>> Hello,
>>>>> I was hit by the same problem, where my USB SD card reader would timeout
>>>>> in U-boot when reading a large file (16 MB). Changing USB_MAX_XFER_BLK
>>>>> to 32767 fixed the problem but I investigated a little more.
>>>>> I was curious to see what the Linux kernel used, because it had no
>>>>> problem reading the file. In Linux, USB_MAX_XFER_BLK corresponds to
>>>>> max_sector in the scsiglue, which is set to 240 blocks per transfer by
>>>>> default, and is tunable via sysfs.
>>>>> There is also a list of unusual devices which needs no higher than 64
>>>>> blocks per transfer.
>>>>> The linux USB FAQ has a very interesting entry about this which explains
>>>>> the rationale for this value:
>>>>>      http://www.linux-usb.org/FAQ.html#i5
>>>>>
>>>>> FWIW: my USB card reader is
>>>>> 0bda:0119 Realtek Semiconductor Corp. Storage Device (SD card reader)
>>>>>
>>>>> I've benchmarked in U-boot the time impact of this change.
>>>>> For reading my 16764395 bytes file:
>>>>> USB_MAX_XFER_BLK        Read duration (as reported by U-boot):
>>>>> 64                      3578 ms
>>>>> 128                     2221 ms
>>>>> 240                     1673 ms
>>>>> 32767                   1020 ms
>>>>> 65535                   974  ms
>>>>>
>>>>> So there is definitely a strong impact for lower values.
>>>> Ok, so with a USB_MAX_XFER_BLK size of 32767 there is not so much of a
>>>> performance impact.
>>>>
>>>> Looks like that changing USB_MAX_XFER_BLK from 65535 to 32767 is the
>>>> way to go.
>>> I have configured a value of 8191 some few weeks ago on my zynq board,
>>> there was no negative feedback until yesterday :-(
>>>
>>> A colleague of mine told me, that his USB-stick doesn't work. I had a look.
>>>
>>> Vendor: 0x1307  Product 0x0165 Version 1.0
>>> I had to reduce the USB_MAX_XFER_BLK downto 2048 to make it work.
>>>
>>> I'm not the big usb-expert ... but would it be possible to move away
>>> from this
>>> #define to some variable which is adapted to the lowest value on the bus.
>>> Is it possible at all to get to right value out of some register ?
>>
>> We will probably need a quirk table and for the crappy USB sticks, we
>> will just have to use lower maximum xfer size. I would suggest to add
>> an environment variable, which would allow to override the max xfer
>> size. This would help in case the user had a device, which does need
>> a quirk, but is not yet in a quirk table ; as a temporary work around of
>> course.
> 
> Yes.
> 
> Even better if we can print a message telling the user about this when
> we detect this error.

Agreed. Can you prepare such patch please ?

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
  2016-02-25 17:56                                           ` Marek Vasut
@ 2016-02-26  1:56                                             ` Simon Glass
  0 siblings, 0 replies; 52+ messages in thread
From: Simon Glass @ 2016-02-26  1:56 UTC (permalink / raw)
  To: u-boot

Hi Marek,

On 25 February 2016 at 10:56, Marek Vasut <marex@denx.de> wrote:
> On 02/25/2016 05:13 AM, Simon Glass wrote:
>> Hi,
>>
>> On 24 February 2016 at 10:43, Marek Vasut <marex@denx.de> wrote:
>>>
>>> On 02/23/2016 07:38 AM, Hannes Schmelzer wrote:
>>>> On 22.02.2016 18:59, Fabio Estevam wrote:
>>>>> On Mon, Feb 22, 2016 at 2:51 PM, Maxime Jayat <jayatmaxime@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hello,
>>>>>> I was hit by the same problem, where my USB SD card reader would
timeout
>>>>>> in U-boot when reading a large file (16 MB). Changing
USB_MAX_XFER_BLK
>>>>>> to 32767 fixed the problem but I investigated a little more.
>>>>>> I was curious to see what the Linux kernel used, because it had no
>>>>>> problem reading the file. In Linux, USB_MAX_XFER_BLK corresponds to
>>>>>> max_sector in the scsiglue, which is set to 240 blocks per transfer
by
>>>>>> default, and is tunable via sysfs.
>>>>>> There is also a list of unusual devices which needs no higher than 64
>>>>>> blocks per transfer.
>>>>>> The linux USB FAQ has a very interesting entry about this which
explains
>>>>>> the rationale for this value:
>>>>>> http://www.linux-usb.org/FAQ.html#i5
>>>>>>
>>>>>> FWIW: my USB card reader is
>>>>>> 0bda:0119 Realtek Semiconductor Corp. Storage Device (SD card reader)
>>>>>>
>>>>>> I've benchmarked in U-boot the time impact of this change.
>>>>>> For reading my 16764395 bytes file:
>>>>>> USB_MAX_XFER_BLK Read duration (as reported by U-boot):
>>>>>> 64 3578 ms
>>>>>> 128 2221 ms
>>>>>> 240 1673 ms
>>>>>> 32767 1020 ms
>>>>>> 65535 974 ms
>>>>>>
>>>>>> So there is definitely a strong impact for lower values.
>>>>> Ok, so with a USB_MAX_XFER_BLK size of 32767 there is not so much of a
>>>>> performance impact.
>>>>>
>>>>> Looks like that changing USB_MAX_XFER_BLK from 65535 to 32767 is the
>>>>> way to go.
>>>> I have configured a value of 8191 some few weeks ago on my zynq board,
>>>> there was no negative feedback until yesterday :-(
>>>>
>>>> A colleague of mine told me, that his USB-stick doesn't work. I had a
look.
>>>>
>>>> Vendor: 0x1307 Product 0x0165 Version 1.0
>>>> I had to reduce the USB_MAX_XFER_BLK downto 2048 to make it work.
>>>>
>>>> I'm not the big usb-expert ... but would it be possible to move away
>>>> from this
>>>> #define to some variable which is adapted to the lowest value on the
bus.
>>>> Is it possible at all to get to right value out of some register ?
>>>
>>> We will probably need a quirk table and for the crappy USB sticks, we
>>> will just have to use lower maximum xfer size. I would suggest to add
>>> an environment variable, which would allow to override the max xfer
>>> size. This would help in case the user had a device, which does need
>>> a quirk, but is not yet in a quirk table ; as a temporary work around of
>>> course.
>>
>> Yes.
>>
>> Even better if we can print a message telling the user about this when
>> we detect this error.
>
> Agreed. Can you prepare such patch please ?
>

Let me put it in my queue and think about it...no promises.

Regards,
Simon

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
  2016-02-18 10:05                         ` Schrempf Frieder
  2016-02-18 15:32                           ` Marek Vasut
@ 2016-04-14 13:20                           ` Diego
  2016-04-15 10:53                             ` Marek Vasut
  1 sibling, 1 reply; 52+ messages in thread
From: Diego @ 2016-04-14 13:20 UTC (permalink / raw)
  To: u-boot

On 18.02.2016, Schrempf Frieder wrote:
> At the moment I have two sticks with the same chip around for which
> setting USB_MAX_XFER_BLK from 65535 to 32767 fixed the file transfer.
> Also one of our customers tested a few non-working sticks with this
> change and reported, that it fixed it for him.

Hi all,

sorry for reopening this thread, but I'd like to provide some additional 
infos.

I was experiencing the same problem with several USB thumb drives, especially 
with some Kingston DataTraveler.

Changing USB_MAX_XFER_BLK from 65535 to 32767 definitely fixed the "EHCI timed 
out on TD" but also fixed a more subtle problem.

Additionally, on a Kingston DataTraveler labelled "DTSE9 G2 USB 3.0":
ID 0951:1666 Kingston Technology DataTraveler G4
I was experiencing apparently successful "load" transfers, but the data loaded 
was actually corrupted when loaded in memory, as a subsequent gzwrite reported 
broken CRC.

U-Boot > usb dev 0

USB device 0:
    Device 0: Vendor: Kingston Rev: PMAP Prod: DataTraveler 3.0
            Type: Removable Hard Disk
            Capacity: 15004.3 MB = 14.6 GB (30728832 x 512)
... is now current device
U-Boot > load usb 0:1 0x10008000 my-image.sdcard.gz
reading my-image.sdcard.gz
112364153 bytes read in 3306 ms (32.4 MiB/s)
U-Boot > gzwrite mmc 1 0x10008000 $filesize
Error: inflate() returned -3

        uncompressed 4194304 of 2218786816
        crcs == 0xa85fe71c/0xd0244792


The decrease of USB_MAX_XFER_BLK from 65535 to 32767 fixed also that "corrupted 
load" problem, so from what I experienced 32767 is a much more practical and 
"real life" reliable value.

If, as Fabio Estevam suggested, changing USB_MAX_XFER_BLK to 32767 is being 
considered, I definitely vote for it.

Bests,
Diego

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
  2016-04-14 13:20                           ` Diego
@ 2016-04-15 10:53                             ` Marek Vasut
  2016-04-15 12:13                               ` Diego
  0 siblings, 1 reply; 52+ messages in thread
From: Marek Vasut @ 2016-04-15 10:53 UTC (permalink / raw)
  To: u-boot

On 04/14/2016 03:20 PM, Diego wrote:
> On 18.02.2016, Schrempf Frieder wrote:
>> At the moment I have two sticks with the same chip around for which
>> setting USB_MAX_XFER_BLK from 65535 to 32767 fixed the file transfer.
>> Also one of our customers tested a few non-working sticks with this
>> change and reported, that it fixed it for him.
> 
> Hi all,
> 
> sorry for reopening this thread, but I'd like to provide some additional 
> infos.
> 
> I was experiencing the same problem with several USB thumb drives, especially 
> with some Kingston DataTraveler.
> 
> Changing USB_MAX_XFER_BLK from 65535 to 32767 definitely fixed the "EHCI timed 
> out on TD" but also fixed a more subtle problem.

So the DTSE9 is problematic even on EHCI ? Sigh ... I'll have to look
into that one stick deeper, that's real bad.

> Additionally, on a Kingston DataTraveler labelled "DTSE9 G2 USB 3.0":
> ID 0951:1666 Kingston Technology DataTraveler G4
> I was experiencing apparently successful "load" transfers, but the data loaded 
> was actually corrupted when loaded in memory, as a subsequent gzwrite reported 
> broken CRC.
> 
> U-Boot > usb dev 0
> 
> USB device 0:
>     Device 0: Vendor: Kingston Rev: PMAP Prod: DataTraveler 3.0
>             Type: Removable Hard Disk
>             Capacity: 15004.3 MB = 14.6 GB (30728832 x 512)
> ... is now current device
> U-Boot > load usb 0:1 0x10008000 my-image.sdcard.gz
> reading my-image.sdcard.gz
> 112364153 bytes read in 3306 ms (32.4 MiB/s)
> U-Boot > gzwrite mmc 1 0x10008000 $filesize
> Error: inflate() returned -3
> 
>         uncompressed 4194304 of 2218786816
>         crcs == 0xa85fe71c/0xd0244792
> 
> 
> The decrease of USB_MAX_XFER_BLK from 65535 to 32767 fixed also that "corrupted 
> load" problem, so from what I experienced 32767 is a much more practical and 
> "real life" reliable value.
> 
> If, as Fabio Estevam suggested, changing USB_MAX_XFER_BLK to 32767 is being 
> considered, I definitely vote for it.
> 
> Bests,
> Diego
> 
> 
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
> 


-- 
Best regards,
Marek Vasut

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
  2016-04-15 10:53                             ` Marek Vasut
@ 2016-04-15 12:13                               ` Diego
  2016-04-18 23:54                                 ` Marek Vasut
  2016-04-27  2:14                                 ` Marek Vasut
  0 siblings, 2 replies; 52+ messages in thread
From: Diego @ 2016-04-15 12:13 UTC (permalink / raw)
  To: u-boot

In data venerd? 15 aprile 2016 12:53:36, Marek Vasut ha scritto:
> On 04/14/2016 03:20 PM, Diego wrote:
> > On 18.02.2016, Schrempf Frieder wrote:
> >> At the moment I have two sticks with the same chip around for which
> >> setting USB_MAX_XFER_BLK from 65535 to 32767 fixed the file transfer.
> >> Also one of our customers tested a few non-working sticks with this
> >> change and reported, that it fixed it for him.
> > 
> > Hi all,
> > 
> > sorry for reopening this thread, but I'd like to provide some additional
> > infos.
> > 
> > I was experiencing the same problem with several USB thumb drives,
> > especially with some Kingston DataTraveler.
> > 
> > Changing USB_MAX_XFER_BLK from 65535 to 32767 definitely fixed the "EHCI
> > timed out on TD" but also fixed a more subtle problem.
> 
> So the DTSE9 is problematic even on EHCI ? Sigh ... I'll have to look
> into that one stick deeper, that's real bad.
> 

Hi Marek,

yes, I was getting the following error with the Kingston DTSE9 USB 2.0:
EHCI timed out on TD - token=0x1e008d80
EHCI timed out on TD - token=0x1e008d80
EHCI timed out on TD - token=0x1e008d80
The model is the one in this photo:
http://katteway.com/images/Kingston-DataTraveler-DTSE9-8GB-USB-Flash-Drive-Silver.jpg
ID 0951:1689 Kingston Technology DataTraveler SE9

I'm available if you want any additional info.

Bests,
Diego

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
  2016-04-15 12:13                               ` Diego
@ 2016-04-18 23:54                                 ` Marek Vasut
  2016-04-25  8:16                                   ` Stefan Roese
  2016-04-27  2:14                                 ` Marek Vasut
  1 sibling, 1 reply; 52+ messages in thread
From: Marek Vasut @ 2016-04-18 23:54 UTC (permalink / raw)
  To: u-boot

On 04/15/2016 02:13 PM, Diego wrote:
> In data venerd? 15 aprile 2016 12:53:36, Marek Vasut ha scritto:
>> On 04/14/2016 03:20 PM, Diego wrote:
>>> On 18.02.2016, Schrempf Frieder wrote:
>>>> At the moment I have two sticks with the same chip around for which
>>>> setting USB_MAX_XFER_BLK from 65535 to 32767 fixed the file transfer.
>>>> Also one of our customers tested a few non-working sticks with this
>>>> change and reported, that it fixed it for him.
>>>
>>> Hi all,
>>>
>>> sorry for reopening this thread, but I'd like to provide some additional
>>> infos.
>>>
>>> I was experiencing the same problem with several USB thumb drives,
>>> especially with some Kingston DataTraveler.
>>>
>>> Changing USB_MAX_XFER_BLK from 65535 to 32767 definitely fixed the "EHCI
>>> timed out on TD" but also fixed a more subtle problem.
>>
>> So the DTSE9 is problematic even on EHCI ? Sigh ... I'll have to look
>> into that one stick deeper, that's real bad.
>>
> 
> Hi Marek,
> 
> yes, I was getting the following error with the Kingston DTSE9 USB 2.0:
> EHCI timed out on TD - token=0x1e008d80
> EHCI timed out on TD - token=0x1e008d80
> EHCI timed out on TD - token=0x1e008d80
> The model is the one in this photo:
> http://katteway.com/images/Kingston-DataTraveler-DTSE9-8GB-USB-Flash-Drive-Silver.jpg
> ID 0951:1689 Kingston Technology DataTraveler SE9
> 
> I'm available if you want any additional info.

I have the same stick and the same problems, but I should be able to
check it with USB analyzer this or next week.

-- 
Best regards,
Marek Vasut

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
  2016-04-18 23:54                                 ` Marek Vasut
@ 2016-04-25  8:16                                   ` Stefan Roese
  0 siblings, 0 replies; 52+ messages in thread
From: Stefan Roese @ 2016-04-25  8:16 UTC (permalink / raw)
  To: u-boot

Hi Marek,

On 19.04.2016 01:54, Marek Vasut wrote:
> On 04/15/2016 02:13 PM, Diego wrote:
>> In data venerd? 15 aprile 2016 12:53:36, Marek Vasut ha scritto:
>>> On 04/14/2016 03:20 PM, Diego wrote:
>>>> On 18.02.2016, Schrempf Frieder wrote:
>>>>> At the moment I have two sticks with the same chip around for which
>>>>> setting USB_MAX_XFER_BLK from 65535 to 32767 fixed the file transfer.
>>>>> Also one of our customers tested a few non-working sticks with this
>>>>> change and reported, that it fixed it for him.
>>>>
>>>> Hi all,
>>>>
>>>> sorry for reopening this thread, but I'd like to provide some additional
>>>> infos.
>>>>
>>>> I was experiencing the same problem with several USB thumb drives,
>>>> especially with some Kingston DataTraveler.
>>>>
>>>> Changing USB_MAX_XFER_BLK from 65535 to 32767 definitely fixed the "EHCI
>>>> timed out on TD" but also fixed a more subtle problem.
>>>
>>> So the DTSE9 is problematic even on EHCI ? Sigh ... I'll have to look
>>> into that one stick deeper, that's real bad.
>>>
>>
>> Hi Marek,
>>
>> yes, I was getting the following error with the Kingston DTSE9 USB 2.0:
>> EHCI timed out on TD - token=0x1e008d80
>> EHCI timed out on TD - token=0x1e008d80
>> EHCI timed out on TD - token=0x1e008d80
>> The model is the one in this photo:
>> http://katteway.com/images/Kingston-DataTraveler-DTSE9-8GB-USB-Flash-Drive-Silver.jpg
>> ID 0951:1689 Kingston Technology DataTraveler SE9
>>
>> I'm available if you want any additional info.
> 
> I have the same stick and the same problems, but I should be able to
> check it with USB analyzer this or next week.

I'm now finally starting to debug this USB key detection problem
on SoCFPGA, introduced with my USB scanning speedup patchset.
My current configuration is the SoCrates board with an USB OTG
cable to attach an USB stick. This is what I get with the
later U-Boot (master branch) and this patch reverted (c998da0d67
"usb: Change power-on / scanning timeout handling":

=> usb start
starting USB...
USB0:   Core Release: 2.93a
dwc_otg_core_host_init: Timeout!
dwc_otg_core_host_init: Timeout!
dwc_otg_core_host_init: Timeout!
dwc_otg_core_host_init: Timeout!
dwc_otg_core_host_init: Timeout!
dwc_otg_core_host_init: Timeout!
dwc_otg_core_host_init: Timeout!
dwc_otg_core_host_init: Timeout!
dwc_otg_core_host_init: Timeout!
dwc_otg_core_host_init: Timeout!
dwc_otg_core_host_init: Timeout!
dwc_otg_core_host_init: Timeout!
dwc_otg_core_host_init: Timeout!
dwc_otg_core_host_init: Timeout!
dwc_otg_core_host_init: Timeout!
scanning bus 0 for devices... 1 USB Device(s) found
=> usb tree
USB device tree:
  1  Hub (480 Mb/s, 0mA)
      U-Boot Root Hub 

This does not change if this patch above is reverted or not.
Does anyone else have these dwc core timeouts?

Thanks,
Stefan

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
  2016-04-15 12:13                               ` Diego
  2016-04-18 23:54                                 ` Marek Vasut
@ 2016-04-27  2:14                                 ` Marek Vasut
  2016-04-27  9:04                                   ` Diego
  1 sibling, 1 reply; 52+ messages in thread
From: Marek Vasut @ 2016-04-27  2:14 UTC (permalink / raw)
  To: u-boot

On 04/15/2016 02:13 PM, Diego wrote:
> In data venerd? 15 aprile 2016 12:53:36, Marek Vasut ha scritto:
>> On 04/14/2016 03:20 PM, Diego wrote:
>>> On 18.02.2016, Schrempf Frieder wrote:
>>>> At the moment I have two sticks with the same chip around for which
>>>> setting USB_MAX_XFER_BLK from 65535 to 32767 fixed the file transfer.
>>>> Also one of our customers tested a few non-working sticks with this
>>>> change and reported, that it fixed it for him.
>>>
>>> Hi all,
>>>
>>> sorry for reopening this thread, but I'd like to provide some additional
>>> infos.
>>>
>>> I was experiencing the same problem with several USB thumb drives,
>>> especially with some Kingston DataTraveler.
>>>
>>> Changing USB_MAX_XFER_BLK from 65535 to 32767 definitely fixed the "EHCI
>>> timed out on TD" but also fixed a more subtle problem.
>>
>> So the DTSE9 is problematic even on EHCI ? Sigh ... I'll have to look
>> into that one stick deeper, that's real bad.
>>
> 
> Hi Marek,
> 
> yes, I was getting the following error with the Kingston DTSE9 USB 2.0:
> EHCI timed out on TD - token=0x1e008d80
> EHCI timed out on TD - token=0x1e008d80
> EHCI timed out on TD - token=0x1e008d80
> The model is the one in this photo:
> http://katteway.com/images/Kingston-DataTraveler-DTSE9-8GB-USB-Flash-Drive-Silver.jpg
> ID 0951:1689 Kingston Technology DataTraveler SE9
> 
> I'm available if you want any additional info.

This Kingston DTSE9 seems to be really pure evil. I connected it to
TotalPhase Beagle USB 480 and plugged it into a PC and the bloody
stick generates broken packets at the beginning. I suspect this is
so bad that it crashes DWC2 controller if plugged directly into it.

I didn't try investigating it with another EHCI controller yet.
Which CPU do you use on your system?

> Bests,
> Diego
> 


-- 
Best regards,
Marek Vasut

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
  2016-04-27  2:14                                 ` Marek Vasut
@ 2016-04-27  9:04                                   ` Diego
  2016-04-27 16:13                                     ` Marek Vasut
  0 siblings, 1 reply; 52+ messages in thread
From: Diego @ 2016-04-27  9:04 UTC (permalink / raw)
  To: u-boot



Il 27 aprile 2016 04:14:45 CEST, Marek Vasut <marex@denx.de> ha scritto:
>On 04/15/2016 02:13 PM, Diego wrote:
>> 
>> Hi Marek,
>> 
>> yes, I was getting the following error with the Kingston DTSE9 USB
>2.0:
>> EHCI timed out on TD - token=0x1e008d80
>> EHCI timed out on TD - token=0x1e008d80
>> EHCI timed out on TD - token=0x1e008d80
>> The model is the one in this photo:
>>
>http://katteway.com/images/Kingston-DataTraveler-DTSE9-8GB-USB-Flash-Drive-Silver.jpg
>> ID 0951:1689 Kingston Technology DataTraveler SE9
>> 
>> I'm available if you want any additional info.
>
>This Kingston DTSE9 seems to be really pure evil. I connected it to
>TotalPhase Beagle USB 480 and plugged it into a PC and the bloody
>stick generates broken packets at the beginning. I suspect this is
>so bad that it crashes DWC2 controller if plugged directly into it.
>
>I didn't try investigating it with another EHCI controller yet.
>Which CPU do you use on your system?
>

Hi Marek,

I'm using a Boundary Devices Nitrogen6x with Freescale / NXP i.MX6Q SOC.

Bests,
Diego

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
  2016-04-27  9:04                                   ` Diego
@ 2016-04-27 16:13                                     ` Marek Vasut
  2016-04-28 13:04                                       ` Diego
  0 siblings, 1 reply; 52+ messages in thread
From: Marek Vasut @ 2016-04-27 16:13 UTC (permalink / raw)
  To: u-boot

On 04/27/2016 11:04 AM, Diego wrote:
> 
> 
> Il 27 aprile 2016 04:14:45 CEST, Marek Vasut <marex@denx.de> ha scritto:
>> On 04/15/2016 02:13 PM, Diego wrote:
>>>
>>> Hi Marek,
>>>
>>> yes, I was getting the following error with the Kingston DTSE9 USB
>> 2.0:
>>> EHCI timed out on TD - token=0x1e008d80
>>> EHCI timed out on TD - token=0x1e008d80
>>> EHCI timed out on TD - token=0x1e008d80
>>> The model is the one in this photo:
>>>
>> http://katteway.com/images/Kingston-DataTraveler-DTSE9-8GB-USB-Flash-Drive-Silver.jpg
>>> ID 0951:1689 Kingston Technology DataTraveler SE9
>>>
>>> I'm available if you want any additional info.
>>
>> This Kingston DTSE9 seems to be really pure evil. I connected it to
>> TotalPhase Beagle USB 480 and plugged it into a PC and the bloody
>> stick generates broken packets at the beginning. I suspect this is
>> so bad that it crashes DWC2 controller if plugged directly into it.
>>
>> I didn't try investigating it with another EHCI controller yet.
>> Which CPU do you use on your system?
>>
> 
> Hi Marek,
> 
> I'm using a Boundary Devices Nitrogen6x with Freescale / NXP i.MX6Q SOC.

OK, I have to two identical sticks and neither has the same USB ID as
yours. Can you do lsusb -vvv -d 0951:1689 ?


-- 
Best regards,
Marek Vasut

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
  2016-04-27 16:13                                     ` Marek Vasut
@ 2016-04-28 13:04                                       ` Diego
  2016-04-28 22:49                                         ` Marek Vasut
  0 siblings, 1 reply; 52+ messages in thread
From: Diego @ 2016-04-28 13:04 UTC (permalink / raw)
  To: u-boot

In data mercoled? 27 aprile 2016 18:13:51, Marek Vasut ha scritto:
> 
> OK, I have to two identical sticks and neither has the same USB ID as
> yours. Can you do lsusb -vvv -d 0951:1689 ?

Hi Marek,

thanks for taking the time to look into this.
Here you are:
# lsusb -vvv -d 0951:1689

Bus 003 Device 020: ID 0951:1689 Kingston Technology DataTraveler SE9
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x0951 Kingston Technology
  idProduct          0x1689 DataTraveler SE9
  bcdDevice            1.00
  iManufacturer           1 Kingston
  iProduct                2 DataTraveler SE9
  iSerial                 3 0019E06B084BFD10470133E8
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk-Only
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 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     0x0200  1x 512 bytes
        bInterval             255
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            0 
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  bNumConfigurations      1
can't get debug descriptor: Resource temporarily unavailable
Device Status:     0x0000
  (Bus Powered)





Bests,
Diego

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
  2016-04-28 13:04                                       ` Diego
@ 2016-04-28 22:49                                         ` Marek Vasut
  2016-04-29  7:58                                           ` Diego
  0 siblings, 1 reply; 52+ messages in thread
From: Marek Vasut @ 2016-04-28 22:49 UTC (permalink / raw)
  To: u-boot

On 04/28/2016 03:04 PM, Diego wrote:
> In data mercoled? 27 aprile 2016 18:13:51, Marek Vasut ha scritto:
>>
>> OK, I have to two identical sticks and neither has the same USB ID as
>> yours. Can you do lsusb -vvv -d 0951:1689 ?
> 
> Hi Marek,
> 
> thanks for taking the time to look into this.
> Here you are:
> # lsusb -vvv -d 0951:1689
> 
> Bus 003 Device 020: ID 0951:1689 Kingston Technology DataTraveler SE9
> Device Descriptor:
>   bLength                18
>   bDescriptorType         1
>   bcdUSB               2.00
>   bDeviceClass            0 
>   bDeviceSubClass         0 
>   bDeviceProtocol         0 
>   bMaxPacketSize0        64
>   idVendor           0x0951 Kingston Technology
>   idProduct          0x1689 DataTraveler SE9
>   bcdDevice            1.00
>   iManufacturer           1 Kingston
>   iProduct                2 DataTraveler SE9
>   iSerial                 3 0019E06B084BFD10470133E8
>   bNumConfigurations      1
>   Configuration Descriptor:
>     bLength                 9
>     bDescriptorType         2
>     wTotalLength           32
>     bNumInterfaces          1
>     bConfigurationValue     1
>     iConfiguration          0 
>     bmAttributes         0x80
>       (Bus Powered)
>     MaxPower              100mA
>     Interface Descriptor:
>       bLength                 9
>       bDescriptorType         4
>       bInterfaceNumber        0
>       bAlternateSetting       0
>       bNumEndpoints           2
>       bInterfaceClass         8 Mass Storage
>       bInterfaceSubClass      6 SCSI
>       bInterfaceProtocol     80 Bulk-Only
>       iInterface              0 
>       Endpoint Descriptor:
>         bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x81  EP 1 IN
>         bmAttributes            2
>           Transfer Type            Bulk
>           Synch Type               None
>           Usage Type               Data
>         wMaxPacketSize     0x0200  1x 512 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     0x0200  1x 512 bytes
>         bInterval             255
> Device Qualifier (for other device speed):
>   bLength                10
>   bDescriptorType         6
>   bcdUSB               2.00
>   bDeviceClass            0 
>   bDeviceSubClass         0 
>   bDeviceProtocol         0 
>   bMaxPacketSize0        64
>   bNumConfigurations      1
> can't get debug descriptor: Resource temporarily unavailable
> Device Status:     0x0000
>   (Bus Powered)

Urgh, so you seem to have third revision of this stick. I have two
sticks which are exactly the same and work in U-Boot on MX6 wandboard:

=> usb reset
resetting USB...
USB0:   Port not available.
USB1:   USB EHCI 1.00
scanning bus 1 for devices... 2 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
=> usb info
1: Hub,  USB Revision 2.0
 - u-boot EHCI Host Controller
 - Class: Hub
 - PacketSize: 64  Configurations: 1
 - Vendor: 0x0000  Product 0x0000 Version 1.0
   Configuration: 1
   - Interfaces: 1 Self Powered 0mA
     Interface: 0
     - Alternate Setting 0, Endpoints: 1
     - Class Hub
     - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms

2: Mass Storage,  USB Revision 2.0
 - Kingston DataTraveler 2.0 C86000BDB6FFB0201A35968E
 - Class: (from Interface) Mass Storage
 - PacketSize: 64  Configurations: 1
 - Vendor: 0x0930  Product 0x6545 Version 1.16
   Configuration: 1
   - Interfaces: 1 Bus Powered 300mA
     Interface: 0
     - Alternate Setting 0, Endpoints: 2
     - Class Mass Storage, Transp. SCSI, Bulk only
     - Endpoint 1 In Bulk MaxPacket 512
     - Endpoint 2 Out Bulk MaxPacket 512

=> usb reset
resetting USB...
EHCI failed to shut down host controller.
USB0:   Port not available.
USB1:   USB EHCI 1.00
scanning bus 1 for devices... 2 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
=> usb info
1: Hub,  USB Revision 2.0
 - u-boot EHCI Host Controller
 - Class: Hub
 - PacketSize: 64  Configurations: 1
 - Vendor: 0x0000  Product 0x0000 Version 1.0
   Configuration: 1
   - Interfaces: 1 Self Powered 0mA
     Interface: 0
     - Alternate Setting 0, Endpoints: 1
     - Class Hub
     - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms

2: Mass Storage,  USB Revision 2.0
 - Kingston DataTraveler 2.0 001A4D5F1A5C1010B9445765
 - Class: (from Interface) Mass Storage
 - PacketSize: 64  Configurations: 1
 - Vendor: 0x0951  Product 0x1665 Version 2.0
   Configuration: 1
   - Interfaces: 1 Bus Powered 100mA
     Interface: 0
     - Alternate Setting 0, Endpoints: 2
     - Class Mass Storage, Transp. SCSI, Bulk only
     - Endpoint 1 In Bulk MaxPacket 512
     - Endpoint 2 Out Bulk MaxPacket 512

-- 
Best regards,
Marek Vasut

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
  2016-04-28 22:49                                         ` Marek Vasut
@ 2016-04-29  7:58                                           ` Diego
  2016-05-03 21:01                                             ` Marek Vasut
  0 siblings, 1 reply; 52+ messages in thread
From: Diego @ 2016-04-29  7:58 UTC (permalink / raw)
  To: u-boot

In data venerd? 29 aprile 2016 00:49:22, Marek Vasut ha scritto:
> 
> Urgh, so you seem to have third revision of this stick. I have two
> sticks which are exactly the same and work in U-Boot on MX6 wandboard:
> 

Hi Marek,

how big is the file you're trying to load?
For me it fails for files bigger than 16MB:
U-Boot > usb info
1: Hub,  USB Revision 2.0
 - u-boot EHCI Host Controller 
 - Class: Hub
 - PacketSize: 64  Configurations: 1
 - Vendor: 0x0000  Product 0x0000 Version 1.0
   Configuration: 1
   - Interfaces: 1 Self Powered 0mA
     Interface: 0
     - Alternate Setting 0, Endpoints: 1
     - Class Hub
     - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms

2: Hub,  USB Revision 2.0
 - Class: Hub
 - PacketSize: 64  Configurations: 1
 - Vendor: 0x0424  Product 0x2513 Version 11.179
   Configuration: 1
   - Interfaces: 1 Self Powered Remote Wakeup 2mA
     Interface: 0
     - Alternate Setting 0, Endpoints: 1
     - Class Hub
     - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms
     - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms

3: Mass Storage,  USB Revision 2.0
 - Kingston DataTraveler SE9 0019E06B084BFD10470133E8
 - Class: (from Interface) Mass Storage
 - PacketSize: 64  Configurations: 1
 - Vendor: 0x0951  Product 0x1689 Version 1.0
   Configuration: 1
   - Interfaces: 1 Bus Powered 100mA
     Interface: 0
     - Alternate Setting 0, Endpoints: 2
     - Class Mass Storage, Transp. SCSI, Bulk only
     - Endpoint 1 In Bulk MaxPacket 512
     - Endpoint 2 Out Bulk MaxPacket 512

U-Boot > load usb 0:1 0x10008000 file1.raw
reading file1.raw
1048576 bytes read in 59 ms (16.9 MiB/s)
U-Boot > load usb 0:1 0x10008000 file2.raw
reading file2.raw
2097152 bytes read in 102 ms (19.6 MiB/s)
U-Boot > load usb 0:1 0x10008000 file4.raw
reading file4.raw
4194304 bytes read in 175 ms (22.9 MiB/s)
U-Boot > load usb 0:1 0x10008000 file6.raw
reading file6.raw
6291456 bytes read in 255 ms (23.5 MiB/s)
U-Boot > load usb 0:1 0x10008000 file8.raw
reading file8.raw
8388608 bytes read in 334 ms (24 MiB/s)
U-Boot > load usb 0:1 0x10008000 file10.raw
reading file10.raw
10485760 bytes read in 408 ms (24.5 MiB/s)
U-Boot > load usb 0:1 0x10008000 file15.raw
reading file15.raw
15728640 bytes read in 603 ms (24.9 MiB/s)
U-Boot > load usb 0:1 0x10008000 file16.raw
reading file16.raw
EHCI timed out on TD - token=0x90008d80
EHCI timed out on TD - token=0x10008d80
EHCI timed out on TD - token=0x10008d80
Error reading cluster
** Unable to read file file16.raw **
U-Boot > load usb 0:1 0x10008000 file20.raw
reading file20.raw
EHCI timed out on TD - token=0xd0008d80
EHCI timed out on TD - token=0x50008d80
EHCI timed out on TD - token=0x50008d80
Error reading cluster
** Unable to read file file20.raw **
U-Boot > load usb 0:1 0x10008000 file40.raw
reading file40.raw
EHCI timed out on TD - token=0x1e008d80
EHCI timed out on TD - token=0x1e008d80
EHCI timed out on TD - token=0x1e008d80
Error reading cluster
** Unable to read file file40.raw **
U-Boot >

Bests,
Diego

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
  2016-04-29  7:58                                           ` Diego
@ 2016-05-03 21:01                                             ` Marek Vasut
  2016-05-04  9:13                                               ` Diego
  0 siblings, 1 reply; 52+ messages in thread
From: Marek Vasut @ 2016-05-03 21:01 UTC (permalink / raw)
  To: u-boot

On 04/29/2016 09:58 AM, Diego wrote:
> In data venerd? 29 aprile 2016 00:49:22, Marek Vasut ha scritto:
>>
>> Urgh, so you seem to have third revision of this stick. I have two
>> sticks which are exactly the same and work in U-Boot on MX6 wandboard:
>>
> 
> Hi Marek,
> 
> how big is the file you're trying to load?
> For me it fails for files bigger than 16MB:

Ha ok, I see it now. According to the bus analyzer, the stick Acks long
block transfer, but then just times out, I guess because it prepares the
data or something. Just a dummy question, did you try reducing
USB_MAX_XFER_BLK ? Try with 4096 instead of 65536 , that might work.

> U-Boot > usb info
> 1: Hub,  USB Revision 2.0
>  - u-boot EHCI Host Controller 
>  - Class: Hub
>  - PacketSize: 64  Configurations: 1
>  - Vendor: 0x0000  Product 0x0000 Version 1.0
>    Configuration: 1
>    - Interfaces: 1 Self Powered 0mA
>      Interface: 0
>      - Alternate Setting 0, Endpoints: 1
>      - Class Hub
>      - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms
> 
> 2: Hub,  USB Revision 2.0
>  - Class: Hub
>  - PacketSize: 64  Configurations: 1
>  - Vendor: 0x0424  Product 0x2513 Version 11.179
>    Configuration: 1
>    - Interfaces: 1 Self Powered Remote Wakeup 2mA
>      Interface: 0
>      - Alternate Setting 0, Endpoints: 1
>      - Class Hub
>      - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms
>      - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms
> 
> 3: Mass Storage,  USB Revision 2.0
>  - Kingston DataTraveler SE9 0019E06B084BFD10470133E8
>  - Class: (from Interface) Mass Storage
>  - PacketSize: 64  Configurations: 1
>  - Vendor: 0x0951  Product 0x1689 Version 1.0
>    Configuration: 1
>    - Interfaces: 1 Bus Powered 100mA
>      Interface: 0
>      - Alternate Setting 0, Endpoints: 2
>      - Class Mass Storage, Transp. SCSI, Bulk only
>      - Endpoint 1 In Bulk MaxPacket 512
>      - Endpoint 2 Out Bulk MaxPacket 512
> 
> U-Boot > load usb 0:1 0x10008000 file1.raw
> reading file1.raw
> 1048576 bytes read in 59 ms (16.9 MiB/s)
> U-Boot > load usb 0:1 0x10008000 file2.raw
> reading file2.raw
> 2097152 bytes read in 102 ms (19.6 MiB/s)
> U-Boot > load usb 0:1 0x10008000 file4.raw
> reading file4.raw
> 4194304 bytes read in 175 ms (22.9 MiB/s)
> U-Boot > load usb 0:1 0x10008000 file6.raw
> reading file6.raw
> 6291456 bytes read in 255 ms (23.5 MiB/s)
> U-Boot > load usb 0:1 0x10008000 file8.raw
> reading file8.raw
> 8388608 bytes read in 334 ms (24 MiB/s)
> U-Boot > load usb 0:1 0x10008000 file10.raw
> reading file10.raw
> 10485760 bytes read in 408 ms (24.5 MiB/s)
> U-Boot > load usb 0:1 0x10008000 file15.raw
> reading file15.raw
> 15728640 bytes read in 603 ms (24.9 MiB/s)
> U-Boot > load usb 0:1 0x10008000 file16.raw
> reading file16.raw
> EHCI timed out on TD - token=0x90008d80
> EHCI timed out on TD - token=0x10008d80
> EHCI timed out on TD - token=0x10008d80
> Error reading cluster
> ** Unable to read file file16.raw **
> U-Boot > load usb 0:1 0x10008000 file20.raw
> reading file20.raw
> EHCI timed out on TD - token=0xd0008d80
> EHCI timed out on TD - token=0x50008d80
> EHCI timed out on TD - token=0x50008d80
> Error reading cluster
> ** Unable to read file file20.raw **
> U-Boot > load usb 0:1 0x10008000 file40.raw
> reading file40.raw
> EHCI timed out on TD - token=0x1e008d80
> EHCI timed out on TD - token=0x1e008d80
> EHCI timed out on TD - token=0x1e008d80
> Error reading cluster
> ** Unable to read file file40.raw **
> U-Boot >
> 
> Bests,
> Diego
> 


-- 
Best regards,
Marek Vasut

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
  2016-05-03 21:01                                             ` Marek Vasut
@ 2016-05-04  9:13                                               ` Diego
  2016-05-04 11:45                                                 ` Marek Vasut
  0 siblings, 1 reply; 52+ messages in thread
From: Diego @ 2016-05-04  9:13 UTC (permalink / raw)
  To: u-boot

In data marted? 3 maggio 2016 23:01:10, Marek Vasut ha scritto:
> On 04/29/2016 09:58 AM, Diego wrote:
> > In data venerd? 29 aprile 2016 00:49:22, Marek Vasut ha scritto:
> >> Urgh, so you seem to have third revision of this stick. I have two
> > 
> >> sticks which are exactly the same and work in U-Boot on MX6 wandboard:
> > Hi Marek,
> > 
> > how big is the file you're trying to load?
> >
> > For me it fails for files bigger than 16MB:
>
> Ha ok, I see it now. According to the bus analyzer, the stick Acks long
> block transfer, but then just times out, I guess because it prepares the
> data or something. Just a dummy question, did you try reducing
> USB_MAX_XFER_BLK ? Try with 4096 instead of 65536 , that might work.
> 

Hi Marek,

that was the original argument of my mail thread:
http://lists.denx.de/pipermail/u-boot/2016-April/251799.html
Changing USB_MAX_XFER_BLK from 65535 to 32767 definitely fixed the "EHCI timed 
out on TD".

I was questioning what was the best approach to fix the problem.
It seems that 65536 doesn't work for quite some USB thumb drives. Seeing my 
experience, my coworker's experience, and previous mails in this same thread, 
I'd guess something like 50% or lower work with 65535, while something like 
90% or more work with 32767.
http://lists.denx.de/pipermail/u-boot/2016-February/245893.html

So I see three options:
1) 65535 default with quirk table
2) 32767 default without quirk table
3) 32767 default with quirk table

Personally I think 3) would be the safest solution, but I think 2) would at 
least work for most thumb drives.
As the transfer speed wouldn't be affected much for 32767:
http://lists.denx.de/pipermail/u-boot/2016-February/246267.html
and as the quirk table for 65535 would grow quite a lot with time, I think.

Bests,
Diego

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
  2016-05-04  9:13                                               ` Diego
@ 2016-05-04 11:45                                                 ` Marek Vasut
  2016-05-04 14:06                                                   ` Diego
  0 siblings, 1 reply; 52+ messages in thread
From: Marek Vasut @ 2016-05-04 11:45 UTC (permalink / raw)
  To: u-boot

On 05/04/2016 11:13 AM, Diego wrote:
> In data marted? 3 maggio 2016 23:01:10, Marek Vasut ha scritto:
>> On 04/29/2016 09:58 AM, Diego wrote:
>>> In data venerd? 29 aprile 2016 00:49:22, Marek Vasut ha scritto:
>>>> Urgh, so you seem to have third revision of this stick. I have two
>>>
>>>> sticks which are exactly the same and work in U-Boot on MX6 wandboard:
>>> Hi Marek,
>>>
>>> how big is the file you're trying to load?
>>>
>>> For me it fails for files bigger than 16MB:
>>
>> Ha ok, I see it now. According to the bus analyzer, the stick Acks long
>> block transfer, but then just times out, I guess because it prepares the
>> data or something. Just a dummy question, did you try reducing
>> USB_MAX_XFER_BLK ? Try with 4096 instead of 65536 , that might work.
>>
> 
> Hi Marek,
> 
> that was the original argument of my mail thread:
> http://lists.denx.de/pipermail/u-boot/2016-April/251799.html
> Changing USB_MAX_XFER_BLK from 65535 to 32767 definitely fixed the "EHCI timed 
> out on TD".
> 
> I was questioning what was the best approach to fix the problem.
> It seems that 65536 doesn't work for quite some USB thumb drives. Seeing my 
> experience, my coworker's experience, and previous mails in this same thread, 
> I'd guess something like 50% or lower work with 65535, while something like 
> 90% or more work with 32767.
> http://lists.denx.de/pipermail/u-boot/2016-February/245893.html
> 
> So I see three options:
> 1) 65535 default with quirk table
> 2) 32767 default without quirk table
> 3) 32767 default with quirk table
> 
> Personally I think 3) would be the safest solution, but I think 2) would at 
> least work for most thumb drives.

1) with the quirk table would be the way to go, modern(ish) drives
should work fine with 65535 .

> As the transfer speed wouldn't be affected much for 32767:
> http://lists.denx.de/pipermail/u-boot/2016-February/246267.html
> and as the quirk table for 65535 would grow quite a lot with time, I think.

Yeah, but with old drives only, which I think is soon gonna be moot.

> Bests,
> Diego
> 


-- 
Best regards,
Marek Vasut

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
  2016-05-04 11:45                                                 ` Marek Vasut
@ 2016-05-04 14:06                                                   ` Diego
  2016-05-04 21:36                                                     ` Marek Vasut
  0 siblings, 1 reply; 52+ messages in thread
From: Diego @ 2016-05-04 14:06 UTC (permalink / raw)
  To: u-boot

In data mercoled? 4 maggio 2016 13:45:57, Marek Vasut ha scritto:
> On 05/04/2016 11:13 AM, Diego wrote:
> > In data marted? 3 maggio 2016 23:01:10, Marek Vasut ha scritto:
> >> On 04/29/2016 09:58 AM, Diego wrote:
> >>> For me it fails for files bigger than 16MB:
> >> Ha ok, I see it now. According to the bus analyzer, the stick Acks long
> >> block transfer, but then just times out, I guess because it prepares the
> >> data or something. Just a dummy question, did you try reducing
> >> USB_MAX_XFER_BLK ? Try with 4096 instead of 65536 , that might work.
> > 
> > Hi Marek,
> > 
> > that was the original argument of my mail thread:
> > http://lists.denx.de/pipermail/u-boot/2016-April/251799.html
> > Changing USB_MAX_XFER_BLK from 65535 to 32767 definitely fixed the "EHCI
> > timed out on TD".
> > 
> > I was questioning what was the best approach to fix the problem.
> > It seems that 65536 doesn't work for quite some USB thumb drives. Seeing
> > my
> > experience, my coworker's experience, and previous mails in this same
> > thread, I'd guess something like 50% or lower work with 65535, while
> > something like 90% or more work with 32767.
> > http://lists.denx.de/pipermail/u-boot/2016-February/245893.html
> > 
> > So I see three options:
> > 1) 65535 default with quirk table
> > 2) 32767 default without quirk table
> > 3) 32767 default with quirk table
> > 
> > Personally I think 3) would be the safest solution, but I think 2) would
> > at
> > least work for most thumb drives.
> 
> 1) with the quirk table would be the way to go, modern(ish) drives
> should work fine with 65535 .
> 

I personally can't see any improvement with more recent thumb drives, quite 
the opposite.
WORKING WITH 65535:
- ancient Sandisk 256MB
	ID 0781:5151 SanDisk Corp. Cruzer Micro Flash Drive
- old Sony 8GB
	ID 054c:0243 Sony Corp. MicroVault Flash Drive
- recent Kingston DT101 G2 16GB
	ID 0951:1642 Kingston Technology DT101 G2

NOT WORKING WITH 65535:
- recent Kingston G3 16GB
	ID 0951:1665 Kingston Technology Digital DataTraveler SE9 64GB
- new Kingston USB 2.0 8GB
	ID 0951:1689 Kingston Technology DataTraveler SE9
- brand new Kingston G2 16GB / 32GB USB 3.0
	ID 0951:1666 Kingston Technology DataTraveler G4

Why are you saying modern(ish) drives should work?

For others following the thread, please post your experience, especially with 
more recent drives (remember to test with files >16MB).

Diego

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
  2016-05-04 14:06                                                   ` Diego
@ 2016-05-04 21:36                                                     ` Marek Vasut
  2016-05-10 12:04                                                       ` Diego
  0 siblings, 1 reply; 52+ messages in thread
From: Marek Vasut @ 2016-05-04 21:36 UTC (permalink / raw)
  To: u-boot

On 05/04/2016 04:06 PM, Diego wrote:
> In data mercoled? 4 maggio 2016 13:45:57, Marek Vasut ha scritto:
>> On 05/04/2016 11:13 AM, Diego wrote:
>>> In data marted? 3 maggio 2016 23:01:10, Marek Vasut ha scritto:
>>>> On 04/29/2016 09:58 AM, Diego wrote:
>>>>> For me it fails for files bigger than 16MB:
>>>> Ha ok, I see it now. According to the bus analyzer, the stick Acks long
>>>> block transfer, but then just times out, I guess because it prepares the
>>>> data or something. Just a dummy question, did you try reducing
>>>> USB_MAX_XFER_BLK ? Try with 4096 instead of 65536 , that might work.
>>>
>>> Hi Marek,
>>>
>>> that was the original argument of my mail thread:
>>> http://lists.denx.de/pipermail/u-boot/2016-April/251799.html
>>> Changing USB_MAX_XFER_BLK from 65535 to 32767 definitely fixed the "EHCI
>>> timed out on TD".
>>>
>>> I was questioning what was the best approach to fix the problem.
>>> It seems that 65536 doesn't work for quite some USB thumb drives. Seeing
>>> my
>>> experience, my coworker's experience, and previous mails in this same
>>> thread, I'd guess something like 50% or lower work with 65535, while
>>> something like 90% or more work with 32767.
>>> http://lists.denx.de/pipermail/u-boot/2016-February/245893.html
>>>
>>> So I see three options:
>>> 1) 65535 default with quirk table
>>> 2) 32767 default without quirk table
>>> 3) 32767 default with quirk table
>>>
>>> Personally I think 3) would be the safest solution, but I think 2) would
>>> at
>>> least work for most thumb drives.
>>
>> 1) with the quirk table would be the way to go, modern(ish) drives
>> should work fine with 65535 .
>>
> 
> I personally can't see any improvement with more recent thumb drives, quite 
> the opposite.
> WORKING WITH 65535:
> - ancient Sandisk 256MB
> 	ID 0781:5151 SanDisk Corp. Cruzer Micro Flash Drive
> - old Sony 8GB
> 	ID 054c:0243 Sony Corp. MicroVault Flash Drive
> - recent Kingston DT101 G2 16GB
> 	ID 0951:1642 Kingston Technology DT101 G2
> 
> NOT WORKING WITH 65535:
> - recent Kingston G3 16GB
> 	ID 0951:1665 Kingston Technology Digital DataTraveler SE9 64GB
> - new Kingston USB 2.0 8GB
> 	ID 0951:1689 Kingston Technology DataTraveler SE9
> - brand new Kingston G2 16GB / 32GB USB 3.0
> 	ID 0951:1666 Kingston Technology DataTraveler G4
> 
> Why are you saying modern(ish) drives should work?

Hmmmmm :-(

> For others following the thread, please post your experience, especially with 
> more recent drives (remember to test with files >16MB).

I don't think it's really worth doing a thread about which sticks work
and which don't. I would find it much more valuable to address this
issue properly. I wonder if it would make sense to, instead of starting
with a big value which might not work, start with a small(er) value and
increase it with each subsequent block transfer. Quite similarly to what
TCP does. Would you be willing to look into it ?

> Diego
> 


-- 
Best regards,
Marek Vasut

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
  2016-05-04 21:36                                                     ` Marek Vasut
@ 2016-05-10 12:04                                                       ` Diego
  2016-05-10 12:32                                                         ` Marek Vasut
  0 siblings, 1 reply; 52+ messages in thread
From: Diego @ 2016-05-10 12:04 UTC (permalink / raw)
  To: u-boot

In data mercoled? 4 maggio 2016 23:36:46, Marek Vasut ha scritto:
> On 05/04/2016 04:06 PM, Diego wrote:
> > In data mercoled? 4 maggio 2016 13:45:57, Marek Vasut ha scritto:
> >> On 05/04/2016 11:13 AM, Diego wrote:
> >>> <snip>
> >>> So I see three options:
> >>> 1) 65535 default with quirk table
> >>> 2) 32767 default without quirk table
> >>> 3) 32767 default with quirk table
> >>> 
> >>> Personally I think 3) would be the safest solution, but I think 2) would
> >>> at
> >>> least work for most thumb drives.
> >> 
> >> 1) with the quirk table would be the way to go, modern(ish) drives
> >> should work fine with 65535 .
> > 
> > I personally can't see any improvement with more recent thumb drives,
> > quite the opposite.
> >
> > <snip>
> > Why are you saying modern(ish) drives should work?
> 
> Hmmmmm :-(
> 
> > For others following the thread, please post your experience, especially
> > with more recent drives (remember to test with files >16MB).
> 
> I don't think it's really worth doing a thread about which sticks work
> and which don't. I would find it much more valuable to address this
> issue properly. I wonder if it would make sense to, instead of starting
> with a big value which might not work, start with a small(er) value and
> increase it with each subsequent block transfer. Quite similarly to what
> TCP does. Would you be willing to look into it ?
> 

Hi Marek,

so your proposal is to ramp up transferred block size during transfer?
What's the rationale behind the proposal? In other words, why do you think it 
will fix the problem?

Regarding implementing your proposal, it might take me very long to find some 
time to dedicate to it, so if anybody else wants to step up before I look at 
it, just raise your hand.

Bests,
Diego

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
  2016-05-10 12:04                                                       ` Diego
@ 2016-05-10 12:32                                                         ` Marek Vasut
  2016-05-20  5:07                                                           ` Rajesh Bhagat
  0 siblings, 1 reply; 52+ messages in thread
From: Marek Vasut @ 2016-05-10 12:32 UTC (permalink / raw)
  To: u-boot

On 05/10/2016 02:04 PM, Diego wrote:
> In data mercoled? 4 maggio 2016 23:36:46, Marek Vasut ha scritto:
>> On 05/04/2016 04:06 PM, Diego wrote:
>>> In data mercoled? 4 maggio 2016 13:45:57, Marek Vasut ha scritto:
>>>> On 05/04/2016 11:13 AM, Diego wrote:
>>>>> <snip>
>>>>> So I see three options:
>>>>> 1) 65535 default with quirk table
>>>>> 2) 32767 default without quirk table
>>>>> 3) 32767 default with quirk table
>>>>>
>>>>> Personally I think 3) would be the safest solution, but I think 2) would
>>>>> at
>>>>> least work for most thumb drives.
>>>>
>>>> 1) with the quirk table would be the way to go, modern(ish) drives
>>>> should work fine with 65535 .
>>>
>>> I personally can't see any improvement with more recent thumb drives,
>>> quite the opposite.
>>>
>>> <snip>
>>> Why are you saying modern(ish) drives should work?
>>
>> Hmmmmm :-(
>>
>>> For others following the thread, please post your experience, especially
>>> with more recent drives (remember to test with files >16MB).
>>
>> I don't think it's really worth doing a thread about which sticks work
>> and which don't. I would find it much more valuable to address this
>> issue properly. I wonder if it would make sense to, instead of starting
>> with a big value which might not work, start with a small(er) value and
>> increase it with each subsequent block transfer. Quite similarly to what
>> TCP does. Would you be willing to look into it ?
>>
> 
> Hi Marek,

Hi!

> so your proposal is to ramp up transferred block size during transfer?
> What's the rationale behind the proposal? In other words, why do you think it 
> will fix the problem?

You will get one transfer failure somewhere in the middle and this will
let you determine the maximum transfer size for particular stick.

> Regarding implementing your proposal, it might take me very long to find some 
> time to dedicate to it, so if anybody else wants to step up before I look at 
> it, just raise your hand.

OK

> Bests,
> Diego
> 


-- 
Best regards,
Marek Vasut

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
  2016-05-10 12:32                                                         ` Marek Vasut
@ 2016-05-20  5:07                                                           ` Rajesh Bhagat
  2016-05-20 11:52                                                             ` Marek Vasut
  0 siblings, 1 reply; 52+ messages in thread
From: Rajesh Bhagat @ 2016-05-20  5:07 UTC (permalink / raw)
  To: u-boot



> -----Original Message-----
> From: U-Boot [mailto:u-boot-bounces at lists.denx.de] On Behalf Of Marek Vasut
> Sent: Tuesday, May 10, 2016 6:02 PM
> To: Diego <diego.ml@zoho.com>
> Cc: u-boot at lists.denx.de; Stefan Roese <sr@denx.de>
> Subject: Re: [U-Boot] Issue with USB mass storage (thumb drives)
> 
> On 05/10/2016 02:04 PM, Diego wrote:
> > In data mercoled? 4 maggio 2016 23:36:46, Marek Vasut ha scritto:
> >> On 05/04/2016 04:06 PM, Diego wrote:
> >>> In data mercoled? 4 maggio 2016 13:45:57, Marek Vasut ha scritto:
> >>>> On 05/04/2016 11:13 AM, Diego wrote:
> >>>>> <snip>
> >>>>> So I see three options:
> >>>>> 1) 65535 default with quirk table
> >>>>> 2) 32767 default without quirk table
> >>>>> 3) 32767 default with quirk table
> >>>>>
> >>>>> Personally I think 3) would be the safest solution, but I think 2)
> >>>>> would at least work for most thumb drives.
> >>>>
> >>>> 1) with the quirk table would be the way to go, modern(ish) drives
> >>>> should work fine with 65535 .
> >>>
> >>> I personally can't see any improvement with more recent thumb
> >>> drives, quite the opposite.
> >>>
> >>> <snip>
> >>> Why are you saying modern(ish) drives should work?
> >>
> >> Hmmmmm :-(
> >>
> >>> For others following the thread, please post your experience,
> >>> especially with more recent drives (remember to test with files >16MB).
> >>
> >> I don't think it's really worth doing a thread about which sticks
> >> work and which don't. I would find it much more valuable to address
> >> this issue properly. I wonder if it would make sense to, instead of
> >> starting with a big value which might not work, start with a
> >> small(er) value and increase it with each subsequent block transfer.
> >> Quite similarly to what TCP does. Would you be willing to look into it ?
> >>
> >
> > Hi Marek,
> 
> Hi!
> 
> > so your proposal is to ramp up transferred block size during transfer?
> > What's the rationale behind the proposal? In other words, why do you
> > think it will fix the problem?
> 
> You will get one transfer failure somewhere in the middle and this will let you
> determine the maximum transfer size for particular stick.
> 
> > Regarding implementing your proposal, it might take me very long to
> > find some time to dedicate to it, so if anybody else wants to step up
> > before I look at it, just raise your hand.
> 
> OK
> 

Hello Marek, 

I have a question regarding USB_MAX_XFER_BLK macro, Why XHCI code doesn't seem to 
focus on this value and is not impacted, kept the value so low i.e. 20?

#ifdef CONFIG_USB_EHCI
/*
 * The U-Boot EHCI driver can handle any transfer length as long as there is
 * enough free heap space left, but the SCSI READ(10) and WRITE(10) commands are
 * limited to 65535 blocks.
 */
#define USB_MAX_XFER_BLK        65535
#else
#define USB_MAX_XFER_BLK        20
#endif

Common code suggests it is used in same way as used in EHCI. Please comment.

Best Regards,
Rajesh Bhagat 

> > Bests,
> > Diego
> >
> 
> 
> --
> Best regards,
> Marek Vasut
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
  2016-05-20  5:07                                                           ` Rajesh Bhagat
@ 2016-05-20 11:52                                                             ` Marek Vasut
  0 siblings, 0 replies; 52+ messages in thread
From: Marek Vasut @ 2016-05-20 11:52 UTC (permalink / raw)
  To: u-boot

On 05/20/2016 07:07 AM, Rajesh Bhagat wrote:
> 
> 
>> -----Original Message-----
>> From: U-Boot [mailto:u-boot-bounces at lists.denx.de] On Behalf Of Marek Vasut
>> Sent: Tuesday, May 10, 2016 6:02 PM
>> To: Diego <diego.ml@zoho.com>
>> Cc: u-boot at lists.denx.de; Stefan Roese <sr@denx.de>
>> Subject: Re: [U-Boot] Issue with USB mass storage (thumb drives)
>>
>> On 05/10/2016 02:04 PM, Diego wrote:
>>> In data mercoled? 4 maggio 2016 23:36:46, Marek Vasut ha scritto:
>>>> On 05/04/2016 04:06 PM, Diego wrote:
>>>>> In data mercoled? 4 maggio 2016 13:45:57, Marek Vasut ha scritto:
>>>>>> On 05/04/2016 11:13 AM, Diego wrote:
>>>>>>> <snip>
>>>>>>> So I see three options:
>>>>>>> 1) 65535 default with quirk table
>>>>>>> 2) 32767 default without quirk table
>>>>>>> 3) 32767 default with quirk table
>>>>>>>
>>>>>>> Personally I think 3) would be the safest solution, but I think 2)
>>>>>>> would at least work for most thumb drives.
>>>>>>
>>>>>> 1) with the quirk table would be the way to go, modern(ish) drives
>>>>>> should work fine with 65535 .
>>>>>
>>>>> I personally can't see any improvement with more recent thumb
>>>>> drives, quite the opposite.
>>>>>
>>>>> <snip>
>>>>> Why are you saying modern(ish) drives should work?
>>>>
>>>> Hmmmmm :-(
>>>>
>>>>> For others following the thread, please post your experience,
>>>>> especially with more recent drives (remember to test with files >16MB).
>>>>
>>>> I don't think it's really worth doing a thread about which sticks
>>>> work and which don't. I would find it much more valuable to address
>>>> this issue properly. I wonder if it would make sense to, instead of
>>>> starting with a big value which might not work, start with a
>>>> small(er) value and increase it with each subsequent block transfer.
>>>> Quite similarly to what TCP does. Would you be willing to look into it ?
>>>>
>>>
>>> Hi Marek,
>>
>> Hi!
>>
>>> so your proposal is to ramp up transferred block size during transfer?
>>> What's the rationale behind the proposal? In other words, why do you
>>> think it will fix the problem?
>>
>> You will get one transfer failure somewhere in the middle and this will let you
>> determine the maximum transfer size for particular stick.
>>
>>> Regarding implementing your proposal, it might take me very long to
>>> find some time to dedicate to it, so if anybody else wants to step up
>>> before I look at it, just raise your hand.
>>
>> OK
>>
> 
> Hello Marek, 
> 
> I have a question regarding USB_MAX_XFER_BLK macro, Why XHCI code doesn't seem to 
> focus on this value and is not impacted, kept the value so low i.e. 20?
> 
> #ifdef CONFIG_USB_EHCI
> /*
>  * The U-Boot EHCI driver can handle any transfer length as long as there is
>  * enough free heap space left, but the SCSI READ(10) and WRITE(10) commands are
>  * limited to 65535 blocks.
>  */
> #define USB_MAX_XFER_BLK        65535
> #else
> #define USB_MAX_XFER_BLK        20
> #endif
> 
> Common code suggests it is used in same way as used in EHCI. Please comment.

The MAX_XFER_BLK = 20 was for OHCI/UHCI, so the code should likely be
patches to set it to higher value for XHCI. Feel free to test and send a
patch.

Thanks

Best regards,
Marek Vasut

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [U-Boot] Issue with USB mass storage (thumb drives)
@ 2016-10-14  9:01 Michael Kasprowicz
  0 siblings, 0 replies; 52+ messages in thread
From: Michael Kasprowicz @ 2016-10-14  9:01 UTC (permalink / raw)
  To: u-boot

Hi Uboot team,
Is this problem of EHCI timed out on TD - token=0x80008d80 already resolved
?

If yes can soneone please point me to the solution.
I am seeing this read timeout failure with 2 n 4 GB Usb drives.
Its a no go for our project, please help or advise.

Thanks,
Mike

^ permalink raw reply	[flat|nested] 52+ messages in thread

end of thread, other threads:[~2016-10-14  9:01 UTC | newest]

Thread overview: 52+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-02-02 10:35 [U-Boot] Issue with USB mass storage (thumb drives) Schrempf Frieder
2016-02-02 16:28 ` Fabio Estevam
2016-02-02 16:39   ` Marek Vasut
2016-02-03  7:40     ` Schrempf Frieder
2016-02-03  7:45       ` Hannes Schmelzer
2016-02-03  9:34         ` Marek Vasut
2016-02-03  9:40       ` Marek Vasut
2016-02-03  9:55         ` Fabio Estevam
2016-02-03 10:15           ` Schrempf Frieder
2016-02-03 11:12             ` Marek Vasut
2016-02-03 11:49               ` Schrempf Frieder
2016-02-03 16:40                 ` Marek Vasut
2016-02-03 19:16                   ` Sergei Temerkhanov
2016-02-04  8:21                     ` Schrempf Frieder
2016-02-04 11:28                       ` Marek Vasut
2016-02-08  8:41                         ` Hannes Schmelzer
2016-02-08 14:58                           ` Marek Vasut
2016-02-12 15:53                             ` Simon Glass
2016-02-12 16:04                               ` Hannes Schmelzer
2016-02-18 10:05                         ` Schrempf Frieder
2016-02-18 15:32                           ` Marek Vasut
2016-02-18 17:14                             ` Fabio Estevam
2016-02-22  7:03                               ` Schrempf Frieder
2016-02-22 17:51                                 ` Maxime Jayat
2016-02-22 17:59                                   ` Fabio Estevam
2016-02-23  6:38                                     ` Hannes Schmelzer
2016-02-24 17:43                                       ` Marek Vasut
2016-02-25  4:13                                         ` Simon Glass
2016-02-25 17:56                                           ` Marek Vasut
2016-02-26  1:56                                             ` Simon Glass
2016-04-14 13:20                           ` Diego
2016-04-15 10:53                             ` Marek Vasut
2016-04-15 12:13                               ` Diego
2016-04-18 23:54                                 ` Marek Vasut
2016-04-25  8:16                                   ` Stefan Roese
2016-04-27  2:14                                 ` Marek Vasut
2016-04-27  9:04                                   ` Diego
2016-04-27 16:13                                     ` Marek Vasut
2016-04-28 13:04                                       ` Diego
2016-04-28 22:49                                         ` Marek Vasut
2016-04-29  7:58                                           ` Diego
2016-05-03 21:01                                             ` Marek Vasut
2016-05-04  9:13                                               ` Diego
2016-05-04 11:45                                                 ` Marek Vasut
2016-05-04 14:06                                                   ` Diego
2016-05-04 21:36                                                     ` Marek Vasut
2016-05-10 12:04                                                       ` Diego
2016-05-10 12:32                                                         ` Marek Vasut
2016-05-20  5:07                                                           ` Rajesh Bhagat
2016-05-20 11:52                                                             ` Marek Vasut
2016-02-04  8:06                   ` Schrempf Frieder
2016-10-14  9:01 Michael Kasprowicz

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.