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 overlayfs is very practical. [...]
An alternative is to use the "external build" option if you're building for multiple targets with different .config files for each. It isn't quite as simple as the Linux kernel's kbuild O= syntax, but works fairly well.
I have three main builds that I'm alternating between (x230, chell and qemu) so I've created three directories and have a .config for each stored in a top-level config directory. From the coreboot directory I can modify the configs and build them independently:
make obj=./x230 DOTCONFIG=./config/x230 menuconfig make obj=./x230 DOTCONFIG=./config/x230 -j 8
The builds will share the same cross build tree, so the actual build output is only 64M per configuration.
Also note that any paths to external files like bzImage and initrd in each buld's .config are relative to the coreboot tree, not the output directory.
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 placed in a tree that followed the mainboard naming conventions.
We might want to think about getting back to multi-mainboard builds in one tree. Requiring people to use external build or overlayfs is kind of a burden.
It might be as simple as rewiring the build/ naming to something like build/vendor/mainboard
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.
Then it's as simple as saying something like MAINBOARD=vendor/mainboard make and letting the build system figure out the rest.
You could also export MAINBOARD=vendor/mainboard when you are doing lots of builds for one mainboard.
I personally would find this extremely useful. Having to bounce around between the various riscv boards has been inconvenient at best.
I'm willing to do the work if no one objects.
On Sun, Nov 20, 2016 at 10:43 AM Trammell Hudson hudson@trmm.net wrote:
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 overlayfs is very practical. [...]
An alternative is to use the "external build" option if you're building for multiple targets with different .config files for each. It isn't quite as simple as the Linux kernel's kbuild O= syntax, but works fairly well.
I have three main builds that I'm alternating between (x230, chell and qemu) so I've created three directories and have a .config for each stored in a top-level config directory. From the coreboot directory I can modify the configs and build them independently:
make obj=./x230 DOTCONFIG=./config/x230 menuconfig make obj=./x230 DOTCONFIG=./config/x230 -j 8
The builds will share the same cross build tree, so the actual build output is only 64M per configuration.
Also note that any paths to external files like bzImage and initrd in each buld's .config are relative to the coreboot tree, not the output directory.
-- Trammell
-- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot