#4397 HIGH Update.: Firmware update without hard power-cycle

[Zarro Boogs per Child]

#4397: Firmware update without hard power-cycle
--------------------------------+-------------------------------------------
  Reporter:  wmb at firmworks.com  |       Owner:  dilinger
      Type:  defect             |      Status:  new     
  Priority:  high               |   Milestone:  Update.2
 Component:  kernel             |     Version:          
Resolution:                     |    Keywords:          
  Verified:  0                  |    Blocking:          
 Blockedby:                     |  
--------------------------------+-------------------------------------------

Comment(by wmb at firmworks.com):

 It is indeed a port 66 command.  Whether or not it "should" be on port
 6c/68 could be a topic for discussion; my take is that the "cleanliness"
 advantages of moving it are outweighed by the disadvantages of having to
 make synchronized changes to EC, OFW, and the kernel.  The port 66
 implementation of the command works well, requiring only a single write to
 that I/O port.

 It should be done on every reboot, because every time that OFW comes up,
 it should be given the opportunity to evaluate the security situation
 anew.  Otherwise you end up with the current situation, in which OFW
 sometimes has to force another reboot (OFW always uses db -> 66 to reboot)
 in order to perform requested SPI FLASH maintenance procedures.  This is
 not good from a user perspective, because the reboot loses the command
 line that the user typed.

 The other problem with the status quo is that there the system comes up in
 two different modes, depending on what happened before the reboot (i.e.
 who initiated the reboot).  This is a potential reliability issue.

 The normal-end-user use case for this is when the OS writes new firmware
 to the disk and reboots, expecting OFW to reflash itself.  OFW comes up
 and tries to do the reflash, but sees that it can't work because indexed
 I/O is off, so OFW has to force a second reboot.  This works, but seems
 dodgy to me.

 The current reboot process, which involves a triple fault, seems dodgy to
 me too, because the state sequence that the system goes through in this
 case is mysterious.  I prefer a reliable, definite, controlled sequence,
 which is what db -> 66 gives us.

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