Stefan Reinauer wrote:
if Normal and Fallback were the same and both would write a decent set of CMOS defaults in the case of a bad checksum.
NAK if this means that testing coreboot and later booting factory BIOS again will throw an error and lose/change the NVRAM contents.
I don't understand your concern.
..
In my scenarios a machine is never running vendor bioses again after coreboot is able to boot (that's the whole purpose of coreboot)
And that's the good scenario that we all know and love. But remember that there are other scenarios up until that point.
I think it's really bad for coreboot to trample NVRAM contents since it hurts the impression of coreboot when someone is evaluating coreboot for the very first time.
That's always the case in one way or another, unless you disable CMOS settings in coreboot completely.
This is another way to express what I think is important; a way to disable NVRAM options that guarantees that coreboot will never write to NVRAM.
Are you saying that coreboot should not corrupt factory bios settings even if that is required to have settings in coreboot? It sounds if you need intelligence in that area, you're gonna get it with tools like nvramtool rather than generally cutting coreboot's feature set.
I'm after a more sophisticated feature set in coreboot, I don't want to cut it down in any way. I totally understand that coreboot in some areas makes convenient assumptions that hold for some scenarios but breaks in others, and it may not be entirely trivial to support those "new" scenarios.
//Peter