On Sat, May 30, 2009 at 11:59:00AM -0400, Kevin O'Connor 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
You have, iirc, 228 bytes to your disposal.
Even if we would put all current cmos.layouts on byte boundaries, no-one would run out of space anyway.
How would you want to store information, and how would you want to handle parsing of this information? Do you really want to store configuration in xml and include an xml parser in a bios? Do you want to invent your own structured information storage system? If so, what is wrong with what we do now, especially, since we do not have to reprogram part of our flash every 5 seconds?
228 bytes is plenty if you are not storing whole strings.
- the coreboot layout conflicts with the vendor layout and it's a pain when switching between coreboot and factory bios
This is what the board-id-ing and versioning in both cmos and optiom table will solve.
- the batteries frequently get old and nvram storage becomes flaky
In such a case, too bad, get a new battery and program defaults.
CMOS is the best part of 256bytes that's available for everyone to use. It's there, it's free, we know how to access it, we know how to make very efficient use of it. We can write to it almost infinitely and very quickly. Sure, you cannot stuff many kBs in there, but how would you use such space anyway?
Why not make maximal use of infrastructure/hardware that is freely available?
Luc Verhaegen.