The wiki is being retired!
Documentation is now handled by the same processes we use for code: Add something to the Documentation/ directory in the coreboot repo, and it will be rendered to https://doc.coreboot.org/. Contributions welcome!
abuild is a great tool to check whether your coreboot tree compiles for one or all targets.
It compiles the 'default' build for a mainboard. This is roughly equivalent to removing the .config file, running make menuconfig, selecting the manufacturer and mainboard, then saving the config without making any other changes.
Note that abuild is a tool to do a simple build test, and the default binary produced may well not boot if flashed to the system.
abuild needs to be run from the coreboot directory. If you cd into the coreboot/util/abuild directory and try to run it from there, it will not run correctly.
If you invoke abuild with no parameters, it will build all boards automatically. The resulting images and logs will end up in the coreboot-builds/ directory.
You can also specify a single board to build with the -t option:
For example, to build the Thomson IP1000 target, run:
$ util/abuild/abuild -t thomson/ip1000
The build log will be in coreboot-builds/thomson_ip1000/make.log.
You can also specify a payload directory with -p:
$ mkdir payloads $ cp /somewhere/filo.elf payloads
Then add a file payloads/payload.sh which prints the name of the payload to use (and takes the mainboard as a parameter) such as:
$ echo "`dirname $0`/build/filo.elf"
Then you can build a fully working image with payload by specifying:
$ util/abuild/abuild -t thomson/ip1000 -p ./payloads
Additionally, you can tell abuild not to use a payload with -p none
$ util/abuild/abuild -t thomson/ip1000 -p none
$ util/abuild/abuild --help coreboot autobuild v0.9 (January 29th, 2010) [...] Usage: util/abuild/abuild [-v] [-a] [-b] [-r] [-t <vendor/board>] [-p <dir>] [lbroot] util/abuild/abuild [-V|--version] util/abuild/abuild [-h|--help] Options: [-v|--verbose] print more messages [-a|--all] build previously succeeded ports as well [-b|--broken] attempt to build ports that are known broken [-r|--remove] remove output dir after build [-t|--target <vendor/board>] attempt to build target vendor/board only [-p|--payloads <dir>] use payloads in <dir> to build images [-V|--version] print version number and exit [-h|--help] print this help and exit [-x|--xml] write xml log file (defaults to abuild.xml) [-T|--test] submit image(s) to automated test system [-c|--cpus <numcpus>] build on <numcpus> at the same time [-s|--silent] omit compiler calls in logs [-ns|--nostackprotect] use gcc -fno-stack-protector option [-sb|--scan-build] use clang's static analyzer [-y|--ccache] use ccache [-C|--config] configure-only mode [-l|--loglevel <num>] set loglevel [-u|--update] update existing image [-P|--prefix <name>] file name prefix in CBFS [lbroot] absolute path to coreboot sources (defaults to .)
Many of the boards need files from the 'blobs' repository, which will be initialized by the -B option. If the blobs repo has already been initialized in your local tree, it won't hurt to add the -B
$ util/abuild/abuild -B -t aaeon/pfm-540i_revb -p none Building aaeon/pfm-540i_revb; Creating config file... (blobs) ok; Compiling image .. ok. (took 8s)
Adding ccache to your system and telling abuild to use it with the -y option will speed things up a bit:
$ util/abuild/abuild -B -y -t aaeon/pfm-540i_revb -p none Building aaeon/pfm-540i_revb; Creating config file... (blobs, ccache) ok; Compiling image .. ok. (took 4s)
Telling abuild to use multiple cores with the -c option helps speed things up as well:
$ util/abuild/abuild -B -y -c 8 -t aaeon/pfm-540i_revb -p none Building aaeon/pfm-540i_revb; Creating config file... (blobs, ccache) ok; Compiling image on 8 cpus in parallel .. ok. (took 3s)
Of course, the real power of abuild is in testing multiple boards
$ util/abuild/abuild -B -y -c 8 -p none