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.mcc...@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@coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot >
-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
