On 04/14/2016 03:20 PM, Diego wrote:
On 18.02.2016, Schrempf Frieder wrote:
At the moment I have two sticks with the same chip around for which setting USB_MAX_XFER_BLK from 65535 to 32767 fixed the file transfer. Also one of our customers tested a few non-working sticks with this change and reported, that it fixed it for him.
Hi all,
sorry for reopening this thread, but I'd like to provide some additional infos.
I was experiencing the same problem with several USB thumb drives, especially with some Kingston DataTraveler.
Changing USB_MAX_XFER_BLK from 65535 to 32767 definitely fixed the "EHCI timed out on TD" but also fixed a more subtle problem.
So the DTSE9 is problematic even on EHCI ? Sigh ... I'll have to look into that one stick deeper, that's real bad.
Additionally, on a Kingston DataTraveler labelled "DTSE9 G2 USB 3.0": ID 0951:1666 Kingston Technology DataTraveler G4 I was experiencing apparently successful "load" transfers, but the data loaded was actually corrupted when loaded in memory, as a subsequent gzwrite reported broken CRC.
U-Boot > usb dev 0
USB device 0: Device 0: Vendor: Kingston Rev: PMAP Prod: DataTraveler 3.0 Type: Removable Hard Disk Capacity: 15004.3 MB = 14.6 GB (30728832 x 512) ... is now current device U-Boot > load usb 0:1 0x10008000 my-image.sdcard.gz reading my-image.sdcard.gz 112364153 bytes read in 3306 ms (32.4 MiB/s) U-Boot > gzwrite mmc 1 0x10008000 $filesize Error: inflate() returned -3
uncompressed 4194304 of 2218786816 crcs == 0xa85fe71c/0xd0244792The 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