[coreboot] cmos.layout upgradability

Vladimir 'φ-coder/phcoder' Serbinenko phcoder at gmail.com
Sat Jan 25 04:15:10 CET 2014

On 25.01.2014 01:28, mrnuke wrote:
> On Saturday, January 25, 2014 12:51:25 AM Vladimir 'φ-coder/phcoder' 
> Serbinenko wrote:
>> Hello, all. Due to my failue to foresee this problem if one upgrades X60
>> coreboot, you need to manually reset CMOS config or your trackpad may
>> not work as option "trackpad_enable" will get a garbage value. While I
>> admit my part of fault, I feel like we should have a way to update
>> options safely. I see following possibilities:
>> 1) Hide ourselves and tell that on upgrade you always have to clear
>> CMOS. I don't think it's really an option as users will continue just
>> running flashrom and in case of external flashing, CMOS reset may
>> require full power removal with cell battery sometimes in difficult to
>> access places inside laptop.
>> 2) Have some version field to check and if it mismatches reset CMOS to
>> default. To avoid having to maintain version manually I propose to
>> checksum option table and write 16-bit result to CMOS. 16-bit should
>> give enough confidence without excessively using CMOS. I've made a
>> prototype at http://review.coreboot.org/#/c/4790/4 . If we can agree
>> that it's a right approach, I'll make this prototype into complete patch
>> (mostly missing is laborous adding of version field)
>> 2a) instead of having separate field we could make XOR layout checksum
>> into CMOS checksum. This would save 2 bytes but will break any existing
>> users if they check checksum.
> You mean it won't write the cmos.default after upgrade?
Not it won't. Checksum covers the same range and is at same position. So
checksum is still valid.
> And why would you need to reset CMOS if trackpad is disabled?
>  # nvramtool -a
>  # nvramtool -w trackpad_enable=Enable
You could do it in this particular case but user isn't required to know
this. And settings may be something more drammatic. It may happen that
the system doesn't boot with garbage settings at all. The fact that you
have to handle garbage in saved option indicates that something is wrong.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 274 bytes
Desc: OpenPGP digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20140125/e6283b16/attachment.sig>

More information about the coreboot mailing list