On Sat, May 30, 2009 at 11:59 AM, Kevin O'Connor kevin@koconnor.net wrote:
On Fri, May 29, 2009 at 03:44:28PM +0200, Luc Verhaegen wrote:
To ease some of my debugging pain on the unichrome, i decided i needed to move FB size selection into cmos, so i could test a size and then reset it to the default after loading this value so that the next reboot uses the (working) default again. This meant implementing set_option in parallel to get_option.
As an aside, I think long-term coreboot should have a config file in flash and use that instead of nvram.
The issues with using nvram:
* it's small and it leads to weird hacks to store data
* the coreboot layout conflicts with the vendor layout and it's a pain when switching between coreboot and factory bios
* the batteries frequently get old and nvram storage becomes flaky
the big concern is having to rewrite a 64K flash page to change one bit. However! We could come up with a format for an erased "option page" in flash like this: struct option {u8 type; u32 len; char values[]};
Type would be 0xff to indicate unused, have some non-zero value to indicate a valid type, and 0 to indicate 'deleted' (much as we do on cbfs now). To eliminate/replace an option that is in the FLASH, set type to 0 (on many parts, we can do this without affecting other bytes) and then set the new option at the end of the current options.
Or should we just store options as files in cbfs? That seems simplest.
ron