[OLPC-devel] Requirements for a field BIOS reflashing tool.

[Stefan Reinauer]

* Jim Gettys <jg at laptop.org> [060616 17:02]:
> We are planning, as I believe has been mentioned on the mailing list, to
> have the embedded controller disable the flash write line unless and
> until the space bar has been held down for a 5 second period, to make it
> difficult for worms/viruses to "brick" the machines.

The 5 second period is a software thing in the flash writer, not a hardware 
issue, right?

I don't think writing should be allowed if I add two lines of spaces in
the word processor. 

Many modern motherboards secure their flash write lines using a GPIO 
that has to be set prior to writing, otherwise not even the flash rom
identification service will work. 

We've been cursing about this stuff in LinuxBIOS a couple of times, when
it was an undocumented feature ;-)

>    1) the flash utility would verify a checksum embedded at the end of
> the flash image, to make sure no bits had been damaged.

And so should the firmware itself. Assuming that a successful check during 
OS runtime will result in a successful check during firmware boot time
can be a wrong implication.

Running an unchecked firmware image is frivolous. Is there any chance we
can stuff a "fallback" and "normal" image in the development and/or
production chips with LinuxBIOS?  The fallback image should just be good
enough to flash the bios from an external device (floppy, cd, usb stick,
whatever the final version of the OLPC will allow) as we don't want two
Linux images in flash under any circumstances.

>    2) A additional adder was added, to bring the sum of the checksum and
> the adder up to a known (to the flash utility) magic number, so we know
> that it was for the intended model machine.

An "adder" as in a hardware Manchester carry chain? Usually such
checksums are CRC16 or CRC32 in safety critical systems.

>    3) the model of machine gets checked against the model(s) the
> firmware image will work on.

LinuxBIOS features a model number in flash, and the "flashrom" tool
which is part of LinuxBIOS checks this prior to flashing.

>    8) if there is a problem, try to reflash a time or two more.

If only to-be-cleared bits are wrongly set, just write it. If bits
are wrongly cleared, re-erase those parts and try again. Maybe: Check
if its erased after erasing it.

>   11) congratulate the user on their success.

the utility from LinuxBIOSv2/util/flashrom does a lot of this already. 


Stefan


-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info at coresystems.de  • http://www.coresystems.de/