[coreboot] cmos.layout upgradability

[Peter Stuge]

Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> I feel like we should have a way to update options safely.

Thanks for starting the thread. I hope we'll hear comments on this
from all parts of the community.

It's a fairly important topic, since it impacts every single board.

Even if individual boards using coreboot in production typically do
not have new NVRAM settings added, there may be tree-wide options
added, and it's important that everything in the field continues to
work if a newer version of coreboot is deployed.

There is also previous work on the topic:

http://www.coreboot.org/Infrastructure_Projects#CMOS_handling

in particular:

http://www.coreboot.org/Infrastructure_Projects#Provide_update_paths_and_avoid_conflicts_in_addressing

(which mentions another solution to the problem)


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

This does seem like a reasonable approach, but...


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

(IIRC we already have problems with the Linux nvram driver which does
checksumming somehow differently. Or maybe that was fixed already.)


Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> > 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.

...but the above reminded me that it is ultimately a responsibility
of our source code and our design to never let booting fail simply
due to some garbage in NVRAM.

Code and design really must ensure a working state.

Until there exists an update path it's obviously not future proof to
add new options to any mainboard.


//Peter