[coreboot] [Patch] CMOS: Add set_option and rework get_option.

[Luc Verhaegen]

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.
> >   
> 
> Why?

Example:

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 
happy.

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 
continues booting.

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 
properly...

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 
  point.
* 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.

Luc Verhaegen.