On Sat, 27 Sep 2008 12:15:41 +0200, Stefan Reinauer stepan@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@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.