[coreboot] [Patch] CMOS: Add set_option and rework get_option.
libv at skynet.be
Tue Jun 2 18:33:08 CEST 2009
On Fri, May 29, 2009 at 07:45:18PM +0200, Stefan Reinauer wrote:
> On 29.05.2009 16:14 Uhr, Luc Verhaegen wrote:
> > Currently, our security of the cmos value being correct with respect to
> > the options table, is the existence of the option name string in the
> > optionstable, and the validity of the checksum. We need more than this,
> > we need a better way of matching cmos data with the options table.
Run native bios on epia-m. It stops booting, loads the defaults and
tells you to go into the config. Alter the config, boot again, and it is
Then plug in a coreboot image. It flags that the checksum is invalid,
and therefor most of the users of cmos data use a default, yet it
Alter a single value with nvramtool, and suddenly the cmos checksum is
correct. No matter what the other values are. Sometimes you're lucky,
but in the epia-m case, you lose serial output (as it suddenly is the
lowest value, a value which screen wasn't used to) and seabios tries to
boot off the network. All one can do is clear the cmos and then boot
What can be done to fix this:
1) track board and version information.
2) add some way to define the default settings in the cmos.layout.
Then there are several situations possible.
* when a legacy bios was run and the rtc is full of garbage (for us), or
when a different board is used, or when the major is different. This
should be treated the same way as an invalid checksum. Booting refuses
to use it and feeds back defaults (which can also be overridden by
code depending on the return value of get_option). Nvramtool can catch
this nicely and can offer to fill in defaults, or at least refuse to
correct the checksum.
* when booting, and when a minor difference between cmos and option
table is detected, treat the retrieved information as in the previous
* when a minor difference between rom option table and cmos.layout is
detected, then nvramtool can offer to program the default value of
the difference, because it can find out the difference.
* when the cmos.layout is for a different board, or of a lower version,
then nvramtool should basically refuse to accept it.
Also when nvramtool detects invalid values, it can offer to program
defaults or at least refuse to validate the checksum. nvramtool should
be able to write anything though, through the use of some argument like
--force. It should also be able to just set up everything by default.
Before any of this is done, the table generation code should get fixed
to output more sensible things (why do we dump this to a list of chars
in a table?) with things like defines or enums for the values. And we
should be able to do checking at boottime as well.
I know that this all nontrivial to implement, and that therefor it'll
take some time for someone to implement it. But i believe it makes
sense, and it will definitely avoid a board booting up with invalid
settings, and at least go for defaults.
More information about the coreboot