ron minnich rminnich@lanl.gov writes:
I just found an issue with CMOS usage, and I am trying to figure out what tools use CMOS in which cases.
So, can we summarize:
- does etherboot do anything to bits in CMOS? If so, what?
There are a couple of variables that allow me to control the boot oder from LinuxBIOS. But those bits are all documented in the appropriate LinuxBIOS table. Etherboot just does a lookup and only uses them if present.
- what bits in CMOS is linuxbios V2 currently messing with? (yeah, I should know this, but it turns out I don't currently; I'm still looking for the place where linuxbios V2 writes to cmos nowadays)
Finally, is the CMOS really 256 bytes nowadays on something like the EPIA, or are we stuck at 128 still? I'm not sure at this point.
Using bits above 128 is interesting.
Any and all information would be nice to have. The problem I've hit is that I'm storing authentication data for Plan 9 in cmos, and it appears that linuxbios/etherboot are storing to bytes at location 0x1f or so, which is bad for me.
Roughly that sounds like the real time clock. Again check the cmos.layout from the LinuxBIOS build that should have a lot of good information.
I need to find 112 bytes that will be unmolested by either linuxbios or etherboot.
After you do it probably makes sense to reserve them in cmos.layout for whatever your purposes are so someone does not kill them.
Having to recompile your BIOS to get extra CMOS options is imperfect but it ensures the reservations get honored.
However I suggest you be very careful doing things that way. CMOS batteries die, and various other odd ball things happen. Long term we need a solution to store things in flash chips as well as just in the CMOS. I'd recommend jffs2 except I think it doesn't scale down quite small enough. But it certainly worth looking at.
Eric