[OLPC-devel] Secure BIOS on the OLPC

Richard Smith smithbone at gmail.com
Fri Sep 1 14:11:01 EDT 2006


> > This might be an obvious question, but is there a reason we allow
> > software to reset the EC
> Not to worry, it's a non-obvious answer! ;-)  The reason that we must be
> able to reset the EC is to stop it from executing code while writing to
> the Flash chip.  Since the EC and the system BIOS share the SPI Flash,
> the EC would otherwise be continually performing code fetches from the
> same Flash that you're trying to write to.  That's why the system must
> be able to reset and control the EC chip.

Its my experience that when you "Un-reset" the KBC the entire system
reboots.  Somewone should probally watch the reset line to see if it
got asserted in that case.

I think what we really want here is not cold/warm reboots but rather
reset asserted vs non-reset asserted.

If you boot from a path that has had reset asserted then you are
basically assured that the resulting code path will be a known path
since it takes the reset vector.

So I would propose that you hook up the "hard" reset line to a one
shot timer and let the EC IO assert that timer.

Then the whole system restarts as if you had pressed the reset button.

-- 
Richard A. Smith



More information about the Devel mailing list