On 02/25/2016 05:13 AM, Simon Glass wrote: > Hi, > > On 24 February 2016 at 10:43, Marek Vasut <ma...@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 <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 ? >> >> 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 ? _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
