#11021 HIGH Not Tri: EC turns on CPU with keyboard unresponsive

[Zarro Boogs per Child]

#11021: EC turns on CPU with keyboard unresponsive
-------------------------------------------+--------------------------------
           Reporter:  wmb at firmworks.com    |       Owner:  rsmith       
               Type:  defect               |      Status:  new          
           Priority:  high                 |   Milestone:  Not Triaged  
          Component:  embedded controller  |     Version:  not specified
         Resolution:                       |    Keywords:               
        Next_action:  diagnose             |    Verified:  0            
Deployment_affected:                       |   Blockedby:               
           Blocking:                       |  
-------------------------------------------+--------------------------------

Comment(by wmb at firmworks.com):

 I have what I think is a reliable OFW recipe for recovering from this bad
 state.  The following code, when added to the 8042 driver's open method,
 seems to work on an ENE 1.5 system:

 {{{
 : consume  ( -- )
    \ Discard any data that is already queued up
    begin  d# 10 ms  stat@  out-buf-full and  while
       data@ drop
    repeat
    d# 10 ms
 ;
 : reset-ps2  ( -- )
    consume

    \ Reset the mouse if the controller is expecting a mouse command
    stat@ h# 38 =  if  h# ff data!  consume   then

    \ Reset the mouse if the controller is reporting an aux port ready bit
    stat@ h# 30 =  if
       h# ff h# d4 put-ctlr-cmd2  consume
    then

    \ Reset the keyboard just for good measure
    h# ff data!  consume
 ;
 }}}

 It first reads and discards any data that is already queued up (the
 initial "consume").

 It then checks to see if the interface is expecting a command to the mouse
 (the "38" test); if so it sends the reset command and consumes any result
 bytes.

 It then checks to see if the interface is in "mouse state" (the "30"
 check); if so, it directs a reset command to the mouse and consumes any
 result bytes.

 Finally, it sends a reset command to the keyboard just to kick it.

 This sequence of operations was arrived at experimentally by booting many
 times, looking at possible error states, and finding successful recovery
 sequences.

 Ideally, it would be nice if the EC could put the interface into a
 consistent and workable state.  I don't know how hard that will be in the
 case where the mouse happens to be turned on at power-cycle time.  If it
 is too hard for the EC, we can consider putting the code in OFW.

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