Re: [coreboot] using overlayfs to have several coreboot dev envs

[Martin Roth]

I've been working on adding configs (miniconfigs) for abuild as well.
The plan is to have a coreboot/configs directory with all of the
configs there.  Two alternatives that were discussed were
coreboot/configs/VENDOR/MAINBOARD and just putting the configs in the
existing src/mainboards/VENDOR/MAINBOARD directories.  The reason
behind the current plan was that storing all of the miniconfigs in one
location would be the easiest way to maintain them.

If we do redo the build, I'd like it to be optional to put the builds
under the build/VENDOR/MAINBOARD directory instead of forcing that
directory structure as the only way to build.  Just a different target
should be fine.  I don't care much which one is the default, as long
as there's still an option to build in the current fashion.

make all = build/VENDOR/MAINBOARD/coreboot.rom
make single = build/coreboot.rom

Right now, for any board that's built, we know exactly where all of
the files will be without having to look up what mainboard was just
built. For example, if we put things under build/VENDOR/MAINBOARD,
it's going to make things difficult for my flash scripts.

Martin

On Sun, Nov 20, 2016 at 2:52 PM, ron minnich  wrote:
> yes, in linuxbios v2 we actually had a way to specify the creation of
> fallback and normal and build the merged coreboot.rom with one make command.
> This kind of fell by the wayside as the fallback/normal approach was mainly
> used by linux networx and Los Alamos.
>
> Good suggestion!
>
> On Sun, Nov 20, 2016 at 1:43 PM Charlotte Plusplus
>  wrote:
> > If you refactor that code, could you make it easier to add the fallback?
> > One of the main reason I use overlayfs is to keep a separate fallback
> >
> > Overlayfs may remain a good option when working on separate source trees,
> > but when the differences are just in the .config. it would be nice to
> > specify the .config-fallback, the .config-normal, run make and get a
> > coreboot.rom without having to manually give the file that needs to be
> > updated. I wrote scripts to do just that.
> >
> > On Sun, Nov 20, 2016 at 4:36 PM, ron minnich  wrote:
> > > On Sun, Nov 20, 2016 at 1:00 PM Matt DeVillier 
> > > wrote:
> > > > On Sun, Nov 20, 2016 at 2:51 PM, ron minnich  wrote:
> > > > > > I had the same thought even while writing that note. So option 2 for
> > > > > > the config file is to create it at the top level: config.${MAINBOARD) or
> > > > > > somewhere else. Would that work?
> > > >
> > > > using top level for config files would really clutter the root dir when
> > > > building for a large # of boards (I have ~25 I'm building for currently);
> > > > perhaps a 'configs' subdir would make sense?
> > >
> > > yes, and the configs would go well in a .gitignore ...