[U-Boot] Issue with USB mass storage (thumb drives)

Diego diego.ml at zoho.com
Thu Apr 14 15:20:09 CEST 2016


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




More information about the U-Boot mailing list