[coreboot] Bootblock CMOS default and the checksum algo

William McCall william.mccall at gmail.com
Sun Oct 7 18:58:28 CEST 2018


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 <lance.zhao at gmail.com> 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 <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



-- 
William McCall



More information about the coreboot mailing list