On 22.02.2016 18:59, Fabio Estevam wrote:
On Mon, Feb 22, 2016 at 2:51 PM, Maxime Jayat <jayatmax...@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 ?
regards,
Hannes
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
