my bad. option_table.h sets the checksum boundaries at LB_CKS_RANGE_START and LB_CKS_RANGE_END for the option table area.
so perhaps this discussion is a bit easier.. I think your comment indicates that we may assume the option table is zero'ed and we can have a case specific for the option table csum? On Sun, Oct 7, 2018 at 4:30 PM Lance Zhao <[email protected]> wrote: > > 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 <[email protected]> > 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: [email protected] >> https://mail.coreboot.org/mailman/listinfo/coreboot -- William McCall -- coreboot mailing list: [email protected] https://mail.coreboot.org/mailman/listinfo/coreboot
