[coreboot] Bootblock CMOS default and the checksum algo

[Lance Zhao]

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 at 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:
> 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
>
> --
> coreboot mailing list: coreboot at coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20181007/aac47070/attachment.html>