[coreboot] Bootblock CMOS default and the checksum algo

[William McCall]

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,

[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.

Post by William McCall
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
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.
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
--
https://mail.coreboot.org/mailman/listinfo/coreboot

[William McCall]

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?

Post by William McCall
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.

Post by William McCall
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
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.
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
--
https://mail.coreboot.org/mailman/listinfo/coreboot