2015-11-21 5:08 GMT+01:00 Peter Stuge peter@stuge.se:
And it's certainly possible to implement fixed placement.
The main drawback of CBFS, pretty much from the start, was that it creates a single chain of files, which makes it hard to implement certain designs safely:
You need to be extra careful when adding files that are supposed to be written to (eg memory training caches) to make sure that they start at a flash block, and keep CBFS data structures out completely.
You can't enforce through its structures that some files aren't "overwritten" by others by just reusing the file name, which is relevant even for the fallback/normal scenario: On an x86 system you have the bootblock at the top and the CBFS file chain moving bottom up, so to keep "fallback" safe, you need to ensure that any "normal" updates are written somewhere in the middle of the flash (and in a way that the CBFS file chain is never broken, despite flash block alignments).
With fmap, you simply have two (or more) separate chains that can span whatever region is practical.
We do not need to add *another* layer of complexity here, do we? We need to *eliminate* some of the complexity that has crept in.
fmap replaces the master header, which has its own issues, for example its very x86-centric design that led to different interpretation of its fields between coreboot, cbfstool and libpayload while adapting things for non-x86. The data structures are also reasonably simple: It's more or less a list of offset/size/name triplets (plus some flag bits that we mostly ignore). Any hierarchy we show in the fmap region descriptions merely exists because fmap allows overlaps.
Can anyone see some concrete problems with Kevin's suggestion?
It doesn't deal with the problem that each command has no visibility into what's going to be added after it.
Some of the constraints that we need to support (fixed placement, alignment, ...) can make the build break for a configuration that would work fine when reordering command invocation. That's an issue we ran into already. This is why I made the proposed flow work from a complete view of what needs to happen, and I tried to keep it out of the build system because people complained already that it's too complex.
Given the opposition on the build description side, I'll punt that and have make(1) deal with things (and ignore some duplication in metadata). Both can still be improved later (or turn out not to be an issue after all).
Patrick