> -----Original Message----- > From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Marek Vasut > Sent: Tuesday, May 10, 2016 6:02 PM > To: Diego <diego...@zoho.com> > Cc: u-boot@lists.denx.de; Stefan Roese <s...@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@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
