[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