[coreboot] Rebuilding coreboot image generation
mr.nuke.me at gmail.com
Fri Nov 6 03:57:20 CET 2015
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
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?
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-75A8TWojjFiGK3r0yeIc7Vo/edit
> 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.
More information about the coreboot