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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot