Hi,
Following up about Noé RFC, who I work with:
On Tue, 15 Nov 2011 21:43:47 +0100 Patrick Georgi patrick@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