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

[Hannes Schmelzer <hannes@schmelzer.or.at>]

On 2016-02-12 16:53, Simon Glass wrote:
> Hi,
>
> On 8 February 2016 at 07:58, Marek Vasut <marex@denx.de> wrote:
>> On Monday, February 08, 2016 at 09:41:09 AM, Hannes Schmelzer 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@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@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 ?
>>> Hi,
>>> that tip works also on my ZYNQ board.
>>>
>>> There is some comment around this 'magic-define':
>>>
>>> /*
>>>    * 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.
>>>    */
>>>
>>> Can i assume that 16MiB free heap space is enough if i want read a 16MiB
>>> file ?
>> The file is actually not read into a buffer on a heap iirc, but directly to
>> the target location if that's in RAM.
> Is it possible that the timeout is genuinely being exceeded? See
> USB_TIMEOUT_MS in ehci_submit_async(). It looks like 5 seconds to load
> 32MB, which should be plenty.
Hi Simon,
thanks for joining. I also have found this USB_TIMOUT in usb.h and 
increesed for
testing purpose this 5s to about 30s ... without wanted result.
It now takes instead 5s this 30s to bring up the timout warning, but 
still with the effect,
that file finally couldn't be read.
> Perhaps this timeout should be dependent on the data size?
Indeed, it depends on size ... but i'm not sure if this size parameter 
is 'wired' with some timeout parameter.
> I really can't understand why the problem is address-dependent. I'm
> assuming the cache is set up normally.
This is confusing me also.
> Regards,
> Simon
Hannes