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

[Marek Vasut]

On 05/10/2016 02:04 PM, Diego wrote:
> In data mercoledì 4 maggio 2016 23:36:46, Marek Vasut ha scritto:
>> On 05/04/2016 04:06 PM, Diego wrote:
>>> In data mercoledì 4 maggio 2016 13:45:57, Marek Vasut ha scritto:
>>>> On 05/04/2016 11:13 AM, Diego wrote:
>>>>> <snip>
>>>>> So I see three options:
>>>>> 1) 65535 default with quirk table
>>>>> 2) 32767 default without quirk table
>>>>> 3) 32767 default with quirk table
>>>>>
>>>>> Personally I think 3) would be the safest solution, but I think 2) would
>>>>> at
>>>>> least work for most thumb drives.
>>>>
>>>> 1) with the quirk table would be the way to go, modern(ish) drives
>>>> should work fine with 65535 .
>>>
>>> I personally can't see any improvement with more recent thumb drives,
>>> quite the opposite.
>>>
>>> <snip>
>>> Why are you saying modern(ish) drives should work?
>>
>> Hmmmmm :-(
>>
>>> For others following the thread, please post your experience, especially
>>> with more recent drives (remember to test with files >16MB).
>>
>> I don't think it's really worth doing a thread about which sticks work
>> and which don't. I would find it much more valuable to address this
>> issue properly. I wonder if it would make sense to, instead of starting
>> with a big value which might not work, start with a small(er) value and
>> increase it with each subsequent block transfer. Quite similarly to what
>> TCP does. Would you be willing to look into it ?
>>
> 
> Hi Marek,

Hi!

> so your proposal is to ramp up transferred block size during transfer?
> What's the rationale behind the proposal? In other words, why do you think it 
> will fix the problem?

You will get one transfer failure somewhere in the middle and this will
let you determine the maximum transfer size for particular stick.

> Regarding implementing your proposal, it might take me very long to find some 
> time to dedicate to it, so if anybody else wants to step up before I look at 
> it, just raise your hand.

OK

> Bests,
> Diego
> 


-- 
Best regards,
Marek Vasut