[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
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
More information about the coreboot
mailing list