[coreboot] [RFC] CMOS options
peter at stuge.se
Wed Dec 9 09:02:00 CET 2009
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.
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.
However, when evaluation has finished and the board will be running
coreboot exclusively - never the factory BIOS again - I agree that it
is a good thing for coreboot to be a bit agressive with NVRAM
contents, since it helps reliability.
I don't think a single solution works for both evaluation and
production behaviors. Since the latter will be destructive I think
it should be explicitly chosen by user. Kconfig seems like the place.
coreboot-eval basically should not rely on NVRAM at all. That means
sane values for all settings must be stored somewhere else, and be
accessible. It also means slightly less functionality, but I think
that is quite acceptable as long as it does not alter the board.
> - 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
> 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.
Hm, the option name->number translation is done at build time now,
>> 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 :-)
Yes, I like both ideas.
> 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.
Maybe a preprocessing stage (cat?) with a bit of validation.
Rather than trying to go from completely static to completely generic
at once I think it might be better to split NVRAM into one part with
options that are common for all boards and defined in one single
place, and another part with board-local options defined per board.
That will still require careful selection of where to put an option,
but I think it would be very helpful to have such a divide since the
point is that in the minimal case a new board port does not need any
explicit options at all. (This is the big point.)
The few number of bytes make it annoying to create a generic solution
without sacrificing too much space, some kind of compromise will be
much easier to implement yet still bring most if not all of the
More information about the coreboot