[coreboot] [RFC] A more robust fallback system

[Guillaume Knispel]

Hi,

Following up about Noé RFC, who I work with:

On Tue, 15 Nov 2011 21:43:47 +0100
Patrick Georgi <patrick at georgi-clan.de> wrote:

> > system, by putting a 'fallback' Coreboot in the high, write-blocked part
> > of the boot ROM, and using the fallback mechanism already implemented in
> > Coreboot in order to fallback in case the user-flashed firmware does not
> > work.
> Why put the fallback in the high parts? The only reason I could find is 
> that you intend to use a boot block protection scheme (as these provide 
> protection only for some high region), but they usually cover only a 
> rather small area - too small for coreboot.

The upper area that we plan to store the safe code in would actually be
the upper half of the flash, which can be soft-locked RO. That is big
enough to contain a coreboot and even more.

> > found with the right name.  That's why the fallback mechanism has to
> > search for the fallback image only in the high part of the RAM.  That
> > requires modification of walkcbfs_asm and of cbfslib to be able to find
> > a file after an offset.
> > [...]
> > overwrite part of another file.  On the contrary, when looking for a
> > fallback component, the file headers before the fallback offset should
> > not be trusted (that's the whole point), so the beginning of the ROM
> > should be entirely skipped.
> These two special cases can be dropped if fallback is aligned to the low 
> end of the image: It's always encountered first, and the CBFS alignment 
> data is protected, too.

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)

> I'm snipping away your other proposals for now. The reason is that there 
> are various projects out there that use coreboot and have safe updates 
> on their agenda, and I'd rather have a complete set of constraints (eg. 
> limitations due to flash chips that only provide boot block protection) 
> before planning what to do about them.

On our side, the essential requirement is that the fallback can be put in
an upper area of the chip, because the lower area can't be locked
(The SST25VF016B can lock its upper 1/32, 1/16, 1/8, 1/4 or 1/2 -- we
 were thinking about locking the whole upper half, maybe to switch at
 a late stage of FW development to something just large enough to fit
 what we need.)

Our idea was that the owner should be allowed to write whatever CBFS
image he wants in the unlocked area of the chip, without the need to
first extract parameters from a protected header in his target board
before using the same to build his own image, and without any impact
on the behavior of the fallback image.

So I think it would be better to have two clearly separated areas,
maybe each one with its own header. If using only one header is
mandatory, then it clearly must be in the protected area, which might
not be possible to put at the bottom of the chip on some refs (like
the SST25VF016B we are using).

It definitely would be great to come with a general solution that works
for everybody and is maintained for a long time in a compatible way in
coreboot, because obviously we won't be able to change the structure
easily in the field once they have been bumped in protected areas of
deployed products, and we also would prefer not to maintain a patch
set specific to our board on this subject forever...
(we could put a jumper to disable the write protection, but because
 that could defeat the whole purpose of the protected fallback if
 misused, we are not yet sure, and we might end up with just an ISP
 header for those who really want to change the protected area).

Cheers!
Guillaume Knispel

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