[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