[Openec] fail-safe startup code?
Frieder Ferlemann
frieder.ferlemann at web.de
Mon Aug 6 16:19:59 EDT 2007
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.
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.
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
More information about the Openec
mailing list