Issue with USB mass storage (thumb drives)

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 **

Adding Marek in case he has any ideas.

On Tue, Feb 2, 2016 at 8:35 AM, Schrempf Frieder

Quoted 76 lines · <[email protected]> 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 **

Quoted 81 lines · Fabio Estevam

Adding Marek in case he has any ideas.

On Tue, Feb 2, 2016 at 8:35 AM, Schrempf Frieder

Quoted 76 lines · <[email protected]> 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 ?

Quoted 82 lines · Marek Vasut

Quoted 81 lines · Fabio Estevam

Adding Marek in case he has any ideas.

On Tue, Feb 2, 2016 at 8:35 AM, Schrempf Frieder

Quoted 76 lines · <[email protected]> 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 **

Quoted 1 line

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.

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

Quoted 89 lines · Schrempf Frieder

Quoted 84 lines · Marek Vasut

Quoted 82 lines · Fabio Estevam

Adding Marek in case he has any ideas.

On Tue, Feb 2, 2016 at 8:35 AM, Schrempf Frieder

Quoted 77 lines · <[email protected]> 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 **

Quoted 1 line

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.

Quoted 84 lines · Marek Vasut

Quoted 82 lines · Fabio Estevam

Adding Marek in case he has any ideas.

On Tue, Feb 2, 2016 at 8:35 AM, Schrempf Frieder

Quoted 77 lines · <[email protected]> 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 **

Quoted 1 line

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.

Quoted 4 lines · Marek Vasut

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.

Quoted 11 lines · Fabio Estevam

Quoted 4 lines · Marek Vasut

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

Quoted 13 lines · Schrempf Frieder

Quoted 10 lines · Fabio Estevam

Quoted 4 lines · Marek Vasut

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!

Quoted 8 lines

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 ?

Quoted 24 lines · Marek Vasut

Quoted 22 lines · Schrempf Frieder

Quoted 11 lines · Fabio Estevam

Quoted 4 lines · Marek Vasut

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

Quoted 8 lines

Quoted 1 line

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.

Quoted 6 lines · Schrempf Frieder

Quoted 5 lines · Marek Vasut

Quoted 4 lines · Schrempf Frieder

Quoted 3 lines · Fabio Estevam

Quoted 2 lines · Marek Vasut

In that case, debug time.

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 2 lines

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.

Quoted 25 lines

Quoted 11 lines

Quoted 10 lines

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

Quoted 8 lines

Quoted 1 line

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/

Quoted 4 lines

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

Quoted 9 lines · Marek Vasut

Quoted 8 lines · Schrempf Frieder

Quoted 7 lines · Marek Vasut

Quoted 6 lines · Schrempf Frieder

Quoted 5 lines · Fabio Estevam

Quoted 4 lines · Marek Vasut

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.

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

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

Quoted 11 lines · Sergei Temerkhanov

Quoted 10 lines · Marek Vasut

Quoted 9 lines · Schrempf Frieder

Quoted 8 lines · Marek Vasut

Quoted 7 lines · Schrempf Frieder

Quoted 6 lines · Fabio Estevam

Quoted 4 lines · Marek Vasut

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.

Quoted 8 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

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?

Quoted 20 lines · Schrempf Frieder

Quoted 10 lines · Sergei Temerkhanov

Quoted 9 lines · Marek Vasut

Quoted 8 lines · Schrempf Frieder

Quoted 7 lines · Marek Vasut

Quoted 6 lines · Schrempf Frieder

Quoted 5 lines · Fabio Estevam

Quoted 4 lines · Marek Vasut

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.

Quoted 7 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

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!

Quoted 7 lines

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

Quoted 27 lines · Marek Vasut

Quoted 26 lines · Schrempf Frieder

Quoted 11 lines · Sergei Temerkhanov

Quoted 10 lines · Marek Vasut

Quoted 9 lines · Schrempf Frieder

Quoted 8 lines · Marek Vasut

Quoted 7 lines · Schrempf Frieder

Quoted 6 lines · Fabio Estevam

Quoted 4 lines · Marek Vasut

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.

Quoted 8 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

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.

Quoted 7 lines

Quoted 4 lines

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 ?

Quoted 49 lines · Hannes Schmelzer

Quoted 27 lines · Marek Vasut

Quoted 26 lines · Schrempf Frieder

Quoted 11 lines · Sergei Temerkhanov

Quoted 10 lines · Marek Vasut

Quoted 9 lines · Schrempf Frieder

Quoted 8 lines · Marek Vasut

Quoted 7 lines · Schrempf Frieder

Quoted 6 lines · Fabio Estevam

Quoted 4 lines · Marek Vasut

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.

Quoted 8 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

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.

Quoted 7 lines

