[U-Boot] Issue with USB mass storage (thumb drives)

[Rajesh Bhagat]

> -----Original Message-----
> From: U-Boot [mailto:u-boot-bounces at lists.denx.de] On Behalf Of Marek Vasut
> Sent: Tuesday, May 10, 2016 6:02 PM
> To: Diego <diego.ml at zoho.com>
> Cc: u-boot at lists.denx.de; Stefan Roese <sr at 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.
> >>>>
> >>>> 1) 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.

Best Regards,
Rajesh Bhagat 

> > Bests,
> > Diego
> >
> 
> 
> --
> Best regards,
> Marek Vasut
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot