[Openec] fail-safe startup code?

[Mitch Bradley]

Frieder Ferlemann wrote:
> Hi,
>
> Frieder Ferlemann schrieb:
>   
>> Richard A. Smith schrieb:
>>     
>>> Bad flashing in the field is a _big_ concern for us because it turns the 
>>> laptop into a brick and the service cost is more than the cost of the 
>>> laptop itself.
>>>
>>> I know you aren't  big on your work efforts going back into close source 
>>> trees but this is absolutely a feature that I would add into the current 
>>> code base.
>>>       
>> I hope to be able to come up with something early next week.
>> And as we all don't want bricked laptops it should allow for this:)
>>     
>
> Just committed:)
>
> http://dev.laptop.org/git.do?p=projects/openec;a=tree;f=failsafe;h=9c438a0683213b23f9227fa497ff1c1ed89408ae;hb=HEAD
>
> At its present stage it _will_ brick the XO.
>
> It generates a 16k binary image "notfailsafe.bin" which is intended
> to end up in 0x000000..0x003fff.
> "notfailsafe.bin" expects the payload to be located at
> 0x010000..0x01ffff.
> And it expects the payload to have an ajmp/ljmp 0x0000
> (0x0000 is the location of the reset vector)
> at its address 0x0200.
>
> The code in failsafe.c contains code to check if
> the bankswitching register XBISEG1 and the undocumented
> registers XBISEG2, XBISEG3 would work as expected.
>
> There are some things to do for "failsafe" to be
> functional. Functions like dcon_enable() are not
> implemented, the code does not blink, the memory
> map of the XO does not allow to use 0x010000..0x01ffff,
> and the code would have to be tested by someone
> who can debrick the XO again.
>
> Note that while the startup of the kb3700 itself
> could be made failsafe this might not be enough:
> If the linux image itself is corrupt then the XO
> still won't come back on its feet.
>   

OFW will have a way to restore a working NAND FLASH image from the 
school server.

> To achieve a more failsafe "failsafe.c" would have to be
> able to download an image (received via UART or
> maybe preferably by the one-wire from the battery)
> to the flash.
>   
I'm pretty sure we don't want a feature like that on production machines 
because it would compromise the security.  If you can replace the EC 
code from outside, you can defeat the SPI FLASH write protect, which is 
the key to overall security.

> If that would be done over the one-wire from the
> battery the recovery procedure would need no opening
> of the case.
> Instead of using the one-wire protocol over the DQ
> line we might consider implementing a halfduplex
> software UART (so the existing software as used for:
> http://wiki.laptop.org/go/SPI_FLASH_Recovery
> could still be used)
>
> (Putting Ivan and Mitch on CC)
>
> Greetings,
> Frieder
>