2015-11-09 21:47 GMT+01:00 Julius Werner jwerner@chromium.org:
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 must be linked to the location it was relocated to. That could even change over time. Just like x86s execute-in-place romstage.
Updates may end up at a different location, and they will likely have a different size. For all we know, updates may grow beyond the space we reserve for FSP in FMAP (which is read-only on Chromebooks). It would be unfortunate to have empty space, just in the wrong region, and run into problems doing an update because of that.
I don't think the layout constraints we can impose on files in CBFS are much of a problem, and there's not much overlap: As I understand things, FMAP exists for higher-order partitioning; for things that the current instance of coreboot need not to care about, like a separate copy of coreboot in flash, or chipset data that is none of the CPU firmware's business (ME and the like). FMAP is also suitable for writable fixed-size sections (like MRC cache) that we want to keep far away from the CBFS chain.
The other reason (besides file constraints) for this proposal is to enable the payload's build system to describe the files they need to add to CBFS themselves (and without knowing which FMAP regions the payload needs to end up in). depthcharge definitely needs something along those lines so we can get rid of that spaghetti code that is bundle_firmware.py. I think grub2 (and to some degree, seabios) could also benefit from dealing with their configuration files themselves in a structured way.
Patrick