1) Will CMOS reset typically result in zeroed out CMOS? Should we assume that it probably does? Is this a common case?
I don't think so, RTC will kepp on counting. We may assume so if only use extended CMOS like 0x72/0x73.
On Sat, Oct 6, 2018 at 7:28 PM William McCall william.mccall@gmail.com wrote:
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:
- Will CMOS reset typically result in zeroed out CMOS? Should we
assume that it probably does? Is this a common case?
- 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)
- 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"?
Should nvramcui be fixed to handle bogus enums?
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
-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot