[coreboot] [PATCH] nvramtool: string support

[Joseph Smith]

On Sat, 27 Sep 2008 12:15:41 +0200, Stefan Reinauer <stepan at coresystems.de>
wrote:
> Joseph Smith wrote:
>>>> Add string support to nvramtool.
>>>>
>>>> To add a string to your cmos.layout, you need to specify type 's':
>>>>
>>>> #start     len       type    unused   name
>>>> 416        512       s       0        boot_devices
>>>>
>>>> With this patch you can do
>>>>
>>>> $ nvramtool -w boot_devices="(hd0,0);(hd2,1);(hd3)"
>>>>
>>>> And FILO will attempt to load a menu.lst from any of these devices in
>>>>       
>> that
>>   
>>>> order.
>>>>
>>>> The patch is not exactly pretty, but a cleaner solution might have
>>>>       
>> resulted in
>>   
>>>> a complete rewrite of the tool, which I did not want.
>>>>
>>>> Signed-off-by: Stefan Reinauer <stepan at coresystems.de>
>>>>       
>>> Cool I like it :-)
>>> But, it may just all change with FILO1.0...
>>>
>>>     
>> And what I mean by that is if Carl-Daniel can come through with his 1
> block
>> flashing idea (expected in Oct), there will be no need for FILO in CMOS.
>> FILO will have it's own data block for settings. Plenty of space for a
> FILO
>> configuration. I will ack this for the intrim though.
>>   
> Yes, we might consider additional storage for options in the future, if
> that's needed. Right now every machine has 256 bytes of CMOS nvram these
> days, of which 14 are reserved for the clock registers. Another byte is
> written by Linux, so we shouldn't use that either. This leaves us with
> 241 bytes of nvram. One of those bytes is actually used by coreboot. So
> the payload has 240 bytes left for its own use. For additional features
> (boot order support) FILO can use a given number of bytes (I gave it 64
> bytes on the board I'm working on). This means we could put 3.75 such
> payloads in a ROM, combined with bayou. I really don't think we're
> anywhere close to exhausting nvram storage. So no need to worry, all
> features of FILO 1.0 can be implemented without us worrying where the
> options are actually saved (and, from a payload perspective, we
> shouldn't care anyways)
> 
Well, if we are going to use CMOS for for FILO, I think we need to setup
Some CMOS guide lines. I think we need to setup a table on the wiki to show
which bytes are used for what, and what bytes are available. If no one
disagres I would be glad to do this. I still think Carl-Daniel's idea is
better though. Because you can take out your battery, throw it around the
room and put it back in and none of the settings will be lost. In my case
it would also work out because the RM4100, IP1000, and possibly other
Set-Top-Box platforms don't even have a CMOS battery so the defaults get
reset every startup.
 
-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org