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