From: Maxime Jayat <jayatmaxime@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] Issue with USB mass storage (thumb drives)
Date: Mon, 22 Feb 2016 18:51:57 +0100 [thread overview]
Message-ID: <56CB4ABD.2090900@gmail.com> (raw)
In-Reply-To: <56CAB2C8.8040703@exceet.de>
Le 22/02/2016 08:03, Schrempf Frieder a ?crit :
> On 18.02.2016 18:14, Fabio Estevam wrote:
>> On Thu, Feb 18, 2016 at 1:32 PM, Marek Vasut <marex@denx.de> wrote:
>>
>>>> Also one of our customers tested a few non-working sticks with this
>>>> change and reported, that it fixed it for him.
>>>> Here's a list of those devices, but I guess there are a lot more:
>>>>
>>>> 1. Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.) Flash
>>>> Drive, VID: 0x090c, PID: 0x1000
>>>> 2. Freecom Technologies, VID: 0x07ab, PID: 0xfcf1
>>>> 3. Newron, VID: 0x8644, PID: 0x800e
>>>> 4. GEMBIRD PhotoFrame PF-15-1, VID: 0x1908, PID: 0x1320
>>>>
>>> Maybe we need a quirk table then ?
>> It seems the list of affected devices is unknown.
>>
>> What would be the impact of changing USB_MAX_XFER_BLK from 65535 to 32767?
>>
>> Would this impact the USB transfer rate? Frieder, do you know?
> I don't really know. While testing I had the feeling, that the transfer
> is slightly slower, but I can't tell for sure.
>
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.
--
Maxime Jayat
next prev parent reply other threads:[~2016-02-22 17:51 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-02 10:35 [U-Boot] Issue with USB mass storage (thumb drives) Schrempf Frieder
2016-02-02 16:28 ` Fabio Estevam
2016-02-02 16:39 ` Marek Vasut
2016-02-03 7:40 ` Schrempf Frieder
2016-02-03 7:45 ` Hannes Schmelzer
2016-02-03 9:34 ` Marek Vasut
2016-02-03 9:40 ` Marek Vasut
2016-02-03 9:55 ` Fabio Estevam
2016-02-03 10:15 ` Schrempf Frieder
2016-02-03 11:12 ` Marek Vasut
2016-02-03 11:49 ` Schrempf Frieder
2016-02-03 16:40 ` Marek Vasut
2016-02-03 19:16 ` Sergei Temerkhanov
2016-02-04 8:21 ` Schrempf Frieder
2016-02-04 11:28 ` Marek Vasut
2016-02-08 8:41 ` Hannes Schmelzer
2016-02-08 14:58 ` Marek Vasut
2016-02-12 15:53 ` Simon Glass
2016-02-12 16:04 ` Hannes Schmelzer
2016-02-18 10:05 ` Schrempf Frieder
2016-02-18 15:32 ` Marek Vasut
2016-02-18 17:14 ` Fabio Estevam
2016-02-22 7:03 ` Schrempf Frieder
2016-02-22 17:51 ` Maxime Jayat [this message]
2016-02-22 17:59 ` Fabio Estevam
2016-02-23 6:38 ` Hannes Schmelzer
2016-02-24 17:43 ` Marek Vasut
2016-02-25 4:13 ` Simon Glass
2016-02-25 17:56 ` Marek Vasut
2016-02-26 1:56 ` Simon Glass
2016-04-14 13:20 ` Diego
2016-04-15 10:53 ` Marek Vasut
2016-04-15 12:13 ` Diego
2016-04-18 23:54 ` Marek Vasut
2016-04-25 8:16 ` Stefan Roese
2016-04-27 2:14 ` Marek Vasut
2016-04-27 9:04 ` Diego
2016-04-27 16:13 ` Marek Vasut
2016-04-28 13:04 ` Diego
2016-04-28 22:49 ` Marek Vasut
2016-04-29 7:58 ` Diego
2016-05-03 21:01 ` Marek Vasut
2016-05-04 9:13 ` Diego
2016-05-04 11:45 ` Marek Vasut
2016-05-04 14:06 ` Diego
2016-05-04 21:36 ` Marek Vasut
2016-05-10 12:04 ` Diego
2016-05-10 12:32 ` Marek Vasut
2016-05-20 5:07 ` Rajesh Bhagat
2016-05-20 11:52 ` Marek Vasut
2016-02-04 8:06 ` Schrempf Frieder
-- strict thread matches above, loose matches on Subject: below --
2016-10-14 9:01 Michael Kasprowicz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56CB4ABD.2090900@gmail.com \
--to=jayatmaxime@gmail.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.