[coreboot] Rebuilding coreboot image generation

[Peter Stuge]

Julius Werner wrote:
> > When designing CBFS we definitely did have fixed locations in mind.
> 
> Sure, I'm definitely not trying to argue that... I'm just saying that
> I think this should change if we have a cleaner option. The old CBFS
> has done a good job for a long time, but it was designed for a very
> specific purpose (x86 ROMs, I believe even without IFDs?) and we are
> now trying to do many more things (ARM boards with different layout
> requirements, RO/RW split ROMs, individually updateable A/B copies of
> the same file sets) that it really doesn't support well.

ARM, flash sector alignment and individually updateable files is
already in CBFS.


> Let's face it, problems like "we need to control the order in which
> we add files because otherwise the fixed location placement breaks"
> are really ugly

They aren't caused by CBFS, but by cbfstool.


> > Can anyone see some concrete problems with Kevin's suggestion?
> 
> I actually think Kevin's suggestion was pretty much the same thing
> we're proposing anyway.

Fair enough. I would like this to first be implemented as he
suggested, then adding support to read all of them at once from a
file in cbfstool should be a very simple change, while cbfstool and
CBFS are still the main tools. I think it is very important to keep
existing tooling and existing data formats to stay compatibile and
not force people to learn more tooling than neccessary.


> it makes the layout very easy to read...

cbfstool print output is also very easy to read, and it's important
to me that this continues to be all that is neccessary to grok a
coreboot.rom file.


> The "little additional metadata" that Kevin said we needed *is* the
> FMAP. Think about it, how else would you store a list of regions with
> hardcoded bounds?

It seems like a very simple data structure (name, base, length) that
would be easy to store as a file within CBFS, so that a CBFS carries
its own metadata.


//Peter