My main concern with this is that we're introducing another language, with something that may just as well end up being cmos.layout 2.0.
I see where the manifest language is coming from. It's sort of like a FMAP dts, but then it really isn't. I understand that we don't want to use a per-board fmap.dts in order to prevent the duplication we ended up having last time we did this (cmos.layout).
From reading the manifest examples, these are the few things that jumped
out at as being unwanted: (1) mixing region descriptors with rules. As soon as we agree to move some rules to manifests and some to makefiles, we risk ending up with a mess that's inconsistent between platforms, and hard to track down/debug. (2) Undermining some of the existing infrastructure. We can extend the concept of cbfs-files-y, to fmap-regions-y, whereas the FMAP regions are dynamically declared. Of course, this is in stark contrast to the per-module descriptors (which I also like, assuming they are pure fmap.dts format). However, this inconsistency worries me. (3) It changes everything we've learnt so far about building a firmware image. Some platforms will end up using the new manifests, others will use the existing build infrastructure. I'm worried we'll end up with an inconsistent build system. Who is going to convert all the old hardware to manifests?
Now to the good parts. I mentioned briefly the possibility of a fmap-regions-y macro. Quite honestly, I much better like seeing the fmap.dts in one place in order to get an idea of the flash layout.
What I'd like to see come out of this is a dts-like set of flash descriptors, with the rules left in the makefiles. At the very least, dts is not a new language.
Do you think we can do that without making a mess out of it?
Alex
On 11/05/2015 03:42 AM, Patrick Georgi wrote:
Hey coreboot folks,
I'm looking for an approach to make building Chrome OS style coreboot images easier to do with regular coreboot tools, instead of the rather large post-processing pipeline we have in the Chrome OS build system.
The rationale is that we also push the Chrome OS capabilities (eg. verified boot) upstream, and actually using them shouldn't depend on checking out yet another custom build environment.
I wrote a proposal on how to do that, which can be found and commented at https://docs.google.com/document/d/1o2bFl5HCHDFPccQsOwa-75A8TWojjFiGK3r0yeIc...
If this is to be implemented, I'd do that as part of coreboot's build system, and work on supporting the regular image types (with a "simple" bootblock and a fallback/normal switch configuration) we currently have.
I appreciate comments and concerns how this fits in with other use cases.
Thanks, Patrick