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

[Marek Vasut]

On 02/18/2016 11:05 AM, Schrempf Frieder wrote:
> On 04.02.2016 12:28, Marek Vasut wrote:
>> On Thursday, February 04, 2016 at 09:21:08 AM, Schrempf Frieder wrote:
>>> On 03.02.2016 20:16, Sergei Temerkhanov wrote:
>>>> On Wed, Feb 3, 2016 at 8:40 AM, Marek Vasut<marex at denx.de>  wrote:
>>>>> On Wednesday, February 03, 2016 at 12:49:20 PM, Schrempf Frieder wrote:
>>>>>> On 03.02.2016 12:12, Marek Vasut wrote:
>>>>>>> On Wednesday, February 03, 2016 at 11:15:00 AM, Schrempf Frieder wrote:
>>>>>>>> On 03.02.2016 10:55, Fabio Estevam wrote:
>>>>>>>>> On Wed, Feb 3, 2016 at 7:40 AM, Marek Vasut<marex at denx.de>  wrote:
>>>>>>>>>> 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.
>>>> 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?
>> 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
> 
Maybe we need a quirk table then ?