#10632 NORM Not Tri: USB failure when updating SD using OFW

[Zarro Boogs per Child]

#10632: USB failure when updating SD using OFW
-------------------------------------------+--------------------------------
           Reporter:  wad                  |       Owner:  wmb at firmworks.com
               Type:  defect               |      Status:  new              
           Priority:  normal               |   Milestone:  Not Triaged      
          Component:  ofw - open firmware  |     Version:  1.75-A2          
         Resolution:                       |    Keywords:  XO-1.75          
        Next_action:  never set            |    Verified:  1                
Deployment_affected:                       |   Blockedby:                   
           Blocking:                       |  
-------------------------------------------+--------------------------------

Comment(by wad):

 On 1/11/11, Mitch discovered that:

 a) The USB errors are "Babble", i.e. the host controller detects data on
 the USB bus after the end of transaction. That is a fatal error according
 to the USB spec, requiring that the endpoint be halted.

 b) The error only happens if the length of an individual USB transfer
 exceeds 4K.  If I restrict transfers to 4K each, I can do long operations,
 including a complete
 fs-update, without error.  If the transfer length exceeds 4K by even one
 sector (4K + 512 bytes), I quickly see babble conditions.

 c) I tried it with the ellisys USB Explorer, which did not notice a babble
 condition on the external bus at the error point.  I'm not sure that's
 conclusive, but it suggests that the babble might be somehow related to
 conditions at the Hub/SOC.

 d) I don't know the max transfer length for Linux; Lennart speculates that
 it might be 4K, per the filesystem block size and page size, but that is
 not confirmed.  If Linux does indeed restrict to 4K, that would explain
 why Linux hasn't seen the problem.

 Here are two versions of a test script:

  ok text-off   \ Speed things up by turning off screen output

  ok select u:0 \ Open USB disk in raw mode

  ok 1000 0  do  (cr i . load-base  0  8  read-blocks 8 <> abort" x" loop

 That script re-reads the same 8 blocks (4K) starting at block 0. You can
 replace the 8 with larger numbers (2 places) to increase the read length.
 For me, it works at b (decimal 11) and failing at c (decimal 12) on one
 USB stick, while working at 8 and failing at 9 on a different stick

  ok text-off   \ Speed things up by turning off screen output

  ok select u:0 \ Open USB disk in raw mode

  ok 1000 0  do  (cr i . load-base  i 8 *  8  read-blocks 8 <> abort" x"
 loop

 The above script moves across the "disk" as it reads, instead of always
 reading the same blocks.  It works at 8 and fails at 9 on the first stick
 above.  Aha!  It fails at 8 on the second stick.  A third USB stick failed
 at a (decimal 10) blocks/transfer on the first test and failed at 9 on the
 second.

-- 
Ticket URL: <http://dev.laptop.org/ticket/10632#comment:1>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system