On Tue, Dec 08, 2009 at 11:01:43PM +0100, Rudolf Marek wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi all,
Is there someone who is actively using most of the CMOS options? For example I just know that Luc is using at least the VRAM size. I think he mentioned that on M2V-MX SE memory init options are too dangerous and board won't boot anymore if set wrong - maybe even after cmos clear?
I noticed that century byte is happily ignored - need to check if it really collides.
Question is what to do with that. Maybe it would be useful if someone could do some payload aka "setup" screen to change those options. Maybe it would make sense to get rid of most and have there only which are really used.
What do you think?
Rudolf
On m2v mx se, if you set Videoram, then the cmos checksum becomes valid, no matter what bullshit is in the rest of cmos. Then amd k8 init fails, because some of the options on the m2v mx se influence the k8 lethally..
Options which are there for development purposes are ok, but for a board as well implemented as the m2v-mx they should no longer be necessary. As stepan said: people copy paste cluelessly.
Last time i posted a patch, and then only after it was commited did it became clear that a "string" is reserved for the seabios/filo at least on the kontron board, making the patch invalid.
People spent time discussing a fantastic great future far far away, requiring a copy of flashrom to be available and everything, but no-one involved in that discussion bothered to review the patch properly, and the only Acker did so from the best of his knowledge (and the patch really was sane, just the requirements were wrong).
This bootloader option stuff needs to be done differently. Why not just reserve the top 64bytes or so for the bootloader?
Then, coreboot board info should be stored in a few bytes too, together with a version number carried in the cmos.options file, bumped as it changes. Option retrieval should check * checksum valid. * board valid. * version valid before it accepts any cmos options.
On top of that, cmos.options needs to have a way to specify defaults. We need defaults. If any of the above checks fail when running nvramtool, the tool should ask whether the defaults should be written in, if not, the checksum should not be validated (which should be able to be forcibly overwritten).
And nvram tool also needs to be able to work with the space reserved for the bootloader, so the common bootloaders better get reserved space structured too.
All of this is a lot of work, but all a lot more useful than doing even more work on a pipedream.
We have 892 bytes to our disposal in cmos. We can reserve 128 for board/cmos versioning, and reserve even 256 for the bootloader, and still have 512bytes left for coreboot options, which is tons when bits are used properly and when strings are not used.
CMOS is there, and it is easy to access and alter, all it needs is structure and properly implemented infrastructure.
Luc Verhaegen.