Quoted 4 lines

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.
*/

Quoted 2 lines

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.

Hi,

Quoted 45 lines · Marek Vasut

Quoted 44 lines · Hannes Schmelzer

Quoted 24 lines · Marek Vasut

Quoted 23 lines · Schrempf Frieder

Quoted 10 lines · Sergei Temerkhanov

Quoted 9 lines · Marek Vasut

Quoted 8 lines · Schrempf Frieder

Quoted 7 lines · Marek Vasut

Quoted 6 lines · Schrempf Frieder

Quoted 5 lines · Fabio Estevam

Quoted 4 lines · Marek Vasut

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.

Quoted 7 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

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.

Quoted 6 lines

Quoted 4 lines

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.
*/

Quoted 4 lines

Quoted 2 lines

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

Quoted 20 lines · Schrempf Frieder

Quoted 10 lines · Sergei Temerkhanov

Quoted 9 lines · Marek Vasut

Quoted 8 lines · Schrempf Frieder

Quoted 7 lines · Marek Vasut

Quoted 6 lines · Schrempf Frieder

Quoted 5 lines · Fabio Estevam

Quoted 4 lines · Marek Vasut

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.

Quoted 7 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

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!

Quoted 7 lines

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 ?

Quoted 21 lines · Marek Vasut

Quoted 20 lines · Schrempf Frieder

Quoted 10 lines · Sergei Temerkhanov

Quoted 9 lines · Marek Vasut

Quoted 8 lines · Schrempf Frieder

Quoted 7 lines · Marek Vasut

Quoted 6 lines · Schrempf Frieder

Quoted 5 lines · Fabio Estevam

Quoted 4 lines · Marek Vasut

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.

Quoted 7 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

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!

Quoted 8 lines

Quoted 7 lines

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

Quoted 10 lines

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 ?

Quoted 10 lines · Marek Vasut

Quoted 10 lines

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

Quoted 1 line

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?

Quoted 12 lines · Marek Vasut

Quoted 11 lines

Quoted 11 lines

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

Quoted 6 lines

Quoted 1 line

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.

Quoted 26 lines · Maxime Jayat

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

Quoted 1 line

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.

Quoted 29 lines · Fabio Estevam

Quoted 26 lines · Maxime Jayat

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

Quoted 6 lines

Quoted 1 line

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 ?

Quoted 41 lines · Hannes Schmelzer

Quoted 29 lines · Fabio Estevam

Quoted 26 lines · Maxime Jayat

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

Quoted 6 lines

Quoted 1 line

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.

Quoted 7 lines

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.

Hi,

Quoted 51 lines · Marek Vasut

Quoted 41 lines · Hannes Schmelzer

Quoted 29 lines · Fabio Estevam

Quoted 26 lines · Maxime Jayat

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

Quoted 6 lines

Quoted 1 line

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.

Quoted 7 lines

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 ?

Quoted 6 lines

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.

Quoted 4 lines · Simon Glass

Hi,

Quoted 1 line · Marek Vasut

Quoted 7 lines

Quoted 7 lines · Hannes Schmelzer

Quoted 6 lines · Fabio Estevam

Quoted 5 lines

Quoted 2 lines · Maxime Jayat

Hello,
I was hit by the same problem, where my USB SD card reader would

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

in U-boot when reading a large file (16 MB). Changing

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

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

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

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

Quoted 19 lines

Quoted 19 lines

Quoted 19 lines

Quoted 19 lines

Quoted 15 lines

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

Quoted 1 line

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.

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 2 lines

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

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

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

Quoted 9 lines

Quoted 8 lines

Quoted 1 line

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.

Quoted 4 lines

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 ?

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.

Quoted 4 lines · Schrempf Frieder

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

_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Quoted 11 lines · Schrempf Frieder

Quoted 4 lines

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.

Quoted 5 lines

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.

In data venerd? 15 aprile 2016 12:53:36, Marek Vasut ha scritto:

Quoted 12 lines · Diego

Quoted 11 lines · Schrempf Frieder

Quoted 4 lines

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.

Quoted 9 lines

Quoted 5 lines

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.

Quoted 33 lines · Diego

In data venerd? 15 aprile 2016 12:53:36, Marek Vasut ha scritto:

Quoted 12 lines · Diego

Quoted 11 lines · Schrempf Frieder

Quoted 4 lines

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.

Quoted 9 lines

Quoted 5 lines

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

Quoted 1 line

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.

In data venerd? 15 aprile 2016 12:53:36, Marek Vasut ha scritto:

Quoted 12 lines · Diego

Quoted 11 lines · Schrempf Frieder

Quoted 4 lines

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.

Quoted 9 lines

Quoted 5 lines

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

Quoted 4 lines

Hi Marek,

