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 opinion.
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.
Patrick