[coreboot] Bootblock CMOS default and the checksum algo

[William McCall]

Hey all--

Recently, I started the process of enabling CMOS-based runtime config
on a board. As this board is native coreboot and it had never used the
CMOS in any meaningful sense, the CMOS was wholly zeroed out.

Based on this, the bootblock never programs the defaults. Why? Because
the checksum algorithm sums with a constant of 0 and simply sums the
bytes. This wasn't always the case, but was changed here:
http://review.coreboot.org/279

Downstream effects of this can be seen in nvramcui. As the CMOS is
zeroed, some enums (like debug_level) do not define a value at zero.
As a result, nvramcui ends up with a null pointer deref when trying to
set these enums.

Questions for the list:
1) Will CMOS reset typically result in zeroed out CMOS? Should we
assume that it probably does? Is this a common case?

2) To fix this, bootblock could look at options table checksum and use
a different constant or NOT the result. Is this reasonable to do in
bootblock? (My opinion is probably not)

3) As a workaround, an image could be used with
CONFIG_STATIC_OPTION_TABLE to force initial programming. Is a special
image acceptable if we assume question 1 is answered "yes"?

4) Should nvramcui be fixed to handle bogus enums?

5) What documentation of this behavior makes sense?

Also open to other solutions, thoughts, etc. Depending on the results
of this convo, I'll send patches/doc updates over that make sense.

TIA,
-- 
William McCall