+# SPDX-License-Identifier: GPL-2.0+
# Copyright (c) 2013 The Chromium OS Authors.
-#
-# SPDX-License-Identifier: GPL-2.0+
-#
(Please read 'How to change from MAKEALL' if you are used to that tool)
+Quick-start
+===========
+
+If you just want to quickly set up buildman so you can build something (for
+example Raspberry Pi 2):
+
+ cd /path/to/u-boot
+ PATH=$PATH:`pwd`/tools/buildman
+ buildman --fetch-arch arm
+ buildman -k rpi_2
+ ls ../current/rpi_2
+ # u-boot.bin is the output image
+
+
What is this?
=============
Caveats
=======
-Buildman is still in its infancy. It is already a very useful tool, but
-expect to find problems and send patches.
-
Buildman can be stopped and restarted, in which case it will continue
where it left off. This should happen cleanly and without side-effects.
If not, it is a bug, for which a patch would be welcome.
Buildman gets so tied up in its work that it can ignore the outside world.
You may need to press Ctrl-C several times to quit it. Also it will print
-out various exceptions when stopped.
+out various exceptions when stopped. You may have to kill it since the
+Ctrl-C handling is somewhat broken.
Theory of Operation
Buildman is a builder. It is not make, although it runs make. It does not
produce any useful output on the terminal while building, except for
-progress information (except with -v, see below). All the output (errors,
-warnings and binaries if you ask for them) is stored in output
-directories, which you can look at while the build is progressing, or when
-it is finished.
+progress information (but see -v below). All the output (errors, warnings and
+binaries if you ask for them) is stored in output directories, which you can
+look at from a separate 'buildman -s' instance while the build is progressing,
+or when it is finished.
+
+Buildman is designed to build entire git branches, i.e. muliple commits. It
+can be run repeatedly on the same branch after making changes to commits on
+that branch. In this case it will automatically rebuild commits which have
+changed (and remove its old results for that commit). It is possible to build
+a branch for one board, then later build it for another board. This adds to
+the output, so now you have results for two boards. If you want buildman to
+re-build a commit it has already built (e.g. because of a toolchain update),
+use the -f flag.
Buildman produces a concise summary of which boards succeeded and failed.
It shows which commit introduced which board failure using a simple
-red/green colour coding. Full error information can be requested, in which
-case it is de-duped and displayed against the commit that introduced the
-error. An example workflow is below.
+red/green colour coding (with yellow/cyan for warnings). Full error
+information can be requested, in which case it is de-duped and displayed
+against the commit that introduced the error. An example workflow is below.
Buildman stores image size information and can report changes in image size
from commit to commit. An example of this is below.
Buildman starts multiple threads, and each thread builds for one board at
a time. A thread starts at the first commit, configures the source for your
board and builds it. Then it checks out the next commit and does an
-incremental build. Eventually the thread reaches the last commit and stops.
-If errors or warnings are found along the way, the thread will reconfigure
-after every commit, and your build will be very slow. This is because a
-file that produces just a warning would not normally be rebuilt in an
-incremental build.
+incremental build (i.e. not using 'make xxx_defconfig' unless you use -C).
+Eventually the thread reaches the last commit and stops. If a commit causes
+an error or warning, buildman will try it again after reconfiguring (but see
+-Q). Thus some commits may be built twice, with the first result silently
+discarded. Lots of errors and warnings will causes lots of reconfigures and your
+build will be very slow. This is because a file that produces just a warning
+would not normally be rebuilt in an incremental build. Once a thread finishes
+building all the commits for a board, it starts on the commits for another
+board.
Buildman works in an entirely separate place from your U-Boot repository.
It creates a separate working directory for each thread, and puts the
output files in the working directory, organised by commit name and board
-name, in a two-level hierarchy.
+name, in a two-level hierarchy (but see -P).
Buildman is invoked in your U-Boot directory, the one with the .git
directory. It clones this repository into a copy for each thread, and the
by the thread affect only the working directory for that thread.
Buildman automatically selects the correct tool chain for each board. You
-must supply suitable tool chains, but buildman takes care of selecting the
-right one.
+must supply suitable tool chains (see --fetch-arch), but buildman takes care
+of selecting the right one.
Buildman generally builds a branch (with the -b flag), and in this case
-builds the upstream commit as well, for comparison. It cannot build
-individual commits at present, unless (maybe) you point it at an empty
-branch. Put all your commits in a branch, set the branch's upstream to a
-valid value, and all will be well. Otherwise buildman will perform random
-actions. Use -n to check what the random actions might be.
+builds the upstream commit as well, for comparison. So even if you have one
+commit in your branch, two commits will be built. Put all your commits in a
+branch, set the branch's upstream to a valid value, and all will be well.
+Otherwise buildman will perform random actions. Use -n to check what the
+random actions might be.
-If you just want to build the current source tree, leave off the -b flag
-and add -e. This will display results and errors as they happen. You can
-still look at them later using -se. Note that buildman will assume that the
-source has changed, and will build all specified boards in this case.
+Buildman effectively has two modes: without -s it builds, with -s it
+summarises the results of previous (or active) builds.
+
+If you just want to build the current source tree, leave off the -b flag.
+This will display results and errors as they happen. You can still look at
+them later using -se. Note that buildman will assume that the source has
+changed, and will build all specified boards in this case.
Buildman is optimised for building many commits at once, for many boards.
On multi-core machines, Buildman is fast because it uses most of the
plan to use your machine for anything else, you can use -T to increase the
number of threads beyond the default.
+
+Selecting which boards to build
+===============================
+
Buildman lets you build all boards, or a subset. Specify the subset by passing
command-line arguments that list the desired board name, architecture name,
SOC name, or anything else in the boards.cfg file. Multiple arguments are
You can also use -x to specifically exclude some boards. For example:
- buildmand arm -x nvidia,freescale,.*ball$
+ buildman arm -x nvidia,freescale,.*ball$
means to build all arm boards except nvidia, freescale and anything ending
with 'ball'.
+For building specific boards you can use the --boards (or --bo) option, which
+takes a comma-separated list of board target names and be used multiple times
+on the command line:
+
+ buildman --boards sandbox,snow --boards
+
It is convenient to use the -n option to see what will be built based on
-the subset given.
+the subset given. Use -v as well to get an actual list of boards.
Buildman does not store intermediate object files. It optionally copies
-the binary output into a directory when a build is successful. Size
+the binary output into a directory when a build is successful (-k). Size
information is always recorded. It needs a fair bit of disk space to work,
typically 250MB per thread.
x86: i386
blackfin: bfin
nds32: nds32le
-openrisc: or32
+openrisc: or1k
This selects the available toolchain paths. Add the base directory for
The toolchain-alias section indicates that the i386 toolchain should be used
to build x86 commits.
+Note that you can also specific exactly toolchain prefixes if you like:
+
+[toolchain-prefix]
+arm: /opt/arm-eabi-4.6/bin/arm-eabi-
+
+or even:
+
+[toolchain-prefix]
+arm: /opt/arm-eabi-4.6/bin/arm-eabi-gcc
+
+This tells buildman that you want to use this exact toolchain for the arm
+architecture. This will override any toolchains found by searching using the
+[toolchain] settings.
+
+Since the toolchain prefix is an explicit request, buildman will report an
+error if a toolchain is not found with that prefix. The current PATH will be
+searched, so it is possible to use:
+
+[toolchain-prefix]
+arm: arm-none-eabi-
+
+and buildman will find arm-none-eabi-gcc in /usr/bin if you have it installed.
+
+[toolchain-wrapper]
+wrapper: ccache
+
+This tells buildman to use a compiler wrapper in front of CROSS_COMPILE. In
+this example, ccache. It doesn't affect the toolchain scan. The wrapper is
+added when CROSS_COMPILE environtal variable is set. The name in this
+section is ignored. If more than one line is provided, only the last one
+is taken.
3. Make sure you have the require Python pre-requisites
$ ./tools/buildman/buildman --list-tool-chains
Scanning for tool chains
+ - scanning prefix '/opt/gcc-4.6.3-nolibc/x86_64-linux/bin/x86_64-linux-'
+Tool chain test: OK, arch='x86', priority 1
+ - scanning prefix '/opt/arm-eabi-4.6/bin/arm-eabi-'
+Tool chain test: OK, arch='arm', priority 1
+ - scanning path '/toolchains/gcc-4.9.0-nolibc/i386-linux'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/i386-linux/.'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/i386-linux/bin'
+ - found '/toolchains/gcc-4.9.0-nolibc/i386-linux/bin/i386-linux-gcc'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/i386-linux/usr/bin'
+Tool chain test: OK, arch='i386', priority 4
+ - scanning path '/toolchains/gcc-4.9.0-nolibc/aarch64-linux'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/aarch64-linux/.'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/aarch64-linux/bin'
+ - found '/toolchains/gcc-4.9.0-nolibc/aarch64-linux/bin/aarch64-linux-gcc'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/aarch64-linux/usr/bin'
+Tool chain test: OK, arch='aarch64', priority 4
+ - scanning path '/toolchains/gcc-4.9.0-nolibc/microblaze-linux'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/microblaze-linux/.'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/microblaze-linux/bin'
+ - found '/toolchains/gcc-4.9.0-nolibc/microblaze-linux/bin/microblaze-linux-gcc'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/microblaze-linux/usr/bin'
+Tool chain test: OK, arch='microblaze', priority 4
+ - scanning path '/toolchains/gcc-4.9.0-nolibc/mips64-linux'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/mips64-linux/.'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/mips64-linux/bin'
+ - found '/toolchains/gcc-4.9.0-nolibc/mips64-linux/bin/mips64-linux-gcc'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/mips64-linux/usr/bin'
+Tool chain test: OK, arch='mips64', priority 4
+ - scanning path '/toolchains/gcc-4.9.0-nolibc/sparc64-linux'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/sparc64-linux/.'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/sparc64-linux/bin'
+ - found '/toolchains/gcc-4.9.0-nolibc/sparc64-linux/bin/sparc64-linux-gcc'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/sparc64-linux/usr/bin'
+Tool chain test: OK, arch='sparc64', priority 4
+ - scanning path '/toolchains/gcc-4.9.0-nolibc/arm-unknown-linux-gnueabi'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/arm-unknown-linux-gnueabi/.'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/arm-unknown-linux-gnueabi/bin'
+ - found '/toolchains/gcc-4.9.0-nolibc/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-gcc'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/arm-unknown-linux-gnueabi/usr/bin'
+Tool chain test: OK, arch='arm', priority 3
+Toolchain '/toolchains/gcc-4.9.0-nolibc/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-gcc' at priority 3 will be ignored because another toolchain for arch 'arm' has priority 1
+ - scanning path '/toolchains/gcc-4.9.0-nolibc/sparc-linux'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/sparc-linux/.'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/sparc-linux/bin'
+ - found '/toolchains/gcc-4.9.0-nolibc/sparc-linux/bin/sparc-linux-gcc'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/sparc-linux/usr/bin'
+Tool chain test: OK, arch='sparc', priority 4
+ - scanning path '/toolchains/gcc-4.9.0-nolibc/mips-linux'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/mips-linux/.'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/mips-linux/bin'
+ - found '/toolchains/gcc-4.9.0-nolibc/mips-linux/bin/mips-linux-gcc'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/mips-linux/usr/bin'
+Tool chain test: OK, arch='mips', priority 4
+ - scanning path '/toolchains/gcc-4.9.0-nolibc/x86_64-linux'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/x86_64-linux/.'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/x86_64-linux/bin'
+ - found '/toolchains/gcc-4.9.0-nolibc/x86_64-linux/bin/x86_64-linux-gcc'
+ - found '/toolchains/gcc-4.9.0-nolibc/x86_64-linux/bin/x86_64-linux-x86_64-linux-gcc'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/x86_64-linux/usr/bin'
+Tool chain test: OK, arch='x86_64', priority 4
+Tool chain test: OK, arch='x86_64', priority 4
+Toolchain '/toolchains/gcc-4.9.0-nolibc/x86_64-linux/bin/x86_64-linux-x86_64-linux-gcc' at priority 4 will be ignored because another toolchain for arch 'x86_64' has priority 4
+ - scanning path '/toolchains/gcc-4.9.0-nolibc/m68k-linux'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/m68k-linux/.'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/m68k-linux/bin'
+ - found '/toolchains/gcc-4.9.0-nolibc/m68k-linux/bin/m68k-linux-gcc'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/m68k-linux/usr/bin'
+Tool chain test: OK, arch='m68k', priority 4
+ - scanning path '/toolchains/gcc-4.9.0-nolibc/powerpc-linux'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/powerpc-linux/.'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/powerpc-linux/bin'
+ - found '/toolchains/gcc-4.9.0-nolibc/powerpc-linux/bin/powerpc-linux-gcc'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/powerpc-linux/usr/bin'
+Tool chain test: OK, arch='powerpc', priority 4
+ - scanning path '/toolchains/gcc-4.6.3-nolibc/bfin-uclinux'
+ - looking in '/toolchains/gcc-4.6.3-nolibc/bfin-uclinux/.'
+ - looking in '/toolchains/gcc-4.6.3-nolibc/bfin-uclinux/bin'
+ - found '/toolchains/gcc-4.6.3-nolibc/bfin-uclinux/bin/bfin-uclinux-gcc'
+ - looking in '/toolchains/gcc-4.6.3-nolibc/bfin-uclinux/usr/bin'
+Tool chain test: OK, arch='bfin', priority 6
+ - scanning path '/toolchains/gcc-4.6.3-nolibc/sparc-linux'
+ - looking in '/toolchains/gcc-4.6.3-nolibc/sparc-linux/.'
+ - looking in '/toolchains/gcc-4.6.3-nolibc/sparc-linux/bin'
+ - found '/toolchains/gcc-4.6.3-nolibc/sparc-linux/bin/sparc-linux-gcc'
+ - looking in '/toolchains/gcc-4.6.3-nolibc/sparc-linux/usr/bin'
+Tool chain test: OK, arch='sparc', priority 4
+Toolchain '/toolchains/gcc-4.6.3-nolibc/sparc-linux/bin/sparc-linux-gcc' at priority 4 will be ignored because another toolchain for arch 'sparc' has priority 4
+ - scanning path '/toolchains/gcc-4.6.3-nolibc/mips-linux'
+ - looking in '/toolchains/gcc-4.6.3-nolibc/mips-linux/.'
+ - looking in '/toolchains/gcc-4.6.3-nolibc/mips-linux/bin'
+ - found '/toolchains/gcc-4.6.3-nolibc/mips-linux/bin/mips-linux-gcc'
+ - looking in '/toolchains/gcc-4.6.3-nolibc/mips-linux/usr/bin'
+Tool chain test: OK, arch='mips', priority 4
+Toolchain '/toolchains/gcc-4.6.3-nolibc/mips-linux/bin/mips-linux-gcc' at priority 4 will be ignored because another toolchain for arch 'mips' has priority 4
+ - scanning path '/toolchains/gcc-4.6.3-nolibc/m68k-linux'
+ - looking in '/toolchains/gcc-4.6.3-nolibc/m68k-linux/.'
+ - looking in '/toolchains/gcc-4.6.3-nolibc/m68k-linux/bin'
+ - found '/toolchains/gcc-4.6.3-nolibc/m68k-linux/bin/m68k-linux-gcc'
+ - looking in '/toolchains/gcc-4.6.3-nolibc/m68k-linux/usr/bin'
+Tool chain test: OK, arch='m68k', priority 4
+Toolchain '/toolchains/gcc-4.6.3-nolibc/m68k-linux/bin/m68k-linux-gcc' at priority 4 will be ignored because another toolchain for arch 'm68k' has priority 4
+ - scanning path '/toolchains/gcc-4.6.3-nolibc/powerpc-linux'
+ - looking in '/toolchains/gcc-4.6.3-nolibc/powerpc-linux/.'
+ - looking in '/toolchains/gcc-4.6.3-nolibc/powerpc-linux/bin'
+ - found '/toolchains/gcc-4.6.3-nolibc/powerpc-linux/bin/powerpc-linux-gcc'
+ - looking in '/toolchains/gcc-4.6.3-nolibc/powerpc-linux/usr/bin'
+Tool chain test: OK, arch='powerpc', priority 4
+Tool chain test: OK, arch='or32', priority 4
- scanning path '/'
- looking in '/.'
- looking in '/bin'
- looking in '/usr/bin'
- - found '/usr/bin/gcc'
-Tool chain test: OK
+ - found '/usr/bin/i586-mingw32msvc-gcc'
- found '/usr/bin/c89-gcc'
-Tool chain test: OK
- - found '/usr/bin/c99-gcc'
-Tool chain test: OK
- found '/usr/bin/x86_64-linux-gnu-gcc'
-Tool chain test: OK
- - scanning path '/toolchains/powerpc-linux'
- - looking in '/toolchains/powerpc-linux/.'
- - looking in '/toolchains/powerpc-linux/bin'
- - found '/toolchains/powerpc-linux/bin/powerpc-linux-gcc'
-Tool chain test: OK
- - looking in '/toolchains/powerpc-linux/usr/bin'
- - scanning path '/toolchains/nds32le-linux-glibc-v1f'
- - looking in '/toolchains/nds32le-linux-glibc-v1f/.'
- - looking in '/toolchains/nds32le-linux-glibc-v1f/bin'
- - found '/toolchains/nds32le-linux-glibc-v1f/bin/nds32le-linux-gcc'
-Tool chain test: OK
- - looking in '/toolchains/nds32le-linux-glibc-v1f/usr/bin'
- - scanning path '/toolchains/nios2'
- - looking in '/toolchains/nios2/.'
- - looking in '/toolchains/nios2/bin'
- - found '/toolchains/nios2/bin/nios2-linux-gcc'
-Tool chain test: OK
- - found '/toolchains/nios2/bin/nios2-linux-uclibc-gcc'
-Tool chain test: OK
- - looking in '/toolchains/nios2/usr/bin'
- - found '/toolchains/nios2/usr/bin/nios2-linux-gcc'
-Tool chain test: OK
- - found '/toolchains/nios2/usr/bin/nios2-linux-uclibc-gcc'
-Tool chain test: OK
- - scanning path '/toolchains/microblaze-unknown-linux-gnu'
- - looking in '/toolchains/microblaze-unknown-linux-gnu/.'
- - looking in '/toolchains/microblaze-unknown-linux-gnu/bin'
- - found '/toolchains/microblaze-unknown-linux-gnu/bin/microblaze-unknown-linux-gnu-gcc'
-Tool chain test: OK
- - found '/toolchains/microblaze-unknown-linux-gnu/bin/mb-linux-gcc'
-Tool chain test: OK
- - looking in '/toolchains/microblaze-unknown-linux-gnu/usr/bin'
- - scanning path '/toolchains/mips-linux'
- - looking in '/toolchains/mips-linux/.'
- - looking in '/toolchains/mips-linux/bin'
- - found '/toolchains/mips-linux/bin/mips-linux-gcc'
-Tool chain test: OK
- - looking in '/toolchains/mips-linux/usr/bin'
- - scanning path '/toolchains/old'
- - looking in '/toolchains/old/.'
- - looking in '/toolchains/old/bin'
- - looking in '/toolchains/old/usr/bin'
- - scanning path '/toolchains/i386-linux'
- - looking in '/toolchains/i386-linux/.'
- - looking in '/toolchains/i386-linux/bin'
- - found '/toolchains/i386-linux/bin/i386-linux-gcc'
-Tool chain test: OK
- - looking in '/toolchains/i386-linux/usr/bin'
- - scanning path '/toolchains/bfin-uclinux'
- - looking in '/toolchains/bfin-uclinux/.'
- - looking in '/toolchains/bfin-uclinux/bin'
- - found '/toolchains/bfin-uclinux/bin/bfin-uclinux-gcc'
-Tool chain test: OK
- - looking in '/toolchains/bfin-uclinux/usr/bin'
- - scanning path '/toolchains/sparc-elf'
- - looking in '/toolchains/sparc-elf/.'
- - looking in '/toolchains/sparc-elf/bin'
- - found '/toolchains/sparc-elf/bin/sparc-elf-gcc'
-Tool chain test: OK
- - looking in '/toolchains/sparc-elf/usr/bin'
- - scanning path '/toolchains/arm-2010q1'
- - looking in '/toolchains/arm-2010q1/.'
- - looking in '/toolchains/arm-2010q1/bin'
- - found '/toolchains/arm-2010q1/bin/arm-none-linux-gnueabi-gcc'
-Tool chain test: OK
- - looking in '/toolchains/arm-2010q1/usr/bin'
- - scanning path '/toolchains/from'
- - looking in '/toolchains/from/.'
- - looking in '/toolchains/from/bin'
- - looking in '/toolchains/from/usr/bin'
- - scanning path '/toolchains/sh4-gentoo-linux-gnu'
- - looking in '/toolchains/sh4-gentoo-linux-gnu/.'
- - looking in '/toolchains/sh4-gentoo-linux-gnu/bin'
- - found '/toolchains/sh4-gentoo-linux-gnu/bin/sh4-gentoo-linux-gnu-gcc'
-Tool chain test: OK
- - looking in '/toolchains/sh4-gentoo-linux-gnu/usr/bin'
- - scanning path '/toolchains/avr32-linux'
- - looking in '/toolchains/avr32-linux/.'
- - looking in '/toolchains/avr32-linux/bin'
- - found '/toolchains/avr32-linux/bin/avr32-gcc'
-Tool chain test: OK
- - looking in '/toolchains/avr32-linux/usr/bin'
- - scanning path '/toolchains/m68k-linux'
- - looking in '/toolchains/m68k-linux/.'
- - looking in '/toolchains/m68k-linux/bin'
- - found '/toolchains/m68k-linux/bin/m68k-linux-gcc'
-Tool chain test: OK
- - looking in '/toolchains/m68k-linux/usr/bin'
-List of available toolchains (17):
-arm : /toolchains/arm-2010q1/bin/arm-none-linux-gnueabi-gcc
-avr32 : /toolchains/avr32-linux/bin/avr32-gcc
-bfin : /toolchains/bfin-uclinux/bin/bfin-uclinux-gcc
+ - found '/usr/bin/gcc'
+ - found '/usr/bin/c99-gcc'
+ - found '/usr/bin/arm-linux-gnueabi-gcc'
+ - found '/usr/bin/aarch64-linux-gnu-gcc'
+ - found '/usr/bin/winegcc'
+ - found '/usr/bin/arm-linux-gnueabihf-gcc'
+Tool chain test: OK, arch='i586', priority 11
+Tool chain test: OK, arch='c89', priority 11
+Tool chain test: OK, arch='x86_64', priority 4
+Toolchain '/usr/bin/x86_64-linux-gnu-gcc' at priority 4 will be ignored because another toolchain for arch 'x86_64' has priority 4
+Tool chain test: OK, arch='sandbox', priority 11
+Tool chain test: OK, arch='c99', priority 11
+Tool chain test: OK, arch='arm', priority 4
+Toolchain '/usr/bin/arm-linux-gnueabi-gcc' at priority 4 will be ignored because another toolchain for arch 'arm' has priority 1
+Tool chain test: OK, arch='aarch64', priority 4
+Toolchain '/usr/bin/aarch64-linux-gnu-gcc' at priority 4 will be ignored because another toolchain for arch 'aarch64' has priority 4
+Tool chain test: OK, arch='sandbox', priority 11
+Toolchain '/usr/bin/winegcc' at priority 11 will be ignored because another toolchain for arch 'sandbox' has priority 11
+Tool chain test: OK, arch='arm', priority 4
+Toolchain '/usr/bin/arm-linux-gnueabihf-gcc' at priority 4 will be ignored because another toolchain for arch 'arm' has priority 1
+List of available toolchains (34):
+aarch64 : /toolchains/gcc-4.9.0-nolibc/aarch64-linux/bin/aarch64-linux-gcc
+alpha : /toolchains/gcc-4.9.0-nolibc/alpha-linux/bin/alpha-linux-gcc
+am33_2.0 : /toolchains/gcc-4.9.0-nolibc/am33_2.0-linux/bin/am33_2.0-linux-gcc
+arm : /opt/arm-eabi-4.6/bin/arm-eabi-gcc
+bfin : /toolchains/gcc-4.6.3-nolibc/bfin-uclinux/bin/bfin-uclinux-gcc
c89 : /usr/bin/c89-gcc
c99 : /usr/bin/c99-gcc
-i386 : /toolchains/i386-linux/bin/i386-linux-gcc
-m68k : /toolchains/m68k-linux/bin/m68k-linux-gcc
-mb : /toolchains/microblaze-unknown-linux-gnu/bin/mb-linux-gcc
-microblaze: /toolchains/microblaze-unknown-linux-gnu/bin/microblaze-unknown-linux-gnu-gcc
-mips : /toolchains/mips-linux/bin/mips-linux-gcc
-nds32le : /toolchains/nds32le-linux-glibc-v1f/bin/nds32le-linux-gcc
-nios2 : /toolchains/nios2/bin/nios2-linux-gcc
-powerpc : /toolchains/powerpc-linux/bin/powerpc-linux-gcc
+frv : /toolchains/gcc-4.9.0-nolibc/frv-linux/bin/frv-linux-gcc
+h8300 : /toolchains/gcc-4.9.0-nolibc/h8300-elf/bin/h8300-elf-gcc
+hppa : /toolchains/gcc-4.9.0-nolibc/hppa-linux/bin/hppa-linux-gcc
+hppa64 : /toolchains/gcc-4.9.0-nolibc/hppa64-linux/bin/hppa64-linux-gcc
+i386 : /toolchains/gcc-4.9.0-nolibc/i386-linux/bin/i386-linux-gcc
+i586 : /usr/bin/i586-mingw32msvc-gcc
+ia64 : /toolchains/gcc-4.9.0-nolibc/ia64-linux/bin/ia64-linux-gcc
+m32r : /toolchains/gcc-4.9.0-nolibc/m32r-linux/bin/m32r-linux-gcc
+m68k : /toolchains/gcc-4.9.0-nolibc/m68k-linux/bin/m68k-linux-gcc
+microblaze: /toolchains/gcc-4.9.0-nolibc/microblaze-linux/bin/microblaze-linux-gcc
+mips : /toolchains/gcc-4.9.0-nolibc/mips-linux/bin/mips-linux-gcc
+mips64 : /toolchains/gcc-4.9.0-nolibc/mips64-linux/bin/mips64-linux-gcc
+or32 : /toolchains/gcc-4.5.1-nolibc/or32-linux/bin/or32-linux-gcc
+powerpc : /toolchains/gcc-4.9.0-nolibc/powerpc-linux/bin/powerpc-linux-gcc
+powerpc64 : /toolchains/gcc-4.9.0-nolibc/powerpc64-linux/bin/powerpc64-linux-gcc
+ppc64le : /toolchains/gcc-4.9.0-nolibc/ppc64le-linux/bin/ppc64le-linux-gcc
+s390x : /toolchains/gcc-4.9.0-nolibc/s390x-linux/bin/s390x-linux-gcc
sandbox : /usr/bin/gcc
-sh4 : /toolchains/sh4-gentoo-linux-gnu/bin/sh4-gentoo-linux-gnu-gcc
-sparc : /toolchains/sparc-elf/bin/sparc-elf-gcc
-x86_64 : /usr/bin/x86_64-linux-gnu-gcc
+sh4 : /toolchains/gcc-4.6.3-nolibc/sh4-linux/bin/sh4-linux-gcc
+sparc : /toolchains/gcc-4.9.0-nolibc/sparc-linux/bin/sparc-linux-gcc
+sparc64 : /toolchains/gcc-4.9.0-nolibc/sparc64-linux/bin/sparc64-linux-gcc
+tilegx : /toolchains/gcc-4.6.2-nolibc/tilegx-linux/bin/tilegx-linux-gcc
+x86 : /opt/gcc-4.6.3-nolibc/x86_64-linux/bin/x86_64-linux-gcc
+x86_64 : /toolchains/gcc-4.9.0-nolibc/x86_64-linux/bin/x86_64-linux-gcc
You can see that everything is covered, even some strange ones that won't
Checking: https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.2/
Checking: https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.5.1/
Checking: https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.2.4/
-Available architectures: alpha am33_2.0 arm avr32 bfin cris crisv32 frv h8300
+Available architectures: alpha am33_2.0 arm bfin cris crisv32 frv h8300
hppa hppa64 i386 ia64 m32r m68k mips mips64 or32 powerpc powerpc64 s390x sh4
sparc sparc64 tilegx x86_64 xtensa
Or download them all from kernel.org and move them to /toolchains directory,
-$ for i in aarch64 arm avr32 i386 m68k microblaze mips or32 powerpc sparc
- do
- ./tools/buildman/buildman --fetch-arch $i
- done
+$ ./tools/buildman/buildman --fetch-arch all
$ sudo mkdir -p /toolchains
$ sudo mv ~/.buildman-toolchains/*/* /toolchains/
For those not available from kernel.org, download from the following links.
arc: https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/
- arc_gnu_2015.06_prebuilt_uclibc_le_archs_linux_install.tar.gz
+ download/arc-2016.09-release/arc_gnu_2016.09_prebuilt_uclibc_le_archs_linux_install.tar.gz
blackfin: http://sourceforge.net/projects/adi-toolchain/files/
blackfin-toolchain-elf-gcc-4.5-2014R1_45-RC2.x86_64.tar.bz2
nds32: http://osdk.andestech.com/packages/
sh: http://sourcery.mentor.com/public/gnu_toolchain/sh-linux-gnu/
renesas-4.4-200-sh-linux-gnu-i686-pc-linux-gnu.tar.bz2
+Note openrisc kernel.org toolchain is out of date. Download the latest one from
+http://opencores.org/or1k/OpenRISC_GNU_tool_chain#Prebuilt_versions - eg:
+ftp://ocuser:ocuser@openrisc.opencores.org/toolchain/gcc-or1k-elf-4.8.1-x86.tar.bz2.
+
Buildman should now be set up to use your new toolchain.
At the time of writing, U-Boot has these architectures:
- arc, arm, avr32, blackfin, m68k, microblaze, mips, nds32, nios2, openrisc
+ arc, arm, blackfin, m68k, microblaze, mips, nds32, nios2, openrisc
powerpc, sandbox, sh, sparc, x86
Of these, only arc and nds32 are not available at kernel.org..
doing something like 'git branch --set-upstream-to upstream/master'
or something similar. Buildman will try to guess a suitable upstream branch
if it can't find one (you will see a message like" Guessing upstream as ...).
+You can also use the -c option to manually specify the number of commits to
+build.
As an example:
minute or so it will settle down to a steady pace, with a display like this:
Building 18 commits for 1059 boards (4 threads, 1 job per thread)
- 528 36 124 /19062 1:13:30 : SIMPC8313_SP
+ 528 36 124 /19062 -18374 1:13:30 : SIMPC8313_SP
This means that it is building 19062 board/commit combinations. So far it
has managed to successfully build 528. Another 36 have built with warnings,
-and 124 more didn't build at all. Buildman expects to complete the process
-in an hour and 15 minutes. Use this time to buy a faster computer.
+and 124 more didn't build at all. It has 18374 builds left to complete.
+Buildman expects to complete the process in around an hour and a quarter.
+Use this time to buy a faster computer.
To find out how the build went, ask for a summary with -s. You can do this
This shows which commits have succeeded and which have failed. In this case
the build is still in progress so many boards are not built yet (use -u to
-see which ones). But still we can see a few failures. The galaxy5200_LOWBOOT
+see which ones). But already we can see a few failures. The galaxy5200_LOWBOOT
never builds correctly. This could be a problem with our toolchain, or it
could be a bug in the upstream. The good news is that we probably don't need
-to blame our commits. The bad news is it isn't tested on that board.
+to blame our commits. The bad news is that our commits are not tested on that
+board.
-Commit 12 broke lubbock. That's what the '+ lubbock' means. The failure
-is never fixed by a later commit, or you would see lubbock again, in green,
-without the +.
+Commit 12 broke lubbock. That's what the '+ lubbock', in red, means. The
+failure is never fixed by a later commit, or you would see lubbock again, in
+green, without the +.
To see the actual error:
-$ ./tools/buildman/buildman -b <branch> -se lubbock
+$ ./tools/buildman/buildman -b <branch> -se
...
12: lcd: Add support for flushing LCD fb from dcache after update
arm: + lubbock
+common/libcommon.o: In function `lcd_sync':
-+/u-boot/lcd9b/.bm-work/00/common/lcd.c:120: undefined reference to `flush_dcache_range'
++common/lcd.c:120: undefined reference to `flush_dcache_range'
+arm-none-linux-gnueabi-ld: BFD (Sourcery G++ Lite 2010q1-202) 2.19.51.20090709 assertion fail /scratch/julian/2010q1-release-linux-lite/obj/binutils-src-2010q1-202-arm-none-linux-gnueabi-i686-pc-linux-gnu/bfd/elf32-arm.c:12572
-+make: *** [/u-boot/lcd9b/.bm-work/00/build/u-boot] Error 139
++make: *** [build/u-boot] Error 139
13: tegra: Align LCD frame buffer to section boundary
14: tegra: Support control of cache settings for LCD
15: tegra: fdt: Add LCD definitions for Seaboard
16: lcd: Add CONFIG_CONSOLE_SCROLL_LINES option to speed console
--/u-boot/lcd9b/.bm-work/00/common/lcd.c:120: undefined reference to `flush_dcache_range'
-+/u-boot/lcd9b/.bm-work/00/common/lcd.c:125: undefined reference to `flush_dcache_range'
+-common/lcd.c:120: undefined reference to `flush_dcache_range'
++common/lcd.c:125: undefined reference to `flush_dcache_range'
17: tegra: Enable display/lcd support on Seaboard
18: wip
should be enough to work out what that commit is doing to break these
boards. (In this case pxa did not have cache operations defined).
-If you see error lines marked with - that means that the errors were fixed
+Note that if there were other boards with errors, the above command would
+show their errors also. Each line is shown only once. So if lubbock and snow
+produce the same error, we just see:
+
+12: lcd: Add support for flushing LCD fb from dcache after update
+ arm: + lubbock snow
++common/libcommon.o: In function `lcd_sync':
++common/lcd.c:120: undefined reference to `flush_dcache_range'
++arm-none-linux-gnueabi-ld: BFD (Sourcery G++ Lite 2010q1-202) 2.19.51.20090709 assertion fail /scratch/julian/2010q1-release-linux-lite/obj/binutils-src-2010q1-202-arm-none-linux-gnueabi-i686-pc-linux-gnu/bfd/elf32-arm.c:12572
++make: *** [build/u-boot] Error 139
+
+But if you did want to see just the errors for lubbock, use:
+
+$ ./tools/buildman/buildman -b <branch> -se lubbock
+
+If you see error lines marked with '-', that means that the errors were fixed
by that commit. Sometimes commits can be in the wrong order, so that a
breakage is introduced for a few commits and fixed by later commits. This
shows up clearly with buildman. You can then reorder the commits and try
again.
-At commit 16, the error moves - you can see that the old error at line 120
+At commit 16, the error moves: you can see that the old error at line 120
is fixed, but there is a new one at line 126. This is probably only because
we added some code and moved the broken line further down the file.
-If many boards have the same error, then -e will display the error only
-once. This makes the output as concise as possible. To see which boards have
-each error, use -l.
+As mentioned, if many boards have the same error, then -e will display the
+error only once. This makes the output as concise as possible. To see which
+boards have each error, use -l. So it is safe to omit the board name - you
+will not get lots of repeated output for every board.
Buildman tries to distinguish warnings from errors, and shows warning lines
-separately with a 'w' prefix.
+separately with a 'w' prefix. Warnings introduced show as yellow. Warnings
+fixed show as cyan.
The full build output in this case is available in:
err: Output from stderr, if any. Errors and warnings appear here.
log: Output from stdout. Normally there isn't any since buildman runs
- in silent mode for now.
+ in silent mode. Use -V to force a verbose build (this passes V=1
+ to 'make')
toolchain: Shows information about the toolchain used for the build.
sizes: Shows image size information.
-It is possible to get the build output there also. Use the -k option for
-this. In that case you will also see some output files, like:
+It is possible to get the build binary output there also. Use the -k option
+for this. In that case you will also see some output files, like:
System.map toolchain u-boot u-boot.bin u-boot.map autoconf.mk
(also SPL versions u-boot-spl and u-boot-spl.bin if available)
A key requirement for U-Boot is that you keep code/data size to a minimum.
Where a new feature increases this noticeably it should normally be put
-behind a CONFIG flag so that boards can leave it off and keep the image
+behind a CONFIG flag so that boards can leave it disabled and keep the image
size more or less the same with each new release.
To check the impact of your commits on image size, use -S. For example:
--step 2 will show the image sizes for only every 2nd commit (so it will
compare the image sizes of the 1st, 3rd, 5th... commits). You can also use
--step 0 which will compare only the first and last commits. This is useful
-for an overview of how your entire series affects code size.
+for an overview of how your entire series affects code size. It will build
+only the upstream commit and your final branch commit.
You can also use -d to see a detailed size breakdown for each board. This
list is sorted in order from largest growth to largest reduction.
-It is possible to go a little further with the -B option (--bloat). This
+It is even possible to go a little further with the -B option (--bloat). This
shows where U-Boot has bloated, breaking the size change down to the function
level. Example output is below:
...
-This shows that commit 19 has increased text size for arm (although only one
-board was built) and by 96 bytes for powerpc. This increase was offset in both
-cases by reductions in rodata and data/bss.
+This shows that commit 19 has reduced codesize for arm slightly and increased
+it for powerpc. This increase was offset in by reductions in rodata and
+data/bss.
Shown below the summary lines are the sizes for each board. Below each board
are the sizes for each function. This information starts with:
will build commits in us-buildman that are not in upstream/master.
+Building Faster
+===============
+
+By default, buildman doesn't execute 'make mrproper' prior to building the
+first commit for each board. This reduces the amount of work 'make' does, and
+hence speeds up the build. To force use of 'make mrproper', use -the -m flag.
+This flag will slow down any buildman invocation, since it increases the amount
+of work done on any build.
+
+One possible application of buildman is as part of a continual edit, build,
+edit, build, ... cycle; repeatedly applying buildman to the same change or
+series of changes while making small incremental modifications to the source
+each time. This provides quick feedback regarding the correctness of recent
+modifications. In this scenario, buildman's default choice of build directory
+causes more build work to be performed than strictly necessary.
+
+By default, each buildman thread uses a single directory for all builds. When a
+thread builds multiple boards, the configuration built in this directory will
+cycle through various different configurations, one per board built by the
+thread. Variations in the configuration will force a rebuild of affected source
+files when a thread switches between boards. Ideally, such buildman-induced
+rebuilds would not happen, thus allowing the build to operate as efficiently as
+the build system and source changes allow. buildman's -P flag may be used to
+enable this; -P causes each board to be built in a separate (board-specific)
+directory, thus avoiding any buildman-induced configuration changes in any
+build directory.
+
+U-Boot's build system embeds information such as a build timestamp into the
+final binary. This information varies each time U-Boot is built. This causes
+various files to be rebuilt even if no source changes are made, which in turn
+requires that the final U-Boot binary be re-linked. This unnecessary work can
+be avoided by turning off the timestamp feature. This can be achieved by
+setting the SOURCE_DATE_EPOCH environment variable to 0.
+
+Combining all of these options together yields the command-line shown below.
+This will provide the quickest possible feedback regarding the current content
+of the source tree, thus allowing rapid tested evolution of the code.
+
+ SOURCE_DATE_EPOCH=0 ./tools/buildman/buildman -P tegra
+
+
+Checking configuration
+======================
+
+A common requirement when converting CONFIG options to Kconfig is to check
+that the effective configuration has not changed due to the conversion.
+Buildman supports this with the -K option, used after a build. This shows
+differences in effective configuration between one commit and the next.
+
+For example:
+
+ $ buildman -b kc4 -sK
+ ...
+ 43: Convert CONFIG_SPL_USBETH_SUPPORT to Kconfig
+ arm:
+ + u-boot.cfg: CONFIG_SPL_ENV_SUPPORT=1 CONFIG_SPL_NET_SUPPORT=1
+ + u-boot-spl.cfg: CONFIG_SPL_MMC_SUPPORT=1 CONFIG_SPL_NAND_SUPPORT=1
+ + all: CONFIG_SPL_ENV_SUPPORT=1 CONFIG_SPL_MMC_SUPPORT=1 CONFIG_SPL_NAND_SUPPORT=1 CONFIG_SPL_NET_SUPPORT=1
+ am335x_evm_usbspl :
+ + u-boot.cfg: CONFIG_SPL_ENV_SUPPORT=1 CONFIG_SPL_NET_SUPPORT=1
+ + u-boot-spl.cfg: CONFIG_SPL_MMC_SUPPORT=1 CONFIG_SPL_NAND_SUPPORT=1
+ + all: CONFIG_SPL_ENV_SUPPORT=1 CONFIG_SPL_MMC_SUPPORT=1 CONFIG_SPL_NAND_SUPPORT=1 CONFIG_SPL_NET_SUPPORT=1
+ 44: Convert CONFIG_SPL_USB_HOST_SUPPORT to Kconfig
+ ...
+
+This shows that commit 44 enabled three new options for the board
+am335x_evm_usbspl which were not enabled in commit 43. There is also a
+summary for 'arm' showing all the changes detected for that architecture.
+In this case there is only one board with changes, so 'arm' output is the
+same as 'am335x_evm_usbspl'/
+
+The -K option uses the u-boot.cfg, spl/u-boot-spl.cfg and tpl/u-boot-tpl.cfg
+files which are produced by a build. If all you want is to check the
+configuration you can in fact avoid doing a full build, using -D. This tells
+buildman to configuration U-Boot and create the .cfg files, but not actually
+build the source. This is 5-10 times faster than doing a full build.
+
+By default buildman considers the follow two configuration methods
+equivalent:
+
+ #define CONFIG_SOME_OPTION
+
+ CONFIG_SOME_OPTION=y
+
+The former would appear in a header filer and the latter in a defconfig
+file. The achieve this, buildman considers 'y' to be '1' in configuration
+variables. This avoids lots of useless output when converting a CONFIG
+option to Kconfig. To disable this behaviour, use --squash-config-y.
+
+
+Checking the environment
+========================
+
+When converting CONFIG options which manipulate the default environment,
+a common requirement is to check that the default environment has not
+changed due to the conversion. Buildman supports this with the -U option,
+used after a build. This shows differences in the default environment
+between one commit and the next.
+
+For example:
+
+$ buildman -b squash brppt1 -sU
+boards.cfg is up to date. Nothing to do.
+Summary of 2 commits for 3 boards (3 threads, 3 jobs per thread)
+01: Migrate bootlimit to Kconfig
+02: Squashed commit of the following:
+ c brppt1_mmc: altbootcmd=mmc dev 1; run mmcboot0; -> mmc dev 1; run mmcboot0
+ c brppt1_spi: altbootcmd=mmc dev 1; run mmcboot0; -> mmc dev 1; run mmcboot0
+ + brppt1_nand: altbootcmd=run usbscript
+ - brppt1_nand: altbootcmd=run usbscript
+(no errors to report)
+
+This shows that commit 2 modified the value of 'altbootcmd' for 'brppt1_mmc'
+and 'brppt1_spi', removing a trailing semicolon. 'brppt1_nand' gained an a
+value for 'altbootcmd', but lost one for ' altbootcmd'.
+
+The -U option uses the u-boot.env files which are produced by a build.
+
+
+Building with clang
+===================
+
+To build with clang (sandbox only), use the -O option to override the
+toolchain. For example:
+
+ buildman -O clang-7 --board sandbox
+
+
+Doing a simple build
+====================
+
+In some cases you just want to build a single board and get the full output, use
+the -w option, for example:
+
+ buildman -o /tmp/build --board sandbox -w
+
+This will write the full build into /tmp/build including object files.
+
+
Other options
=============
-Buildman has various other command line options. Try --help to see them.
+Buildman has various other command-line options. Try --help to see them.
+
+To find out what toolchain prefix buildman will use for a build, use the -A
+option.
+
+To request that compiler warnings be promoted to errors, use -E. This passes the
+-Werror flag to the compiler. Note that the build can still produce warnings
+with -E, e.g. the migration warnings:
+
+ ===================== WARNING ======================
+ This board does not use CONFIG_DM_MMC. Please update
+ ...
+ ====================================================
When doing builds, Buildman's return code will reflect the overall result:
0 (success) No errors or warnings found
- 128 Errors found
- 129 Warnings found
+ 100 Errors found
+ 101 Warnings found (only if no -W)
+
+You can use -W to tell Buildman to return 0 (success) instead of 101 when
+warnings are found. Note that it can be useful to combine -E and -W. This means
+that all compiler warnings will produce failures (code 100) and all other
+warnings will produce success (since 101 is changed to 0).
+
+If there are both warnings and errors, errors win, so buildman returns 100.
+
+The -y option is provided (for use with -s) to ignore the bountiful device-tree
+warnings. Similarly, -Y tells buildman to ignore the migration warnings.
How to change from MAKEALL
TODO
====
-This has mostly be written in my spare time as a response to my difficulties
-in testing large series of patches. Apart from tidying up there is quite a
-bit of scope for improvement. Things like better error diffs and easier
-access to log files. Also it would be nice if buildman could 'hunt' for
-problems, perhaps by building a few boards for each arch, or checking
-commits for changed files and building only boards which use those files.
+Many improvements have been made over the years. There is still quite a bit of
+scope for more though, e.g.:
+
+- easier access to log files
+- 'hunting' for problems, perhaps by building a few boards for each arch, or
+ checking commits for changed files and building only boards which use those
+ files
+- using the same git repo for all threads instead of cloning it. Currently
+ it uses about 500MB per thread, so on a 64-thread machine this is 32GB for
+ the build.
Credits
Halloween 2012
Updated 12-12-12
Updated 23-02-13
+Updated 09-04-20
projects / oweals / u-boot.git / blobdiff