yes, I was getting the following error with the Kingston DTSE9 USB

2.0:

Quoted 5 lines

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

Quoted 3 lines

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?

Il 27 aprile 2016 04:14:45 CEST, Marek Vasut <[email protected]> ha scritto:

Quoted 21 lines · Diego

Quoted 4 lines

Hi Marek,

yes, I was getting the following error with the Kingston DTSE9 USB

2.0:

Quoted 5 lines

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

Quoted 3 lines

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.

Quoted 3 lines

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 ?

In data mercoled? 27 aprile 2016 18:13:51, Marek Vasut ha scritto:

Quoted 3 lines

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:

In data venerd? 29 aprile 2016 00:49:22, Marek Vasut ha scritto:

Quoted 4 lines

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

Quoted 6 lines

In data venerd? 29 aprile 2016 00:49:22, Marek Vasut ha scritto:

Quoted 3 lines

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,

Quoted 3 lines

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.

In data marted? 3 maggio 2016 23:01:10, Marek Vasut ha scritto:

Quoted 7 lines · Diego

Quoted 6 lines

In data venerd? 29 aprile 2016 00:49:22, Marek Vasut ha scritto:

Quoted 3 lines

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,

Quoted 9 lines

Quoted 3 lines

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

Quoted 28 lines

In data marted? 3 maggio 2016 23:01:10, Marek Vasut ha scritto:

Quoted 6 lines · Diego

Quoted 1 line

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

Quoted 3 lines

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 .

In data mercoled? 4 maggio 2016 13:45:57, Marek Vasut ha scritto:

Quoted 29 lines · Diego

Quoted 28 lines

In data marted? 3 maggio 2016 23:01:10, Marek Vasut ha scritto:

Quoted 6 lines · Diego

Quoted 1 line

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

Quoted 7 lines

Quoted 3 lines

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

Quoted 12 lines

In data mercoled? 4 maggio 2016 13:45:57, Marek Vasut ha scritto:

Quoted 11 lines · Diego

Quoted 9 lines

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

Quoted 8 lines

Quoted 2 lines

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 :-(

Quoted 2 lines

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 ?

In data mercoled? 4 maggio 2016 23:36:46, Marek Vasut ha scritto:

Quoted 27 lines · Diego

Quoted 12 lines

In data mercoled? 4 maggio 2016 13:45:57, Marek Vasut ha scritto:

Quoted 11 lines · Diego

Quoted 9 lines

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

Quoted 8 lines

Quoted 2 lines

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 :-(

Quoted 2 lines

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

Quoted 7 lines

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 at lists.denx.de] On Behalf Of Marek Vasut
Sent: Tuesday, May 10, 2016 6:02 PM
To: Diego <[email protected]>
Cc: u-boot at lists.denx.de; Stefan Roese <[email protected]>
Subject: Re: [U-Boot] Issue with USB mass storage (thumb drives)

Quoted 35 lines · Diego

In data mercoled? 4 maggio 2016 23:36:46, Marek Vasut ha scritto:

Quoted 26 lines · Diego

Quoted 11 lines

In data mercoled? 4 maggio 2016 13:45:57, Marek Vasut ha scritto:

Quoted 10 lines · Diego

Quoted 8 lines

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

Quoted 8 lines

Quoted 2 lines

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 :-(

Quoted 2 lines

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

Quoted 7 lines

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 ?

Quoted 1 line

Hi Marek,

Hi!

Quoted 3 lines

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.

Quoted 3 lines

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

Quoted 3 lines

Bests,
Diego

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

Quoted 53 lines

-----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 <[email protected]>
Cc: u-boot at lists.denx.de; Stefan Roese <[email protected]>
Subject: Re: [U-Boot] Issue with USB mass storage (thumb drives)

Quoted 35 lines · Diego

In data mercoled? 4 maggio 2016 23:36:46, Marek Vasut ha scritto:

Quoted 26 lines · Diego

Quoted 11 lines

In data mercoled? 4 maggio 2016 13:45:57, Marek Vasut ha scritto:

Quoted 10 lines · Diego

Quoted 8 lines

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

Quoted 8 lines

Quoted 2 lines

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 :-(

Quoted 2 lines

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

Quoted 7 lines

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 ?

Quoted 1 line

Hi Marek,

Hi!

Quoted 3 lines

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?

Quoted 9 lines

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

Quoted 3 lines

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.

Quoted 35 lines · Schrempf Frieder

Quoted 22 lines · Marek Vasut

Quoted 13 lines · Schrempf Frieder

Quoted 10 lines · Fabio Estevam

Quoted 4 lines · Marek Vasut

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!

Quoted 8 lines

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:

Quoted 7 lines

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/

Quoted 4 lines

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 .