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

[Marek Vasut <marex@denx.de>]

On 02/25/2016 05:13 AM, Simon Glass wrote:
> Hi,
> 
> On 24 February 2016 at 10:43, Marek Vasut <marex@denx.de> wrote:
>>
>> On 02/23/2016 07:38 AM, Hannes Schmelzer wrote:
>>> On 22.02.2016 18:59, Fabio Estevam wrote:
>>>> On Mon, Feb 22, 2016 at 2:51 PM, Maxime Jayat <jayatmaxime@gmail.com>
>>>> wrote:
>>>>
>>>>> Hello,
>>>>> I was hit by the same problem, where my USB SD card reader would timeout
>>>>> in U-boot when reading a large file (16 MB). Changing USB_MAX_XFER_BLK
>>>>> to 32767 fixed the problem but I investigated a little more.
>>>>> I was curious to see what the Linux kernel used, because it had no
>>>>> problem reading the file. In Linux, USB_MAX_XFER_BLK corresponds to
>>>>> max_sector in the scsiglue, which is set to 240 blocks per transfer by
>>>>> default, and is tunable via sysfs.
>>>>> There is also a list of unusual devices which needs no higher than 64
>>>>> blocks per transfer.
>>>>> The linux USB FAQ has a very interesting entry about this which explains
>>>>> the rationale for this value:
>>>>>      http://www.linux-usb.org/FAQ.html#i5
>>>>>
>>>>> FWIW: my USB card reader is
>>>>> 0bda:0119 Realtek Semiconductor Corp. Storage Device (SD card reader)
>>>>>
>>>>> I've benchmarked in U-boot the time impact of this change.
>>>>> For reading my 16764395 bytes file:
>>>>> USB_MAX_XFER_BLK        Read duration (as reported by U-boot):
>>>>> 64                      3578 ms
>>>>> 128                     2221 ms
>>>>> 240                     1673 ms
>>>>> 32767                   1020 ms
>>>>> 65535                   974  ms
>>>>>
>>>>> So there is definitely a strong impact for lower values.
>>>> Ok, so with a USB_MAX_XFER_BLK size of 32767 there is not so much of a
>>>> performance impact.
>>>>
>>>> Looks like that changing USB_MAX_XFER_BLK from 65535 to 32767 is the
>>>> way to go.
>>> I have configured a value of 8191 some few weeks ago on my zynq board,
>>> there was no negative feedback until yesterday :-(
>>>
>>> A colleague of mine told me, that his USB-stick doesn't work. I had a look.
>>>
>>> Vendor: 0x1307  Product 0x0165 Version 1.0
>>> I had to reduce the USB_MAX_XFER_BLK downto 2048 to make it work.
>>>
>>> I'm not the big usb-expert ... but would it be possible to move away
>>> from this
>>> #define to some variable which is adapted to the lowest value on the bus.
>>> Is it possible at all to get to right value out of some register ?
>>
>> We will probably need a quirk table and for the crappy USB sticks, we
>> will just have to use lower maximum xfer size. I would suggest to add
>> an environment variable, which would allow to override the max xfer
>> size. This would help in case the user had a device, which does need
>> a quirk, but is not yet in a quirk table ; as a temporary work around of
>> course.
> 
> Yes.
> 
> Even better if we can print a message telling the user about this when
> we detect this error.

Agreed. Can you prepare such patch please ?