[coreboot] Rebuilding coreboot image generation

Julius Werner jwerner at chromium.org
Tue Nov 24 06:37:05 CET 2015

On Fri, Nov 20, 2015 at 4:18 PM, Patrick Georgi <pgeorgi at google.com> wrote:
> So you think we're better off with one place to store the partition
> layout, a separate one to store what files belong where, and yet
> another one for the properties of those files, each with their own
> syntax and tooling?

Yes. I find it strange that you seem to imply this would make it more
complex or otherwise undesirable. Your proposal is to use a common
language, but spread the files that control all of this (including the
layout, which I think is the thing that really needs to be together in
one place to be readable) all over the place. I think we agree that
declarations of individual files should go in the different source
directories that relate to them, I just think that the layout should
stay centralized to be easily comprehensible and modifyable.

> 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. 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
and we should try to find a design that removes them completely.

> 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. It's just that he suggested adding regions one
at a time per cbfstool invocation, while the .fmd format is designed
to read the complete region layout from a file at image creation
(which I think is nicer because it makes the layout very easy to
read... if you did the thing with commands, you'd effectively still
end up having a list of those region-defining commands in some

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? This whole thing really started as an idea for a
"CBFS partition layout"
(http://www.coreboot.org/User_talk:MrNuke/CBFS_Ideas), until we
realized that the difference between any "partition table" format we
could come up with and an FMAP was so negligible that we might as well
keep the established format with pre-existing tooling (most
importantly flashrom support).

More information about the coreboot mailing list