[coreboot] [Patch] CMOS: Add set_option and rework get_option.

Luc Verhaegen 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
> available?
> 
> Luc Verhaegen.

I cannot help but feel that this is just trying to be different for the 
sake of trying to be different.

Luc Verhaegen.




More information about the coreboot mailing list