#9453 BLOC Not Tri: Keyboard not present after boot

[Zarro Boogs per Child]

#9453: Keyboard not present after boot
-------------------------------------------+--------------------------------
           Reporter:  wad                  |       Owner:  rsmith       
               Type:  defect               |      Status:  new          
           Priority:  blocker              |   Milestone:  Not Triaged  
          Component:  embedded controller  |     Version:  not specified
         Resolution:                       |    Keywords:               
        Next_action:  never set            |    Verified:  0            
Deployment_affected:                       |   Blockedby:               
           Blocking:                       |  
-------------------------------------------+--------------------------------

Comment(by rsmith):

 Replying to [comment:4 wad]:
 > I've seen it on three different laptops, with an approximate frequency
 of one in twenty bots.  The one laptop that showed a much higher frequency
 turned out to have a faulty keyboard controller or wiring.

 Attempting to reproduce this on my A2's I spent a fair amount of time
 power cycling using the power button and watching the EC serial port.
 Unable to reproduce.

 I got sick of pressing the power button and added a ec-cmd66 command 0xd7
 that duplicates a power off/power on via the power button.  I didn't want
 to use 'reboot' because that does a EC watchdog reset and thus resets the
 EC every time.

 I then modified /boot/olpc.fth such so it delayed 500 ms and then issued
 the d7 command.  Ran that and logged the EC output.  On a machine with a
 new touchpad the EC will show "EnE KBC" when openfirmware tells the EC to
 switch keymapping.

 I let this run and then came back later. I then processed the log file.
 The EC outputs a "System Booted" message when its happy all the power
 rails are up and PCI reset is deasserted.  So I did a grep and a wc -l for
 the strings "System Booted" and then "EnE KBC" if the new keyboard was
 detected properly every time then these numbers should match.  After over
 400 cycles they matched perfectly.

 I then put a heavy object over the Enter key and continued to let the test
 run.  I let that test run till over 1000 cycles had happened and they
 still matched.

 While that was running I set up a 2nd test on my other A2 that has a ALPS
 controller in it.  There is no message output for an ALPS keyboard so
 instead I modified olpc.fth so that it looks for a 0x0d from the keyboard
 and if its not 0x0d then it aborts otherwise it issues the d7 powercyle
 command.  If there is not a key in the buffer then the the 'key' word will
 hang so if its not the correct key or if there is no key then the test
 would stop.

 This test ran for over an hour without fail.  I don't know how many cycles
 but way more than 20.

 Then I modified the keycheck test so that rather than a d7 reboot it did a
 'reboot' cmd which will cause the EC to reset.  This test also ran for
 many, many cycles without a problem.

 I'm giving up on trying to make this happen on my A2's.  Next I'll load
 the proper connectors on one of the B2's wad brought back and re-run the
 tests.

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