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
