From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Glass Date: Thu, 25 Feb 2016 18:56:43 -0700 Subject: [U-Boot] Issue with USB mass storage (thumb drives) In-Reply-To: <56CF4037.1070302@denx.de> References: <56B08683.9000607@exceet.de> <56B309F3.9000503@exceet.de> <201602041228.53313.marex@denx.de> <56C5974E.10600@exceet.de> <56C5E3F5.4040906@denx.de> <56CAB2C8.8040703@exceet.de> <56CB4ABD.2090900@gmail.com> <56CBFE6B.2040708@schmelzer.or.at> <56CDEBB9.6040507@denx.de> <56CF4037.1070302@denx.de> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Marek, On 25 February 2016 at 10:56, Marek Vasut wrote: > On 02/25/2016 05:13 AM, Simon Glass wrote: >> Hi, >> >> On 24 February 2016 at 10:43, Marek Vasut 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 >>>>> 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 ? > Let me put it in my queue and think about it...no promises. Regards, Simon