[coreboot] Rebuilding coreboot image generation

[Patrick Georgi]

2015-11-21 5:08 GMT+01:00 Peter Stuge <peter at 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
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle