[coreboot] Rebuilding coreboot image generation

[Julius Werner]

> Again then this becomes an inconsistency on Chrome OS. FSP lives in
> RO, RW-A, and RW-B regions. RW-A and RW-B will be CBFS. So do make it
> it partly CBFS and partly FMAP such that the code is consistent to use
> FMAP APIs throughout? In my opinion that isn't appropriate. From a
> "change this little bit of code here" thing it's doable. But from
> looking at source code I standpoint such it's inconsistent. Sure FMAP
> would be used in certain places, but I'd argue those are in the
> infrastructure parts that many people porting things don't deal with.
> I don't want people to head scratch where something should live and
> then figure out 1. how to access it and 2. how to add it properly. The
> latter is still not plumbed in anywhere in the build system.

Okay, I guess we disagree on that one, then. In my opinion, the
biggest problem and inconsistency here is that we have a CBFS file
that needs to be placed at an exact offset (breaking the whole concept
of CBFS as a "file system" that can transparently manage its space
allocation). I think this is something that was done in the past for
lack of a better option, but that can and should be fixed when a
better tool (FMAP) is available. In my recollection/perspective, this
was the biggest reason we decided to combine CBFS and FMAP in the same
image in the first place (as opposed to porting all the Chrome OS /
vboot tools over to access CBFS and have the whole Chrome OS image be
a single (enhanced) CBFS)... because we acknowledged that FMAP's
strengths (global lookup table, rigid regions that can be exactly
aligned to custom offsets or erase blocks) are completely different
and complementary to CBFS's strengths (organizing many small files in
a compact, easy to manage format with automatic, opaque layout).

If Intel's architectural requirements force us to have a component
that must be linked at an exact spot in the image, I think it would
only be consistent to use the tool that we have which is meant for
these sorts of things... FMAP. It makes the intention (of placing it
*exactly there*) very explicit, and it frees up CBFS from weird
requirements that you wouldn't expect (e.g. the RO CBFS must encompass
that region, you need to pay attention to the order you add files in,
etc.). If that makes the code that handles it more complicated that's
unfortunate, and we should try to mitigate it where we can (maybe hide
differences with an extra FSP access API, or have all chipsets keep it
in its own FMAP section (maybe even in RW?) even though only some
really need that, or find a way / ask Intel to separate the
location-dependent part out into a separate blob)... but it still
seems like a smaller price to me than keeping the separation of duties
between FMAP and CBFS muddied and imposing all of those weird
restrictions on the latter for this one special case.

I should probably stop arguing this because I don't even know the
Intel code this is for... if you and all other x86 developers think
the FSP really must go in CBFS I'll shut up. It's also really only
tangentially related to the original discussion about the build system
architecture... but I brought it up because some of the benefits
Patrick's approach is trying to achieve (being able to better control
CBFS file ordering) should be irrelevant in my opinion, and only even
exist because of this problem.