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

[Simon Glass]

Hi,

On 8 February 2016 at 07:58, Marek Vasut <marex at 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 at 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 at 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.

Perhaps this timeout should be dependent on the data size?

I really can't understand why the problem is address-dependent. I'm
assuming the cache is set up normally.

Regards,
Simon