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 ?

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.

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

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

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.

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@lists.denx.de http://lists.denx.de/mailman/listinfo/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

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

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

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 Vasutmarex@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 Vasutmarex@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 ?

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.

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.

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.

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 ?

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

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-S... ID 0951:1689 Kingston Technology DataTraveler SE9

I'm available if you want any additional info.

Bests, Diego

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-S... 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

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-S...

...

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

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

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

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

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

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

-----Original Message----- From: U-Boot [mailto:u-boot-bounces@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@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@lists.denx.de http://lists.denx.de/mailman/listinfo/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.