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 this.
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, right?
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 benefit.
//Peter