[coreboot] [Patch] CMOS: Add set_option and rework get_option.
libv at skynet.be
Tue Jun 2 18:49:10 CEST 2009
On Tue, Jun 02, 2009 at 06:45:28PM +0200, Luc Verhaegen wrote:
> 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
> Luc Verhaegen.
I cannot help but feel that this is just trying to be different for the
sake of trying to be different.
More information about the coreboot