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

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

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

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,

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

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

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

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:

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

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

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

On Sun, Nov 20, 2016 at 12:45 PM Trammell Hudson wrote: > On Sun, Nov 20, 2016 at 08:20:51PM +, ron minnich wrote: > > [...] > > There's also no fundamental reason for using the name .config other than > > tradition. We could, for example, create > >

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

On Sun, Nov 20, 2016 at 08:20:51PM +, ron minnich wrote: > [...] > There's also no fundamental reason for using the name .config other than > tradition. We could, for example, create > build/vendor/mainboard/config and use that. One minor concern with that placement is that I enjoy the

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

I think the build system could stand some cleanup so that external build would not be needed and building many mainboards in one tree would be easy. LinuxBIOS V1 allowed you to build any number of mainboards in one source tree -- it was initially modeled on the BSD build system. objects were

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

On Sun, Nov 13, 2016 at 03:34:49PM -0500, Charlotte Plusplus wrote: > With the cross compiling tool chain, coreboot takes 1G. If you are a bit > short on space, or if you want to save writes to your SSD, instead of > having multiple copies of the coreboot source folder, I have found out >

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

A more portable solution to the "big toolchain" problem is to store the toolchain outside the coreboot tree. Something like $ util/crossgcc/buildgcc -D $HOME/.xgcc Then add $HOME/.xgcc/bin to your PATH. Regards, Patrick 2016-11-13 21:34 GMT+01:00 Charlotte Plusplus

[coreboot] using overlayfs to have several coreboot dev envs

Hello With the cross compiling tool chain, coreboot takes 1G. If you are a bit short on space, or if you want to save writes to your SSD, instead of having multiple copies of the coreboot source folder, I have found out overlayfs is very practical. If you have done git clone in