#12169 NORM Not Tri: XO-4 B1 SDHCI error on boot

[Zarro Boogs per Child]

#12169: XO-4 B1 SDHCI error on boot
------------------------------------+---------------------------------------
           Reporter:  rsmith        |       Owner:               
               Type:  defect        |      Status:  new          
           Priority:  normal        |   Milestone:  Not Triaged  
          Component:  not assigned  |     Version:  not specified
         Resolution:                |    Keywords:               
        Next_action:  never set     |    Verified:  0            
Deployment_affected:                |   Blockedby:               
           Blocking:                |  
------------------------------------+---------------------------------------

Comment(by rsmith):

 The following is e-mail/IRC between Richard and Mitch on trying to
 diagnose the failure on the unit at Twine

 =============
 I played with my B1 having the SDHCI problem a bit just now.  Its
 still showing the problem and I've discovered a few things.

 If I have my boot USB flash drive inserted then it errors every time.
 This is what I was using to boot cjb's kernel.
 If I do not have the flash drive in then it errors only sometimes.

 In both cases If I boot with the "check" key enabled then the problem
 does not occur.  At least not with enough frequency that I can see it
 in 10 or so tries.

 The same usb disk does not cause the error on 2 other B1 units I tried.
 =============

 One thing to try:  With the USB key installed, power on, then as soon as
 the screen turns while, press the rotate button.

 Then, on the serial port, type "resume"

 The intention here is to see if any delay fixes the problem.

 We have already seen that the "check" key fixes the problem.  One effect
 of the check key is the delay introduced by the "Release the game keys
 to continue" step.  I wonder if introducing delays at other points works
 similarly.
 ===================

 >
 > Then, on the serial port, type "resume"

 That does not fix it.

 > The intention here is to see if any delay fixes the problem.
 >
 > We have already seen that the "check" key fixes the problem.  One effect
 > of the check key is the delay introduced by the "Release the game keys
 > to continue" step.  I wonder if introducing delays at other points works
 > similarly.

 If I release the check key after the cforth numbers but before OFW can
 check for the key then the problem still happens
 =========

 Via IRC:
 [09 19:41:14] <MitchBradley> The thing I was going to suggest was   ok
 debug startup
 [09 19:41:29] <MitchBradley> or ok debug stand-init
 [09 19:42:00] <MitchBradley> and find out where it starts failing when you
 do 'g' from various points

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