[coreboot] [RFC] CMOS options

Andrew Goodbody andrew.goodbody at tadpole.com
Wed Dec 9 12:48:03 CET 2009

Peter Stuge wrote:
> Patrick Georgi wrote:
>> 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
> I think this is too violent as a general solution.

As a general solution it is exactly what you want.

> When first testing coreboot on a board, it will trample all over the
> existing bytes in NVRAM. A more gentle approach there is definately
> on my wishlist.

In this specific case I can see a more gentle approach may be slightly 
more desirable. Using an emulated CMOS device rather than the real 
hardware could be an option if there is sufficient isolation in the 
interface. But on the whole I don't see a problem with overwriting CMOS.

>> - 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 opinion.
> I don't know if I've seen a BIOS which will overwrite NVRAM without
> user confirmation. I think it's a problem that coreboot always does
> this.

AFAIK all BIOSes will load defaults on detection of invalid checksums 
with no user confirmation. On Phoenix a CMOS checksum error is only a 
warning, you may not even notice it had happened.
By the time you see a prompt about entering Setup or continue, defaults 
were loaded long ago. The BIOS owns the machine, it has no interest in 
preserving corrupt CMOS contents.


More information about the coreboot mailing list