[coreboot] [RFC] A more robust fallback system

[Guillaume Knispel]

On Wed, 16 Nov 2011 21:50:59 +0100
Patrick Georgi <patrick at georgi-clan.de> wrote:

> Am 15.11.2011 23:42, schrieb Guillaume Knispel:
> > We can't put the fallback at the beginning of the image because that 
> > area can't be locked on the chip we are using. (SST25VF016B)
> Thanks! That was the missing part in your scenario. Most current chips 
> support sector granularity (usually 4kb, sometimes rather weird 
> combinations of different sizes).
>
> Current idea under consideration: Modify CBFS to work from top to 
> bottom. That way, you could place all immutable data at the beginning of 
> the chain (ie. top-most). That way all kind of headers, as well as 
> fallback-versions of code, can be in the protected area.
> If updates fail, some mechanism (counter in nvram, jumper, ...) can be 
> used to tell the bootblock to use the fallback version.

I think the most useful thing for the long term would be to come up with
data structures that allow use on all currently know chips, so in the
future every tool will be standard and there won't be a sort of
maintenance hell like "card X requires option Y during build of soft Z
then don't forget to use the following offsets and order when building
the cbfs image, and oh BTW here is a patch you should apply to your
toolchain first -- and remember to configure T exactly the same way or
they will be incompatible". It would also be more approachable for
users who want to modify their firmware if we avoid that mess.

> Of course, this is a rather severe change, but actually not that hard in 
> implementation: a couple of additions replaced by subtraction, and 
> different exit conditions. As it also affects payload compatibility 
> (libpayload and seabios at least), it requires some thought.

I think if we are going to modify payload compatibility, the right way
is to aim at a generic solution that would work well on all kind of
chips.

The advantage of having two clearly separated CBFS, one for the
protected area and one for the rest is that it would be clean (no hack,
no need to scan the whole chip, etc.), and would work with both chips
protected in the lower and chips protected in the upper area. Also I
think the CBFS structures would not need to be modified if there are
only contiguous areas. We maybe even could manage to keep backward
compatibility with older bootblocks (but they would not provide
the same level of protection) and tools?

Cheers,
Guillaume Knispel

-- 
Avencall - 10 bis, rue Lucien Voilin - 92800 Puteaux
Tel. : (+33) 141 389 960