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?
2015-11-21 1:08 GMT+01:00 Julius Werner jwerner@chromium.org:
Let's extend your example so it becomes somewhat comparable to my proposal: [...] And that for every mainboard, and not transferable to other flash layout schemes. I don't think this is looking better (or even just as good) as my proposal, simple because of maintenance reasons.
Sorry, I'm not quite sure how to read that... did you literally mean that the cbfstool commands (or something equivalent) would be *in* the .fmd file? That is certainly not what I meant.
Instead, I was suggesting to use well-known CBFS "categories" and have another part of the system (e.g. the Makefiles) map files to those. For example when something (a mainboard, an SoC, etc.) declares a file, it would declare that this file belongs to the "pre-boot-split CBFS" category or the "post-boot-split CBFS" category (or for all I care you could also bind them directly to romstage/ramstage/etc. which is I think closer to what you were proposing). Then the part deciding the boot scheme ("vboot" and "traditional coreboot" for now) would know that all "pre-boot-split" files would belong into the well-known CBFS FMAP sections "FALLBACK" and "NORMAL" for traditional coreboot, whereas "post-boot-split" would only go into "NORMAL" (and the vboot version would instead know how to bind those categories to its RO/RW_A/RW_B sections). The .fmd file should *only* define the layout, and all the individual platform pieces that need to add files should *only* declare something abstract about in which context those files are used. Then something else (which is deciding the general boot method) should define how to bind those two together.