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 <ma...@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 <ma...@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 ?
Best regards,
Marek Vasut
best regards,
Hannes
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
