[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