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.