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

[Simon Glass]

Hi Marek,

On 25 February 2016 at 10:56, Marek Vasut <marex at denx.de> wrote:
> On 02/25/2016 05:13 AM, Simon Glass wrote:
>> Hi,
>>
>> On 24 February 2016 at 10:43, Marek Vasut <marex at 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 at 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 ?
>

Let me put it in my queue and think about it...no promises.

Regards,
Simon