From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Tue, 10 May 2016 14:32:29 +0200 Subject: [U-Boot] Issue with USB mass storage (thumb drives) In-Reply-To: <1538078.ET8cfR6BQf@ip-192-168-197-87.eu-west-1.compute.internal> References: <6271677.LhHn0SdMV3@ip-192-168-197-87.eu-west-1.compute.internal> <1562946.88OqF5sfEm@localhost.localdomain> <572A6B6E.6060401@denx.de> <1538078.ET8cfR6BQf@ip-192-168-197-87.eu-west-1.compute.internal> Message-ID: <5731D4DD.5070901@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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: >>>>> >>>>> 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. >>> >>> >>> 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 > Bests, > Diego > -- Best regards, Marek Vasut