#9423 NORM 1.5-F11: Stabilize OFW USB handling on XO-1.5

Zarro Boogs per Child bugtracker at laptop.org
Thu Oct 29 20:44:48 EDT 2009


#9423: Stabilize OFW USB handling on XO-1.5
-------------------------------------------+--------------------------------
           Reporter:  wmb at firmworks.com    |       Owner:  wmb at firmworks.com
               Type:  defect               |      Status:  assigned         
           Priority:  normal               |   Milestone:  1.5-F11          
          Component:  ofw - open firmware  |     Version:  1.5-B2           
         Resolution:                       |    Keywords:                   
        Next_action:  test in release      |    Verified:  0                
Deployment_affected:                       |   Blockedby:                   
           Blocking:                       |  
-------------------------------------------+--------------------------------
Changes (by wmb at firmworks.com):

 * cc: wad at laptop.org (added)


Comment:

 More data on the Kingston USB stick problem, based on a lot of
 experiments.

 The information above about the "read transaction status" result having
 been written to memory is incorrect.  The data was left-over from a
 previous run.  The status transaction does appear on the USB bus, complete
 with ACK, but the host controller does not write either the data or the
 updated queue descriptor to memory.

 According to the ellisys USB explorer, in every case where the error
 occurs, one or more invalid or incomplete IN transactions precede the one
 that the host controller fails to register.

 In the good case, you have the read data transaction, then a series of
 several thousand IN..NAK transactions (essentially polling for the status
 from the stick), then finally an IN..ACK that returns the status.

 The bad case is similar, except that instead of an unbroken series of
 IN..NAK transactions, one or more IN..(incomplete) or IN..(invalid)
 transactions are inserted in the polling sequence.  When the IN..ACK
 occurs, the host controller apparently fails to accept it.

 I wonder if the USB2.0 PHY needs tuning for our board layout?

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


More information about the Bugs mailing list