[coreboot] [Patch] CMOS: Add set_option and rework get_option.
Luc Verhaegen
libv at skynet.be
Tue Jun 2 18:45:28 CEST 2009
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.
More information about the coreboot
mailing list