[coreboot] cmos.layout upgradability
Vladimir 'φ-coder/phcoder' Serbinenko
phcoder at gmail.com
Sun Jan 26 05:55:18 CET 2014
> (which mentions another solution to the problem)
Flashrom solution is interesting but it doesn't handle external
flashing. It would be a nice addition to checksums for internal flashing
Patrick's solution would have only one advantage compared to my
prototype: possibility of coreboot migrating the options rather than
But there is a problem with attempting this: when you request for option
the hashing would always give a number, even if that option doesn't
exist. And then we're back to reading garbage for new options.
>> 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.)
Ok. Let's hold 2a in reserve if 2 bytes is considered too expensive
> ...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.
There are number of problems with this:
1) Overclocking options. If you overclock too much, you don't boot
2) FILO uses options to control its behaviour. If by garbage tells to
boot from bad filename, it will probably stop unable to find the file.
3) vbnv field may be a problem.
Even if this goal is achieved we still need an upgrade way as new option
with garbage may make the system bootable but uncomfortable to most of
users, which is to avoid. E.g. disabling touchpad: I personally disable
touchpad (but through OS facilities, not coreboot) but many users would
get confused by disabled touchpad.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 274 bytes
Desc: OpenPGP digital signature
More information about the coreboot