[coreboot] [RFC] CMOS options

Patrick Georgi patrick at georgi-clan.de
Tue Dec 8 23:11:02 CET 2009

Am 08.12.2009 23:01, schrieb Rudolf Marek:
> Is there someone who is actively using most of the CMOS options? For example I
> just know that Luc is using at least the VRAM size. I think he mentioned that on
> M2V-MX SE memory init options are too dangerous and board won't boot anymore if
> set wrong - maybe even after cmos clear?
What we definitely need is a recovery procedure.

Right now, on many boards coreboot looks if CMOS is valid (by using the 
checksum), and jumps to normal which uses CMOS or stays in fallback 
which uses hardcoded values. That fails if the validation routine fails 
(happened for me a couple of times), and isn't too nice to handle - 
basically two copies of the entire code just to switch between two sets 
of values (CMOS or hardcode).

It might be sufficient to keep a static array around with a valid preset 
of CMOS values (the cmos.layout format would have to be extended to 
store defaults for that), and just overwrite CMOS if it's found to be 
invalid - it's a bit harsh, but well, it's something that works (all 
PCBIOSes do it like that), and it works better than what we have, in my 

If we figure out a better way to handle it later (indirect access to 
CMOS via accessors that can be retargeted to accessing said static array 
or whatever), all the better. The hard part in this idea is that these 
accessor functions would need to be global variables of some sort.
> Question is what to do with that. Maybe it would be useful if someone could do
> some payload aka "setup" screen to change those options. Maybe it would make
> sense to get rid of most and have there only which are really used.
Basically, an nvramtool with frontend and as payload. Sounds good :-)

While we're talking about CMOS options, there was some talk about adding 
some include statement to cmos.layout, so components could add their 
flags and config variables. I don't think that there was some good 
proposal about how to do it. The issue is that variables should stay in 
their place, even if some component gains or loses some flags.


More information about the coreboot mailing list