[coreboot] [RFC] CMOS options

Luc Verhaegen libv at skynet.be
Wed Dec 9 09:23:33 CET 2009


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.





More information about the coreboot mailing list