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

[Marek Vasut]

On 05/20/2016 07:07 AM, Rajesh Bhagat wrote:
> 
> 
>> -----Original Message-----
>> From: U-Boot [mailto:u-boot-bounces at lists.denx.de] On Behalf Of Marek Vasut
>> Sent: Tuesday, May 10, 2016 6:02 PM
>> To: Diego <diego.ml at zoho.com>
>> Cc: u-boot at lists.denx.de; Stefan Roese <sr at denx.de>
>> Subject: Re: [U-Boot] Issue with USB mass storage (thumb drives)
>>
>> 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
>>
> 
> Hello Marek, 
> 
> I have a question regarding USB_MAX_XFER_BLK macro, Why XHCI code doesn't seem to 
> focus on this value and is not impacted, kept the value so low i.e. 20?
> 
> #ifdef CONFIG_USB_EHCI
> /*
>  * The U-Boot EHCI driver can handle any transfer length as long as there is
>  * enough free heap space left, but the SCSI READ(10) and WRITE(10) commands are
>  * limited to 65535 blocks.
>  */
> #define USB_MAX_XFER_BLK        65535
> #else
> #define USB_MAX_XFER_BLK        20
> #endif
> 
> Common code suggests it is used in same way as used in EHCI. Please comment.

The MAX_XFER_BLK = 20 was for OHCI/UHCI, so the code should likely be
patches to set it to higher value for XHCI. Feel free to test and send a
patch.

Thanks

Best regards,
Marek Vasut