+# 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)
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. 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. If you want buildman to re-build a commit it has already
-built (e.g. because of a toolchain update), use the -f flag.
+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.
+
+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
-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.
+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.
- 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 '/toolchains/gcc-4.2.4-nolibc/avr32-linux'
- - looking in '/toolchains/gcc-4.2.4-nolibc/avr32-linux/.'
- - looking in '/toolchains/gcc-4.2.4-nolibc/avr32-linux/bin'
- - found '/toolchains/gcc-4.2.4-nolibc/avr32-linux/bin/avr32-linux-gcc'
- - looking in '/toolchains/gcc-4.2.4-nolibc/avr32-linux/usr/bin'
-Tool chain test: OK, arch='avr32', priority 4
- scanning path '/'
- looking in '/.'
- looking in '/bin'
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
-avr32 : /toolchains/gcc-4.2.4-nolibc/avr32-linux/bin/avr32-linux-gcc
bfin : /toolchains/gcc-4.6.3-nolibc/bfin-uclinux/bin/bfin-uclinux-gcc
c89 : /usr/bin/c89-gcc
c99 : /usr/bin/c99-gcc
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
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/
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 around an hour and a quarter. 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 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).
+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
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. So it is safe to omit the board name - you will not get
-lots of repeated output for every board.
+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:
Building Faster
===============
-By default, buildman executes 'make mrproper' prior to building the first
-commit for each board. This causes everything to be built from scratch. If you
-trust the build system's incremental build capabilities, you can pass the -I
-flag to skip the 'make mproper' invocation, which will reduce the amount of
-work 'make' does, and hence speed up the build. This flag will speed up any
-buildman invocation, since it reduces the amount of work done on any build.
+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
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 -I -P tegra
+ SOURCE_DATE_EPOCH=0 ./tools/buildman/buildman -P tegra
Checking configuration
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.
-A specific problem to fix is that Ctrl-C does not exit buildman cleanly when
-multiple builder threads are active.
Credits
=======
Halloween 2012
Updated 12-12-12
Updated 23-02-13
+Updated 09-04-20
projects / oweals / u-boot.git / blobdiff