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. -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
