On 05/20/2016 07:07 AM, Rajesh Bhagat wrote:
-----Original Message----- From: U-Boot [mailto:u-boot-bounces@lists.denx.de] On Behalf Of Marek Vasut Sent: Tuesday, May 10, 2016 6:02 PM To: Diego diego.ml@zoho.com Cc: u-boot@lists.denx.de; Stefan Roese sr@denx.de Subject: Re: [U-Boot] Issue with USB mass storage (thumb drives)
On 05/10/2016 02:04 PM, Diego wrote:
In data mercoledì 4 maggio 2016 23:36:46, Marek Vasut ha scritto:
On 05/04/2016 04:06 PM, Diego wrote:
In data mercoledì 4 maggio 2016 13:45:57, Marek Vasut ha scritto:
On 05/04/2016 11:13 AM, Diego wrote: > <snip> > So I see three options: > 1) 65535 default with quirk table > 2) 32767 default without quirk table > 3) 32767 default with quirk table > > Personally I think 3) would be the safest solution, but I think 2) > would at least work for most thumb drives.
- with the quirk table would be the way to go, modern(ish) drives
should work fine with 65535 .
I personally can't see any improvement with more recent thumb drives, quite the opposite.
<snip> Why are you saying modern(ish) drives should work?
Hmmmmm :-(
For others following the thread, please post your experience, especially with more recent drives (remember to test with files >16MB).
I don't think it's really worth doing a thread about which sticks work and which don't. I would find it much more valuable to address this issue properly. I wonder if it would make sense to, instead of starting with a big value which might not work, start with a small(er) value and increase it with each subsequent block transfer. Quite similarly to what TCP does. Would you be willing to look into it ?
Hi Marek,
Hi!
so your proposal is to ramp up transferred block size during transfer? What's the rationale behind the proposal? In other words, why do you think it will fix the problem?
You will get one transfer failure somewhere in the middle and this will let you determine the maximum transfer size for particular stick.
Regarding implementing your proposal, it might take me very long to find some time to dedicate to it, so if anybody else wants to step up before I look at it, just raise your hand.
OK
Hello Marek,
I have a question regarding USB_MAX_XFER_BLK macro, Why XHCI code doesn't seem to focus on this value and is not impacted, kept the value so low i.e. 20?
#ifdef CONFIG_USB_EHCI /*
- 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.
*/ #define USB_MAX_XFER_BLK 65535 #else #define USB_MAX_XFER_BLK 20 #endif
Common code suggests it is used in same way as used in EHCI. Please comment.
The MAX_XFER_BLK = 20 was for OHCI/UHCI, so the code should likely be patches to set it to higher value for XHCI. Feel free to test and send a patch.
Thanks
Best regards, Marek Vasut