1 # SPDX-License-Identifier: GPL-2.0+
2 # Copyright (c) 2013 The Chromium OS Authors.
4 (Please read 'How to change from MAKEALL' if you are used to that tool)
9 If you just want to quickly set up buildman so you can build something (for
10 example Raspberry Pi 2):
13 PATH=$PATH:`pwd`/tools/buildman
14 buildman --fetch-arch arm
17 # u-boot.bin is the output image
23 This tool handles building U-Boot to check that you have not broken it
24 with your patch series. It can build each individual commit and report
25 which boards fail on which commits, and which errors come up. It aims
26 to make full use of multi-processor machines.
28 A key feature of buildman is its output summary, which allows warnings,
29 errors or image size increases in a particular commit or board to be
30 quickly identified and the offending commit pinpointed. This can be a big
31 help for anyone working with >10 patches at a time.
37 Buildman can be stopped and restarted, in which case it will continue
38 where it left off. This should happen cleanly and without side-effects.
39 If not, it is a bug, for which a patch would be welcome.
41 Buildman gets so tied up in its work that it can ignore the outside world.
42 You may need to press Ctrl-C several times to quit it. Also it will print
43 out various exceptions when stopped. You may have to kill it since the
44 Ctrl-C handling is somewhat broken.
50 (please read this section in full twice or you will be perpetually confused)
52 Buildman is a builder. It is not make, although it runs make. It does not
53 produce any useful output on the terminal while building, except for
54 progress information (but see -v below). All the output (errors, warnings and
55 binaries if you ask for them) is stored in output directories, which you can
56 look at from a separate 'buildman -s' instance while the build is progressing,
57 or when it is finished.
59 Buildman is designed to build entire git branches, i.e. muliple commits. It
60 can be run repeatedly on the same branch after making changes to commits on
61 that branch. In this case it will automatically rebuild commits which have
62 changed (and remove its old results for that commit). It is possible to build
63 a branch for one board, then later build it for another board. This adds to
64 the output, so now you have results for two boards. If you want buildman to
65 re-build a commit it has already built (e.g. because of a toolchain update),
68 Buildman produces a concise summary of which boards succeeded and failed.
69 It shows which commit introduced which board failure using a simple
70 red/green colour coding (with yellow/cyan for warnings). Full error
71 information can be requested, in which case it is de-duped and displayed
72 against the commit that introduced the error. An example workflow is below.
74 Buildman stores image size information and can report changes in image size
75 from commit to commit. An example of this is below.
77 Buildman starts multiple threads, and each thread builds for one board at
78 a time. A thread starts at the first commit, configures the source for your
79 board and builds it. Then it checks out the next commit and does an
80 incremental build (i.e. not using 'make xxx_defconfig' unless you use -C).
81 Eventually the thread reaches the last commit and stops. If a commit causes
82 an error or warning, buildman will try it again after reconfiguring (but see
83 -Q). Thus some commits may be built twice, with the first result silently
84 discarded. Lots of errors and warnings will causes lots of reconfigures and your
85 build will be very slow. This is because a file that produces just a warning
86 would not normally be rebuilt in an incremental build. Once a thread finishes
87 building all the commits for a board, it starts on the commits for another
90 Buildman works in an entirely separate place from your U-Boot repository.
91 It creates a separate working directory for each thread, and puts the
92 output files in the working directory, organised by commit name and board
93 name, in a two-level hierarchy (but see -P).
95 Buildman is invoked in your U-Boot directory, the one with the .git
96 directory. It clones this repository into a copy for each thread, and the
97 threads do not affect the state of your git repository. Any checkouts done
98 by the thread affect only the working directory for that thread.
100 Buildman automatically selects the correct tool chain for each board. You
101 must supply suitable tool chains (see --fetch-arch), but buildman takes care
102 of selecting the right one.
104 Buildman generally builds a branch (with the -b flag), and in this case
105 builds the upstream commit as well, for comparison. So even if you have one
106 commit in your branch, two commits will be built. Put all your commits in a
107 branch, set the branch's upstream to a valid value, and all will be well.
108 Otherwise buildman will perform random actions. Use -n to check what the
109 random actions might be.
111 Buildman effectively has two modes: without -s it builds, with -s it
112 summarises the results of previous (or active) builds.
114 If you just want to build the current source tree, leave off the -b flag.
115 This will display results and errors as they happen. You can still look at
116 them later using -se. Note that buildman will assume that the source has
117 changed, and will build all specified boards in this case.
119 Buildman is optimised for building many commits at once, for many boards.
120 On multi-core machines, Buildman is fast because it uses most of the
121 available CPU power. When it gets to the end, or if you are building just
122 a few commits or boards, it will be pretty slow. As a tip, if you don't
123 plan to use your machine for anything else, you can use -T to increase the
124 number of threads beyond the default.
127 Selecting which boards to build
128 ===============================
130 Buildman lets you build all boards, or a subset. Specify the subset by passing
131 command-line arguments that list the desired build target, architecture,
132 CPU, board name, vendor, SoC or options. Multiple arguments are allowed. Each
133 argument will be interpreted as a regular expression, so behaviour is a superset
134 of exact or substring matching. Examples are:
136 * 'tegra20' All boards with a Tegra20 SoC
137 * 'tegra' All boards with any Tegra Soc (Tegra20, Tegra30, Tegra114...)
138 * '^tegra[23]0$' All boards with either Tegra20 or Tegra30 SoC
139 * 'powerpc' All PowerPC boards
141 While the default is to OR the terms together, you can also make use of
142 the '&' operator to limit the selection:
144 * 'freescale & arm sandbox' All Freescale boards with ARM architecture,
147 You can also use -x to specifically exclude some boards. For example:
149 buildman arm -x nvidia,freescale,.*ball$
151 means to build all arm boards except nvidia, freescale and anything ending
154 For building specific boards you can use the --boards (or --bo) option, which
155 takes a comma-separated list of board target names and be used multiple times
158 buildman --boards sandbox,snow --boards
160 It is convenient to use the -n option to see what will be built based on
161 the subset given. Use -v as well to get an actual list of boards.
163 Buildman does not store intermediate object files. It optionally copies
164 the binary output into a directory when a build is successful (-k). Size
165 information is always recorded. It needs a fair bit of disk space to work,
166 typically 250MB per thread.
172 1. Get the U-Boot source. You probably already have it, but if not these
173 steps should get you started with a repo and some commits for testing.
176 $ git clone git://git.denx.de/u-boot.git .
177 $ git checkout -b my-branch origin/master
178 $ # Add some commits to the branch, reading for testing
180 2. Create ~/.buildman to tell buildman where to find tool chains (see 'The
181 .buildman file' later for details). As an example:
183 # Buildman settings file
189 arm: /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.8-2013.08_linux
190 aarch64: /opt/linaro/gcc-linaro-aarch64-none-elf-4.8-2013.10_linux
198 This selects the available toolchain paths. Add the base directory for
199 each of your toolchains here. Buildman will search inside these directories
200 and also in any '/usr' and '/usr/bin' subdirectories.
202 Make sure the tags (here root: rest: and eldk:) are unique.
204 The toolchain-alias section indicates that the i386 toolchain should be used
205 to build x86 commits.
207 Note that you can also specific exactly toolchain prefixes if you like:
210 arm: /opt/arm-eabi-4.6/bin/arm-eabi-
215 arm: /opt/arm-eabi-4.6/bin/arm-eabi-gcc
217 This tells buildman that you want to use this exact toolchain for the arm
218 architecture. This will override any toolchains found by searching using the
219 [toolchain] settings.
221 Since the toolchain prefix is an explicit request, buildman will report an
222 error if a toolchain is not found with that prefix. The current PATH will be
223 searched, so it is possible to use:
228 and buildman will find arm-none-eabi-gcc in /usr/bin if you have it installed.
233 This tells buildman to use a compiler wrapper in front of CROSS_COMPILE. In
234 this example, ccache. It doesn't affect the toolchain scan. The wrapper is
235 added when CROSS_COMPILE environtal variable is set. The name in this
236 section is ignored. If more than one line is provided, only the last one
239 3. Make sure you have the require Python pre-requisites
241 Buildman uses multiprocessing, Queue, shutil, StringIO, ConfigParser and
242 urllib2. These should normally be available, but if you get an error like
243 this then you will need to obtain those modules:
245 ImportError: No module named multiprocessing
248 4. Check the available toolchains
250 Run this check to make sure that you have a toolchain for every architecture.
252 $ ./tools/buildman/buildman --list-tool-chains
253 Scanning for tool chains
254 - scanning prefix '/opt/gcc-4.6.3-nolibc/x86_64-linux/bin/x86_64-linux-'
255 Tool chain test: OK, arch='x86', priority 1
256 - scanning prefix '/opt/arm-eabi-4.6/bin/arm-eabi-'
257 Tool chain test: OK, arch='arm', priority 1
258 - scanning path '/toolchains/gcc-4.9.0-nolibc/i386-linux'
259 - looking in '/toolchains/gcc-4.9.0-nolibc/i386-linux/.'
260 - looking in '/toolchains/gcc-4.9.0-nolibc/i386-linux/bin'
261 - found '/toolchains/gcc-4.9.0-nolibc/i386-linux/bin/i386-linux-gcc'
262 - looking in '/toolchains/gcc-4.9.0-nolibc/i386-linux/usr/bin'
263 Tool chain test: OK, arch='i386', priority 4
264 - scanning path '/toolchains/gcc-4.9.0-nolibc/aarch64-linux'
265 - looking in '/toolchains/gcc-4.9.0-nolibc/aarch64-linux/.'
266 - looking in '/toolchains/gcc-4.9.0-nolibc/aarch64-linux/bin'
267 - found '/toolchains/gcc-4.9.0-nolibc/aarch64-linux/bin/aarch64-linux-gcc'
268 - looking in '/toolchains/gcc-4.9.0-nolibc/aarch64-linux/usr/bin'
269 Tool chain test: OK, arch='aarch64', priority 4
270 - scanning path '/toolchains/gcc-4.9.0-nolibc/microblaze-linux'
271 - looking in '/toolchains/gcc-4.9.0-nolibc/microblaze-linux/.'
272 - looking in '/toolchains/gcc-4.9.0-nolibc/microblaze-linux/bin'
273 - found '/toolchains/gcc-4.9.0-nolibc/microblaze-linux/bin/microblaze-linux-gcc'
274 - looking in '/toolchains/gcc-4.9.0-nolibc/microblaze-linux/usr/bin'
275 Tool chain test: OK, arch='microblaze', priority 4
276 - scanning path '/toolchains/gcc-4.9.0-nolibc/mips64-linux'
277 - looking in '/toolchains/gcc-4.9.0-nolibc/mips64-linux/.'
278 - looking in '/toolchains/gcc-4.9.0-nolibc/mips64-linux/bin'
279 - found '/toolchains/gcc-4.9.0-nolibc/mips64-linux/bin/mips64-linux-gcc'
280 - looking in '/toolchains/gcc-4.9.0-nolibc/mips64-linux/usr/bin'
281 Tool chain test: OK, arch='mips64', priority 4
282 - scanning path '/toolchains/gcc-4.9.0-nolibc/sparc64-linux'
283 - looking in '/toolchains/gcc-4.9.0-nolibc/sparc64-linux/.'
284 - looking in '/toolchains/gcc-4.9.0-nolibc/sparc64-linux/bin'
285 - found '/toolchains/gcc-4.9.0-nolibc/sparc64-linux/bin/sparc64-linux-gcc'
286 - looking in '/toolchains/gcc-4.9.0-nolibc/sparc64-linux/usr/bin'
287 Tool chain test: OK, arch='sparc64', priority 4
288 - scanning path '/toolchains/gcc-4.9.0-nolibc/arm-unknown-linux-gnueabi'
289 - looking in '/toolchains/gcc-4.9.0-nolibc/arm-unknown-linux-gnueabi/.'
290 - looking in '/toolchains/gcc-4.9.0-nolibc/arm-unknown-linux-gnueabi/bin'
291 - found '/toolchains/gcc-4.9.0-nolibc/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-gcc'
292 - looking in '/toolchains/gcc-4.9.0-nolibc/arm-unknown-linux-gnueabi/usr/bin'
293 Tool chain test: OK, arch='arm', priority 3
294 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
295 - scanning path '/toolchains/gcc-4.9.0-nolibc/sparc-linux'
296 - looking in '/toolchains/gcc-4.9.0-nolibc/sparc-linux/.'
297 - looking in '/toolchains/gcc-4.9.0-nolibc/sparc-linux/bin'
298 - found '/toolchains/gcc-4.9.0-nolibc/sparc-linux/bin/sparc-linux-gcc'
299 - looking in '/toolchains/gcc-4.9.0-nolibc/sparc-linux/usr/bin'
300 Tool chain test: OK, arch='sparc', priority 4
301 - scanning path '/toolchains/gcc-4.9.0-nolibc/mips-linux'
302 - looking in '/toolchains/gcc-4.9.0-nolibc/mips-linux/.'
303 - looking in '/toolchains/gcc-4.9.0-nolibc/mips-linux/bin'
304 - found '/toolchains/gcc-4.9.0-nolibc/mips-linux/bin/mips-linux-gcc'
305 - looking in '/toolchains/gcc-4.9.0-nolibc/mips-linux/usr/bin'
306 Tool chain test: OK, arch='mips', priority 4
307 - scanning path '/toolchains/gcc-4.9.0-nolibc/x86_64-linux'
308 - looking in '/toolchains/gcc-4.9.0-nolibc/x86_64-linux/.'
309 - looking in '/toolchains/gcc-4.9.0-nolibc/x86_64-linux/bin'
310 - found '/toolchains/gcc-4.9.0-nolibc/x86_64-linux/bin/x86_64-linux-gcc'
311 - found '/toolchains/gcc-4.9.0-nolibc/x86_64-linux/bin/x86_64-linux-x86_64-linux-gcc'
312 - looking in '/toolchains/gcc-4.9.0-nolibc/x86_64-linux/usr/bin'
313 Tool chain test: OK, arch='x86_64', priority 4
314 Tool chain test: OK, arch='x86_64', priority 4
315 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
316 - scanning path '/toolchains/gcc-4.9.0-nolibc/m68k-linux'
317 - looking in '/toolchains/gcc-4.9.0-nolibc/m68k-linux/.'
318 - looking in '/toolchains/gcc-4.9.0-nolibc/m68k-linux/bin'
319 - found '/toolchains/gcc-4.9.0-nolibc/m68k-linux/bin/m68k-linux-gcc'
320 - looking in '/toolchains/gcc-4.9.0-nolibc/m68k-linux/usr/bin'
321 Tool chain test: OK, arch='m68k', priority 4
322 - scanning path '/toolchains/gcc-4.9.0-nolibc/powerpc-linux'
323 - looking in '/toolchains/gcc-4.9.0-nolibc/powerpc-linux/.'
324 - looking in '/toolchains/gcc-4.9.0-nolibc/powerpc-linux/bin'
325 - found '/toolchains/gcc-4.9.0-nolibc/powerpc-linux/bin/powerpc-linux-gcc'
326 - looking in '/toolchains/gcc-4.9.0-nolibc/powerpc-linux/usr/bin'
327 Tool chain test: OK, arch='powerpc', priority 4
328 - scanning path '/toolchains/gcc-4.6.3-nolibc/bfin-uclinux'
329 - looking in '/toolchains/gcc-4.6.3-nolibc/bfin-uclinux/.'
330 - looking in '/toolchains/gcc-4.6.3-nolibc/bfin-uclinux/bin'
331 - found '/toolchains/gcc-4.6.3-nolibc/bfin-uclinux/bin/bfin-uclinux-gcc'
332 - looking in '/toolchains/gcc-4.6.3-nolibc/bfin-uclinux/usr/bin'
333 Tool chain test: OK, arch='bfin', priority 6
334 - scanning path '/toolchains/gcc-4.6.3-nolibc/sparc-linux'
335 - looking in '/toolchains/gcc-4.6.3-nolibc/sparc-linux/.'
336 - looking in '/toolchains/gcc-4.6.3-nolibc/sparc-linux/bin'
337 - found '/toolchains/gcc-4.6.3-nolibc/sparc-linux/bin/sparc-linux-gcc'
338 - looking in '/toolchains/gcc-4.6.3-nolibc/sparc-linux/usr/bin'
339 Tool chain test: OK, arch='sparc', priority 4
340 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
341 - scanning path '/toolchains/gcc-4.6.3-nolibc/mips-linux'
342 - looking in '/toolchains/gcc-4.6.3-nolibc/mips-linux/.'
343 - looking in '/toolchains/gcc-4.6.3-nolibc/mips-linux/bin'
344 - found '/toolchains/gcc-4.6.3-nolibc/mips-linux/bin/mips-linux-gcc'
345 - looking in '/toolchains/gcc-4.6.3-nolibc/mips-linux/usr/bin'
346 Tool chain test: OK, arch='mips', priority 4
347 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
348 - scanning path '/toolchains/gcc-4.6.3-nolibc/m68k-linux'
349 - looking in '/toolchains/gcc-4.6.3-nolibc/m68k-linux/.'
350 - looking in '/toolchains/gcc-4.6.3-nolibc/m68k-linux/bin'
351 - found '/toolchains/gcc-4.6.3-nolibc/m68k-linux/bin/m68k-linux-gcc'
352 - looking in '/toolchains/gcc-4.6.3-nolibc/m68k-linux/usr/bin'
353 Tool chain test: OK, arch='m68k', priority 4
354 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
355 - scanning path '/toolchains/gcc-4.6.3-nolibc/powerpc-linux'
356 - looking in '/toolchains/gcc-4.6.3-nolibc/powerpc-linux/.'
357 - looking in '/toolchains/gcc-4.6.3-nolibc/powerpc-linux/bin'
358 - found '/toolchains/gcc-4.6.3-nolibc/powerpc-linux/bin/powerpc-linux-gcc'
359 - looking in '/toolchains/gcc-4.6.3-nolibc/powerpc-linux/usr/bin'
360 Tool chain test: OK, arch='powerpc', priority 4
361 Tool chain test: OK, arch='or32', priority 4
365 - looking in '/usr/bin'
366 - found '/usr/bin/i586-mingw32msvc-gcc'
367 - found '/usr/bin/c89-gcc'
368 - found '/usr/bin/x86_64-linux-gnu-gcc'
369 - found '/usr/bin/gcc'
370 - found '/usr/bin/c99-gcc'
371 - found '/usr/bin/arm-linux-gnueabi-gcc'
372 - found '/usr/bin/aarch64-linux-gnu-gcc'
373 - found '/usr/bin/winegcc'
374 - found '/usr/bin/arm-linux-gnueabihf-gcc'
375 Tool chain test: OK, arch='i586', priority 11
376 Tool chain test: OK, arch='c89', priority 11
377 Tool chain test: OK, arch='x86_64', priority 4
378 Toolchain '/usr/bin/x86_64-linux-gnu-gcc' at priority 4 will be ignored because another toolchain for arch 'x86_64' has priority 4
379 Tool chain test: OK, arch='sandbox', priority 11
380 Tool chain test: OK, arch='c99', priority 11
381 Tool chain test: OK, arch='arm', priority 4
382 Toolchain '/usr/bin/arm-linux-gnueabi-gcc' at priority 4 will be ignored because another toolchain for arch 'arm' has priority 1
383 Tool chain test: OK, arch='aarch64', priority 4
384 Toolchain '/usr/bin/aarch64-linux-gnu-gcc' at priority 4 will be ignored because another toolchain for arch 'aarch64' has priority 4
385 Tool chain test: OK, arch='sandbox', priority 11
386 Toolchain '/usr/bin/winegcc' at priority 11 will be ignored because another toolchain for arch 'sandbox' has priority 11
387 Tool chain test: OK, arch='arm', priority 4
388 Toolchain '/usr/bin/arm-linux-gnueabihf-gcc' at priority 4 will be ignored because another toolchain for arch 'arm' has priority 1
389 List of available toolchains (34):
390 aarch64 : /toolchains/gcc-4.9.0-nolibc/aarch64-linux/bin/aarch64-linux-gcc
391 alpha : /toolchains/gcc-4.9.0-nolibc/alpha-linux/bin/alpha-linux-gcc
392 am33_2.0 : /toolchains/gcc-4.9.0-nolibc/am33_2.0-linux/bin/am33_2.0-linux-gcc
393 arm : /opt/arm-eabi-4.6/bin/arm-eabi-gcc
394 bfin : /toolchains/gcc-4.6.3-nolibc/bfin-uclinux/bin/bfin-uclinux-gcc
395 c89 : /usr/bin/c89-gcc
396 c99 : /usr/bin/c99-gcc
397 frv : /toolchains/gcc-4.9.0-nolibc/frv-linux/bin/frv-linux-gcc
398 h8300 : /toolchains/gcc-4.9.0-nolibc/h8300-elf/bin/h8300-elf-gcc
399 hppa : /toolchains/gcc-4.9.0-nolibc/hppa-linux/bin/hppa-linux-gcc
400 hppa64 : /toolchains/gcc-4.9.0-nolibc/hppa64-linux/bin/hppa64-linux-gcc
401 i386 : /toolchains/gcc-4.9.0-nolibc/i386-linux/bin/i386-linux-gcc
402 i586 : /usr/bin/i586-mingw32msvc-gcc
403 ia64 : /toolchains/gcc-4.9.0-nolibc/ia64-linux/bin/ia64-linux-gcc
404 m32r : /toolchains/gcc-4.9.0-nolibc/m32r-linux/bin/m32r-linux-gcc
405 m68k : /toolchains/gcc-4.9.0-nolibc/m68k-linux/bin/m68k-linux-gcc
406 microblaze: /toolchains/gcc-4.9.0-nolibc/microblaze-linux/bin/microblaze-linux-gcc
407 mips : /toolchains/gcc-4.9.0-nolibc/mips-linux/bin/mips-linux-gcc
408 mips64 : /toolchains/gcc-4.9.0-nolibc/mips64-linux/bin/mips64-linux-gcc
409 or32 : /toolchains/gcc-4.5.1-nolibc/or32-linux/bin/or32-linux-gcc
410 powerpc : /toolchains/gcc-4.9.0-nolibc/powerpc-linux/bin/powerpc-linux-gcc
411 powerpc64 : /toolchains/gcc-4.9.0-nolibc/powerpc64-linux/bin/powerpc64-linux-gcc
412 ppc64le : /toolchains/gcc-4.9.0-nolibc/ppc64le-linux/bin/ppc64le-linux-gcc
413 s390x : /toolchains/gcc-4.9.0-nolibc/s390x-linux/bin/s390x-linux-gcc
414 sandbox : /usr/bin/gcc
415 sh4 : /toolchains/gcc-4.6.3-nolibc/sh4-linux/bin/sh4-linux-gcc
416 sparc : /toolchains/gcc-4.9.0-nolibc/sparc-linux/bin/sparc-linux-gcc
417 sparc64 : /toolchains/gcc-4.9.0-nolibc/sparc64-linux/bin/sparc64-linux-gcc
418 tilegx : /toolchains/gcc-4.6.2-nolibc/tilegx-linux/bin/tilegx-linux-gcc
419 x86 : /opt/gcc-4.6.3-nolibc/x86_64-linux/bin/x86_64-linux-gcc
420 x86_64 : /toolchains/gcc-4.9.0-nolibc/x86_64-linux/bin/x86_64-linux-gcc
423 You can see that everything is covered, even some strange ones that won't
424 be used (c88 and c99). This is a feature.
427 5. Install new toolchains if needed
429 You can download toolchains and update the [toolchain] section of the
430 settings file to find them.
432 To make this easier, buildman can automatically download and install
433 toolchains from kernel.org. First list the available architectures:
435 $ ./tools/buildman/buildman --fetch-arch list
436 Checking: https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/
437 Checking: https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.2/
438 Checking: https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.5.1/
439 Checking: https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.2.4/
440 Available architectures: alpha am33_2.0 arm bfin cris crisv32 frv h8300
441 hppa hppa64 i386 ia64 m32r m68k mips mips64 or32 powerpc powerpc64 s390x sh4
442 sparc sparc64 tilegx x86_64 xtensa
444 Then pick one and download it:
446 $ ./tools/buildman/buildman --fetch-arch or32
447 Checking: https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/
448 Checking: https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.2/
449 Checking: https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.5.1/
450 Downloading: https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.5.1//x86_64-gcc-4.5.1-nolibc_or32-linux.tar.xz
451 Unpacking to: /home/sjg/.buildman-toolchains
453 - looking in '/home/sjg/.buildman-toolchains/gcc-4.5.1-nolibc/or32-linux/.'
454 - looking in '/home/sjg/.buildman-toolchains/gcc-4.5.1-nolibc/or32-linux/bin'
455 - found '/home/sjg/.buildman-toolchains/gcc-4.5.1-nolibc/or32-linux/bin/or32-linux-gcc'
458 Or download them all from kernel.org and move them to /toolchains directory,
460 $ ./tools/buildman/buildman --fetch-arch all
461 $ sudo mkdir -p /toolchains
462 $ sudo mv ~/.buildman-toolchains/*/* /toolchains/
464 For those not available from kernel.org, download from the following links.
466 arc: https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/
467 download/arc-2016.09-release/arc_gnu_2016.09_prebuilt_uclibc_le_archs_linux_install.tar.gz
468 blackfin: http://sourceforge.net/projects/adi-toolchain/files/
469 blackfin-toolchain-elf-gcc-4.5-2014R1_45-RC2.x86_64.tar.bz2
470 nios2: http://sourcery.mentor.com/public/gnu_toolchain/nios2-linux-gnu/
471 sourceryg++-2015.11-27-nios2-linux-gnu-i686-pc-linux-gnu.tar.bz2
472 sh: http://sourcery.mentor.com/public/gnu_toolchain/sh-linux-gnu/
473 renesas-4.4-200-sh-linux-gnu-i686-pc-linux-gnu.tar.bz2
475 Note openrisc kernel.org toolchain is out of date. Download the latest one from
476 http://opencores.org/or1k/OpenRISC_GNU_tool_chain#Prebuilt_versions - eg:
477 ftp://ocuser:ocuser@openrisc.opencores.org/toolchain/gcc-or1k-elf-4.8.1-x86.tar.bz2.
479 Buildman should now be set up to use your new toolchain.
481 At the time of writing, U-Boot has these architectures:
483 arc, arm, blackfin, m68k, microblaze, mips, nios2, openrisc
484 powerpc, sandbox, sh, sparc, x86
486 Of these, only arc is not available at kernel.org..
492 First do a dry run using the -n flag: (replace <branch> with a real, local
493 branch with a valid upstream)
495 $ ./tools/buildman/buildman -b <branch> -n
497 If it can't detect the upstream branch, try checking out the branch, and
498 doing something like 'git branch --set-upstream-to upstream/master'
499 or something similar. Buildman will try to guess a suitable upstream branch
500 if it can't find one (you will see a message like" Guessing upstream as ...).
501 You can also use the -c option to manually specify the number of commits to
506 Dry run, so not doing much. But I would do this:
508 Building 18 commits for 1059 boards (4 threads, 1 job per thread)
509 Build directory: ../lcd9b
510 5bb3505 Merge branch 'master' of git://git.denx.de/u-boot-arm
511 c18f1b4 tegra: Use const for pinmux_config_pingroup/table()
512 2f043ae tegra: Add display support to funcmux
513 e349900 tegra: fdt: Add pwm binding and node
514 424a5f0 tegra: fdt: Add LCD definitions for Tegra
515 0636ccf tegra: Add support for PWM
516 a994fe7 tegra: Add SOC support for display/lcd
517 fcd7350 tegra: Add LCD driver
518 4d46e9d tegra: Add LCD support to Nvidia boards
519 991bd48 arm: Add control over cachability of memory regions
520 54e8019 lcd: Add CONFIG_LCD_ALIGNMENT to select frame buffer alignment
521 d92aff7 lcd: Add support for flushing LCD fb from dcache after update
522 dbd0677 tegra: Align LCD frame buffer to section boundary
523 0cff9b8 tegra: Support control of cache settings for LCD
524 9c56900 tegra: fdt: Add LCD definitions for Seaboard
525 5cc29db lcd: Add CONFIG_CONSOLE_SCROLL_LINES option to speed console
526 cac5a23 tegra: Enable display/lcd support on Seaboard
529 Total boards to build for each commit: 1059
531 This shows that it will build all 1059 boards, using 4 threads (because
532 we have a 4-core CPU). Each thread will run with -j1, meaning that each
533 make job will use a single CPU. The list of commits to be built helps you
534 confirm that things look about right. Notice that buildman has chosen a
535 'base' directory for you, immediately above your source tree.
537 Buildman works entirely inside the base directory, here ../lcd9b,
538 creating a working directory for each thread, and creating output
539 directories for each commit and board.
545 To run the build for real, take off the -n:
547 $ ./tools/buildman/buildman -b <branch>
549 Buildman will set up some working directories, and get started. After a
550 minute or so it will settle down to a steady pace, with a display like this:
552 Building 18 commits for 1059 boards (4 threads, 1 job per thread)
553 528 36 124 /19062 -18374 1:13:30 : SIMPC8313_SP
555 This means that it is building 19062 board/commit combinations. So far it
556 has managed to successfully build 528. Another 36 have built with warnings,
557 and 124 more didn't build at all. It has 18374 builds left to complete.
558 Buildman expects to complete the process in around an hour and a quarter.
559 Use this time to buy a faster computer.
562 To find out how the build went, ask for a summary with -s. You can do this
563 either before the build completes (presumably in another terminal) or
564 afterwards. Let's work through an example of how this is used:
566 $ ./tools/buildman/buildman -b lcd9b -s
568 01: Merge branch 'master' of git://git.denx.de/u-boot-arm
569 powerpc: + galaxy5200_LOWBOOT
570 02: tegra: Use const for pinmux_config_pingroup/table()
571 03: tegra: Add display support to funcmux
572 04: tegra: fdt: Add pwm binding and node
573 05: tegra: fdt: Add LCD definitions for Tegra
574 06: tegra: Add support for PWM
575 07: tegra: Add SOC support for display/lcd
576 08: tegra: Add LCD driver
577 09: tegra: Add LCD support to Nvidia boards
578 10: arm: Add control over cachability of memory regions
579 11: lcd: Add CONFIG_LCD_ALIGNMENT to select frame buffer alignment
580 12: lcd: Add support for flushing LCD fb from dcache after update
582 13: tegra: Align LCD frame buffer to section boundary
583 14: tegra: Support control of cache settings for LCD
584 15: tegra: fdt: Add LCD definitions for Seaboard
585 16: lcd: Add CONFIG_CONSOLE_SCROLL_LINES option to speed console
586 17: tegra: Enable display/lcd support on Seaboard
589 This shows which commits have succeeded and which have failed. In this case
590 the build is still in progress so many boards are not built yet (use -u to
591 see which ones). But already we can see a few failures. The galaxy5200_LOWBOOT
592 never builds correctly. This could be a problem with our toolchain, or it
593 could be a bug in the upstream. The good news is that we probably don't need
594 to blame our commits. The bad news is that our commits are not tested on that
597 Commit 12 broke lubbock. That's what the '+ lubbock', in red, means. The
598 failure is never fixed by a later commit, or you would see lubbock again, in
599 green, without the +.
601 To see the actual error:
603 $ ./tools/buildman/buildman -b <branch> -se
605 12: lcd: Add support for flushing LCD fb from dcache after update
607 +common/libcommon.o: In function `lcd_sync':
608 +common/lcd.c:120: undefined reference to `flush_dcache_range'
609 +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
610 +make: *** [build/u-boot] Error 139
611 13: tegra: Align LCD frame buffer to section boundary
612 14: tegra: Support control of cache settings for LCD
613 15: tegra: fdt: Add LCD definitions for Seaboard
614 16: lcd: Add CONFIG_CONSOLE_SCROLL_LINES option to speed console
615 -common/lcd.c:120: undefined reference to `flush_dcache_range'
616 +common/lcd.c:125: undefined reference to `flush_dcache_range'
617 17: tegra: Enable display/lcd support on Seaboard
620 So the problem is in lcd.c, due to missing cache operations. This information
621 should be enough to work out what that commit is doing to break these
622 boards. (In this case pxa did not have cache operations defined).
624 Note that if there were other boards with errors, the above command would
625 show their errors also. Each line is shown only once. So if lubbock and snow
626 produce the same error, we just see:
628 12: lcd: Add support for flushing LCD fb from dcache after update
630 +common/libcommon.o: In function `lcd_sync':
631 +common/lcd.c:120: undefined reference to `flush_dcache_range'
632 +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
633 +make: *** [build/u-boot] Error 139
635 But if you did want to see just the errors for lubbock, use:
637 $ ./tools/buildman/buildman -b <branch> -se lubbock
639 If you see error lines marked with '-', that means that the errors were fixed
640 by that commit. Sometimes commits can be in the wrong order, so that a
641 breakage is introduced for a few commits and fixed by later commits. This
642 shows up clearly with buildman. You can then reorder the commits and try
645 At commit 16, the error moves: you can see that the old error at line 120
646 is fixed, but there is a new one at line 126. This is probably only because
647 we added some code and moved the broken line further down the file.
649 As mentioned, if many boards have the same error, then -e will display the
650 error only once. This makes the output as concise as possible. To see which
651 boards have each error, use -l. So it is safe to omit the board name - you
652 will not get lots of repeated output for every board.
654 Buildman tries to distinguish warnings from errors, and shows warning lines
655 separately with a 'w' prefix. Warnings introduced show as yellow. Warnings
658 The full build output in this case is available in:
660 ../lcd9b/12_of_18_gd92aff7_lcd--Add-support-for/lubbock/
662 done: Indicates the build was done, and holds the return code from make.
663 This is 0 for a good build, typically 2 for a failure.
665 err: Output from stderr, if any. Errors and warnings appear here.
667 log: Output from stdout. Normally there isn't any since buildman runs
668 in silent mode. Use -V to force a verbose build (this passes V=1
671 toolchain: Shows information about the toolchain used for the build.
673 sizes: Shows image size information.
675 It is possible to get the build binary output there also. Use the -k option
676 for this. In that case you will also see some output files, like:
678 System.map toolchain u-boot u-boot.bin u-boot.map autoconf.mk
679 (also SPL versions u-boot-spl and u-boot-spl.bin if available)
685 A key requirement for U-Boot is that you keep code/data size to a minimum.
686 Where a new feature increases this noticeably it should normally be put
687 behind a CONFIG flag so that boards can leave it disabled and keep the image
688 size more or less the same with each new release.
690 To check the impact of your commits on image size, use -S. For example:
692 $ ./tools/buildman/buildman -b us-x86 -sS
693 Summary of 10 commits for 1066 boards (4 threads, 1 job per thread)
694 01: MAKEALL: add support for per architecture toolchains
695 02: x86: Add function to get top of usable ram
696 x86: (for 1/3 boards) text -272.0 rodata +41.0
697 03: x86: Add basic cache operations
698 04: x86: Permit bootstage and timer data to be used prior to relocation
699 x86: (for 1/3 boards) data +16.0
700 05: x86: Add an __end symbol to signal the end of the U-Boot binary
701 x86: (for 1/3 boards) text +76.0
702 06: x86: Rearrange the output input to remove BSS
703 x86: (for 1/3 boards) bss -2140.0
704 07: x86: Support relocation of FDT on start-up
706 08: x86: Add error checking to x86 relocation code
707 09: x86: Adjust link device tree include file
708 10: x86: Enable CONFIG_OF_CONTROL on coreboot
711 You can see that image size only changed on x86, which is good because this
712 series is not supposed to change any other board. From commit 7 onwards the
713 build fails so we don't get code size numbers. The numbers are fractional
714 because they are an average of all boards for that architecture. The
715 intention is to allow you to quickly find image size problems introduced by
718 Note that the 'text' region and 'rodata' are split out. You should add the
719 two together to get the total read-only size (reported as the first column
720 in the output from binutil's 'size' utility).
722 A useful option is --step which lets you skip some commits. For example
723 --step 2 will show the image sizes for only every 2nd commit (so it will
724 compare the image sizes of the 1st, 3rd, 5th... commits). You can also use
725 --step 0 which will compare only the first and last commits. This is useful
726 for an overview of how your entire series affects code size. It will build
727 only the upstream commit and your final branch commit.
729 You can also use -d to see a detailed size breakdown for each board. This
730 list is sorted in order from largest growth to largest reduction.
732 It is even possible to go a little further with the -B option (--bloat). This
733 shows where U-Boot has bloated, breaking the size change down to the function
734 level. Example output is below:
736 $ ./tools/buildman/buildman -b us-mem4 -sSdB
738 19: Roll crc32 into hash infrastructure
739 arm: (for 10/10 boards) all -143.4 bss +1.2 data -4.8 rodata -48.2 text -91.6
740 paz00 : all +23 bss -4 rodata -29 text +56
741 u-boot: add: 1/0, grow: 3/-2 bytes: 168/-104 (64)
742 function old new delta
743 hash_command 80 160 +80
744 crc32_wd_buf - 56 +56
745 ext4fs_read_file 540 568 +28
746 insert_var_value_sub 688 692 +4
747 run_list_real 1996 1992 -4
748 do_mem_crc 168 68 -100
749 trimslice : all -9 bss +16 rodata -29 text +4
750 u-boot: add: 1/0, grow: 1/-3 bytes: 136/-124 (12)
751 function old new delta
752 hash_command 80 160 +80
753 crc32_wd_buf - 56 +56
754 ext4fs_iterate_dir 672 668 -4
755 ext4fs_read_file 568 548 -20
756 do_mem_crc 168 68 -100
757 whistler : all -9 bss +16 rodata -29 text +4
758 u-boot: add: 1/0, grow: 1/-3 bytes: 136/-124 (12)
759 function old new delta
760 hash_command 80 160 +80
761 crc32_wd_buf - 56 +56
762 ext4fs_iterate_dir 672 668 -4
763 ext4fs_read_file 568 548 -20
764 do_mem_crc 168 68 -100
765 seaboard : all -9 bss -28 rodata -29 text +48
766 u-boot: add: 1/0, grow: 3/-2 bytes: 160/-104 (56)
767 function old new delta
768 hash_command 80 160 +80
769 crc32_wd_buf - 56 +56
770 ext4fs_read_file 548 568 +20
771 run_list_real 1996 2000 +4
772 do_nandboot 760 756 -4
773 do_mem_crc 168 68 -100
774 colibri_t20 : all -9 rodata -29 text +20
775 u-boot: add: 1/0, grow: 2/-3 bytes: 140/-112 (28)
776 function old new delta
777 hash_command 80 160 +80
778 crc32_wd_buf - 56 +56
779 read_abs_bbt 204 208 +4
780 do_nandboot 760 756 -4
781 ext4fs_read_file 576 568 -8
782 do_mem_crc 168 68 -100
783 ventana : all -37 bss -12 rodata -29 text +4
784 u-boot: add: 1/0, grow: 1/-3 bytes: 136/-124 (12)
785 function old new delta
786 hash_command 80 160 +80
787 crc32_wd_buf - 56 +56
788 ext4fs_iterate_dir 672 668 -4
789 ext4fs_read_file 568 548 -20
790 do_mem_crc 168 68 -100
791 harmony : all -37 bss -16 rodata -29 text +8
792 u-boot: add: 1/0, grow: 2/-3 bytes: 140/-124 (16)
793 function old new delta
794 hash_command 80 160 +80
795 crc32_wd_buf - 56 +56
796 nand_write_oob_syndrome 428 432 +4
797 ext4fs_iterate_dir 672 668 -4
798 ext4fs_read_file 568 548 -20
799 do_mem_crc 168 68 -100
800 medcom-wide : all -417 bss +28 data -16 rodata -93 text -336
801 u-boot: add: 1/-1, grow: 1/-2 bytes: 88/-376 (-288)
802 function old new delta
803 crc32_wd_buf - 56 +56
804 do_fat_read_at 2872 2904 +32
806 do_mem_crc 168 68 -100
807 hash_command 420 160 -260
808 tec : all -449 bss -4 data -16 rodata -93 text -336
809 u-boot: add: 1/-1, grow: 1/-2 bytes: 88/-376 (-288)
810 function old new delta
811 crc32_wd_buf - 56 +56
812 do_fat_read_at 2872 2904 +32
814 do_mem_crc 168 68 -100
815 hash_command 420 160 -260
816 plutux : all -481 bss +16 data -16 rodata -93 text -388
817 u-boot: add: 1/-1, grow: 1/-3 bytes: 68/-408 (-340)
818 function old new delta
819 crc32_wd_buf - 56 +56
820 do_load_serial_bin 1688 1700 +12
822 do_fat_read_at 2904 2872 -32
823 do_mem_crc 168 68 -100
824 hash_command 420 160 -260
825 powerpc: (for 5/5 boards) all +37.4 data -3.2 rodata -41.8 text +82.4
826 MPC8610HPCD : all +55 rodata -29 text +84
827 u-boot: add: 1/0, grow: 0/-1 bytes: 176/-96 (80)
828 function old new delta
829 hash_command - 176 +176
830 do_mem_crc 184 88 -96
831 MPC8641HPCN : all +55 rodata -29 text +84
832 u-boot: add: 1/0, grow: 0/-1 bytes: 176/-96 (80)
833 function old new delta
834 hash_command - 176 +176
835 do_mem_crc 184 88 -96
836 MPC8641HPCN_36BIT: all +55 rodata -29 text +84
837 u-boot: add: 1/0, grow: 0/-1 bytes: 176/-96 (80)
838 function old new delta
839 hash_command - 176 +176
840 do_mem_crc 184 88 -96
841 sbc8641d : all +55 rodata -29 text +84
842 u-boot: add: 1/0, grow: 0/-1 bytes: 176/-96 (80)
843 function old new delta
844 hash_command - 176 +176
845 do_mem_crc 184 88 -96
846 xpedite517x : all -33 data -16 rodata -93 text +76
847 u-boot: add: 1/-1, grow: 0/-1 bytes: 176/-112 (64)
848 function old new delta
849 hash_command - 176 +176
851 do_mem_crc 184 88 -96
855 This shows that commit 19 has reduced codesize for arm slightly and increased
856 it for powerpc. This increase was offset in by reductions in rodata and
859 Shown below the summary lines are the sizes for each board. Below each board
860 are the sizes for each function. This information starts with:
862 add - number of functions added / removed
863 grow - number of functions which grew / shrunk
864 bytes - number of bytes of code added to / removed from all functions,
865 plus the total byte change in brackets
867 The change seems to be that hash_command() has increased by more than the
868 do_mem_crc() function has decreased. The function sizes typically add up to
869 roughly the text area size, but note that every read-only section except
870 rodata is included in 'text', so the function total does not exactly
873 It is common when refactoring code for the rodata to decrease as the text size
874 increases, and vice versa.
880 The .buildman file provides information about the available toolchains and
881 also allows build flags to be passed to 'make'. It consists of several
882 sections, with the section name in square brackets. Within each section are
883 a set of (tag, value) pairs.
885 '[toolchain]' section
887 This lists the available toolchains. The tag here doesn't matter, but
888 make sure it is unique. The value is the path to the toolchain. Buildman
889 will look in that path for a file ending in 'gcc'. It will then execute
890 it to check that it is a C compiler, passing only the --version flag to
891 it. If the return code is 0, buildman assumes that it is a valid C
892 compiler. It uses the first part of the name as the architecture and
893 strips off the last part when setting the CROSS_COMPILE environment
894 variable (parts are delimited with a hyphen).
896 For example powerpc-linux-gcc will be noted as a toolchain for 'powerpc'
897 and CROSS_COMPILE will be set to powerpc-linux- when using it.
899 '[toolchain-alias]' section
901 This converts toolchain architecture names to U-Boot names. For example,
902 if an x86 toolchains is called i386-linux-gcc it will not normally be
903 used for architecture 'x86'. Adding 'x86: i386 x86_64' to this section
904 will tell buildman that the i386 and x86_64 toolchains can be used for
905 the x86 architecture.
907 '[make-flags]' section
909 U-Boot's build system supports a few flags (such as BUILD_TAG) which
910 affect the build product. These flags can be specified in the buildman
911 settings file. They can also be useful when building U-Boot against other
912 open source software.
915 at91-boards=ENABLE_AT91_TEST=1
916 snapper9260=${at91-boards} BUILD_TAG=442
917 snapper9g45=${at91-boards} BUILD_TAG=443
919 This will use 'make ENABLE_AT91_TEST=1 BUILD_TAG=442' for snapper9260
920 and 'make ENABLE_AT91_TEST=1 BUILD_TAG=443' for snapper9g45. A special
921 variable ${target} is available to access the target name (snapper9260
922 and snapper9g20 in this case). Variables are resolved recursively. Note
923 that variables can only contain the characters A-Z, a-z, 0-9, hyphen (-)
926 It is expected that any variables added are dealt with in U-Boot's
927 config.mk file and documented in the README.
929 Note that you can pass ad-hoc options to the build using environment
930 variables, for example:
932 SOME_OPTION=1234 ./tools/buildman/buildman my_board
938 If you have made changes and want to do a quick sanity check of the
939 currently checked-out source, run buildman without the -b flag. This will
940 build the selected boards and display build status as it runs (i.e. -v is
941 enabled automatically). Use -e to see errors/warnings as well.
947 You can build a range of commits by specifying a range instead of a branch
948 when using the -b flag. For example:
950 upstream/master..us-buildman
952 will build commits in us-buildman that are not in upstream/master.
958 By default, buildman doesn't execute 'make mrproper' prior to building the
959 first commit for each board. This reduces the amount of work 'make' does, and
960 hence speeds up the build. To force use of 'make mrproper', use -the -m flag.
961 This flag will slow down any buildman invocation, since it increases the amount
962 of work done on any build.
964 One possible application of buildman is as part of a continual edit, build,
965 edit, build, ... cycle; repeatedly applying buildman to the same change or
966 series of changes while making small incremental modifications to the source
967 each time. This provides quick feedback regarding the correctness of recent
968 modifications. In this scenario, buildman's default choice of build directory
969 causes more build work to be performed than strictly necessary.
971 By default, each buildman thread uses a single directory for all builds. When a
972 thread builds multiple boards, the configuration built in this directory will
973 cycle through various different configurations, one per board built by the
974 thread. Variations in the configuration will force a rebuild of affected source
975 files when a thread switches between boards. Ideally, such buildman-induced
976 rebuilds would not happen, thus allowing the build to operate as efficiently as
977 the build system and source changes allow. buildman's -P flag may be used to
978 enable this; -P causes each board to be built in a separate (board-specific)
979 directory, thus avoiding any buildman-induced configuration changes in any
982 U-Boot's build system embeds information such as a build timestamp into the
983 final binary. This information varies each time U-Boot is built. This causes
984 various files to be rebuilt even if no source changes are made, which in turn
985 requires that the final U-Boot binary be re-linked. This unnecessary work can
986 be avoided by turning off the timestamp feature. This can be achieved by
987 setting the SOURCE_DATE_EPOCH environment variable to 0.
989 Combining all of these options together yields the command-line shown below.
990 This will provide the quickest possible feedback regarding the current content
991 of the source tree, thus allowing rapid tested evolution of the code.
993 SOURCE_DATE_EPOCH=0 ./tools/buildman/buildman -P tegra
996 Checking configuration
997 ======================
999 A common requirement when converting CONFIG options to Kconfig is to check
1000 that the effective configuration has not changed due to the conversion.
1001 Buildman supports this with the -K option, used after a build. This shows
1002 differences in effective configuration between one commit and the next.
1006 $ buildman -b kc4 -sK
1008 43: Convert CONFIG_SPL_USBETH_SUPPORT to Kconfig
1010 + u-boot.cfg: CONFIG_SPL_ENV_SUPPORT=1 CONFIG_SPL_NET=1
1011 + u-boot-spl.cfg: CONFIG_SPL_MMC=1 CONFIG_SPL_NAND_SUPPORT=1
1012 + all: CONFIG_SPL_ENV_SUPPORT=1 CONFIG_SPL_MMC=1 CONFIG_SPL_NAND_SUPPORT=1 CONFIG_SPL_NET=1
1014 + u-boot.cfg: CONFIG_SPL_ENV_SUPPORT=1 CONFIG_SPL_NET=1
1015 + u-boot-spl.cfg: CONFIG_SPL_MMC=1 CONFIG_SPL_NAND_SUPPORT=1
1016 + all: CONFIG_SPL_ENV_SUPPORT=1 CONFIG_SPL_MMC=1 CONFIG_SPL_NAND_SUPPORT=1 CONFIG_SPL_NET=1
1017 44: Convert CONFIG_SPL_USB_HOST to Kconfig
1020 This shows that commit 44 enabled three new options for the board
1021 am335x_evm_usbspl which were not enabled in commit 43. There is also a
1022 summary for 'arm' showing all the changes detected for that architecture.
1023 In this case there is only one board with changes, so 'arm' output is the
1024 same as 'am335x_evm_usbspl'/
1026 The -K option uses the u-boot.cfg, spl/u-boot-spl.cfg and tpl/u-boot-tpl.cfg
1027 files which are produced by a build. If all you want is to check the
1028 configuration you can in fact avoid doing a full build, using -D. This tells
1029 buildman to configuration U-Boot and create the .cfg files, but not actually
1030 build the source. This is 5-10 times faster than doing a full build.
1032 By default buildman considers the follow two configuration methods
1035 #define CONFIG_SOME_OPTION
1037 CONFIG_SOME_OPTION=y
1039 The former would appear in a header filer and the latter in a defconfig
1040 file. The achieve this, buildman considers 'y' to be '1' in configuration
1041 variables. This avoids lots of useless output when converting a CONFIG
1042 option to Kconfig. To disable this behaviour, use --squash-config-y.
1045 Checking the environment
1046 ========================
1048 When converting CONFIG options which manipulate the default environment,
1049 a common requirement is to check that the default environment has not
1050 changed due to the conversion. Buildman supports this with the -U option,
1051 used after a build. This shows differences in the default environment
1052 between one commit and the next.
1056 $ buildman -b squash brppt1 -sU
1057 Summary of 2 commits for 3 boards (3 threads, 3 jobs per thread)
1058 01: Migrate bootlimit to Kconfig
1059 02: Squashed commit of the following:
1060 c brppt1_mmc: altbootcmd=mmc dev 1; run mmcboot0; -> mmc dev 1; run mmcboot0
1061 c brppt1_spi: altbootcmd=mmc dev 1; run mmcboot0; -> mmc dev 1; run mmcboot0
1062 + brppt1_nand: altbootcmd=run usbscript
1063 - brppt1_nand: altbootcmd=run usbscript
1064 (no errors to report)
1066 This shows that commit 2 modified the value of 'altbootcmd' for 'brppt1_mmc'
1067 and 'brppt1_spi', removing a trailing semicolon. 'brppt1_nand' gained an a
1068 value for 'altbootcmd', but lost one for ' altbootcmd'.
1070 The -U option uses the u-boot.env files which are produced by a build.
1076 To build with clang (sandbox only), use the -O option to override the
1077 toolchain. For example:
1079 buildman -O clang-7 --board sandbox
1082 Doing a simple build
1083 ====================
1085 In some cases you just want to build a single board and get the full output, use
1086 the -w option, for example:
1088 buildman -o /tmp/build --board sandbox -w
1090 This will write the full build into /tmp/build including object files. You must
1091 specify the output directory with -o when using -w.
1094 Support for IDEs (Integrated Development Environments)
1095 ======================================================
1097 Normally buildman summarises the output and shows information indicating the
1098 meaning of each line of output. For example a '+' symbol appears at the start of
1099 each error line. Also, buildman prints information about what it is about to do,
1100 along with a summary at the end.
1102 When using buildman from an IDE, it is helpful to drop this behaviour. Use the
1103 -I/--ide option for that. You might find -W helpful also so that warnings do
1104 not cause the build to fail:
1106 buildman -o /tmp/build --board sandbox -wWI
1109 Changing the configuration
1110 ==========================
1112 Sometimes it is useful to change the CONFIG options for a build on the fly. This
1113 can be used to build a board (or multiple) with a few changes to see the impact.
1114 The -a option supports this:
1118 where <cfg> is a CONFIG option (with or without the CONFIG_ prefix) to enable.
1121 buildman -a CMD_SETEXPR_FMT
1123 will build with CONFIG_CMD_SETEXPR_FMT enabled.
1125 You can disable options by preceding them with tilde (~). You can specify the
1126 -a option multiple times:
1128 buildman -a CMD_SETEXPR_FMT -a ~CMDLINE
1130 Some options have values, in which case you can change them:
1132 buildman -a 'BOOTCOMMAND="echo hello"' CONFIG_SYS_LOAD_ADDR=0x1000
1134 Note that you must put quotes around string options and the whole thing must be
1135 in single quotes, to make sure the shell leave it alone.
1137 If you try to set an option that does not exist, or that cannot be changed for
1138 some other reason (e.g. it is 'selected' by another option), then buildman
1141 buildman --board sandbox -a FRED
1142 Building current source for 1 boards (1 thread, 32 jobs per thread)
1143 0 0 0 /1 -1 (starting)errs
1144 Some CONFIG adjustments did not take effect. This may be because
1145 the request CONFIGs do not exist or conflict with others.
1149 FRED Missing expected line: CONFIG_FRED=y
1152 One major caveat with this feature with branches (-b) is that buildman does not
1153 name the output directories differently when you change the configuration, so
1154 doing the same build again with different configuration will not trigger a
1155 rebuild. You can use -f to work around that.
1161 Buildman has various other command-line options. Try --help to see them.
1163 To find out what toolchain prefix buildman will use for a build, use the -A
1166 To request that compiler warnings be promoted to errors, use -E. This passes the
1167 -Werror flag to the compiler. Note that the build can still produce warnings
1168 with -E, e.g. the migration warnings:
1170 ===================== WARNING ======================
1171 This board does not use CONFIG_DM_MMC. Please update
1173 ====================================================
1175 When doing builds, Buildman's return code will reflect the overall result:
1177 0 (success) No errors or warnings found
1179 101 Warnings found (only if no -W)
1181 You can use -W to tell Buildman to return 0 (success) instead of 101 when
1182 warnings are found. Note that it can be useful to combine -E and -W. This means
1183 that all compiler warnings will produce failures (code 100) and all other
1184 warnings will produce success (since 101 is changed to 0).
1186 If there are both warnings and errors, errors win, so buildman returns 100.
1188 The -y option is provided (for use with -s) to ignore the bountiful device-tree
1189 warnings. Similarly, -Y tells buildman to ignore the migration warnings.
1191 Sometimes you might get an error in a thread that is not handled by buildman,
1192 perhaps due to a failure of a tool that it calls. You might see the output, but
1193 then buildman hangs. Failing to handle any eventuality is a bug in buildman and
1194 should be reported. But you can use -T0 to disable threading and hopefully
1195 figure out the root cause of the build failure.
1200 When buildman finishes it shows a summary, something like this:
1202 Completed: 5 total built, duration 0:00:21, rate 0.24
1204 This shows that a total of 5 builds were done across all selected boards, it
1205 took 21 seconds and the builds happened at the rate of 0.24 per second. The
1206 latter number depends on the speed of your machine and the efficiency of the
1210 How to change from MAKEALL
1211 ==========================
1213 Buildman includes most of the features of MAKEALL and is generally faster
1214 and easier to use. In particular it builds entire branches: if a particular
1215 commit introduces an error in a particular board, buildman can easily show
1216 you this, even if a later commit fixes that error.
1218 The reasons to deprecate MAKEALL are:
1219 - We don't want to maintain two build systems
1220 - Buildman is typically faster
1221 - Buildman has a lot more features
1223 But still, many people will be sad to lose MAKEALL. If you are used to
1224 MAKEALL, here are a few pointers.
1226 First you need to set up your tool chains - see the 'Setting up' section
1227 for details. Once you have your required toolchain(s) detected then you are
1230 To build the current source tree, run buildman without a -b flag:
1232 ./tools/buildman/buildman <list of things to build>
1234 This will build the current source tree for the given boards and display
1235 the results and errors.
1237 However buildman usually works on entire branches, and for that you must
1238 specify a board flag:
1240 ./tools/buildman/buildman -b <branch_name> <list of things to build>
1242 followed by (afterwards, or perhaps concurrently in another terminal):
1244 ./tools/buildman/buildman -b <branch_name> -s <list of things to build>
1246 to see the results of the build. Rather than showing you all the output,
1247 buildman just shows a summary, with red indicating that a commit introduced
1248 an error and green indicating that a commit fixed an error. Use the -e
1249 flag to see the full errors and -l to see which boards caused which errors.
1251 If you really want to see build results as they happen, use -v when doing a
1252 build (and -e to see the errors/warnings too).
1254 You don't need to stick around on that branch while buildman is running. It
1255 checks out its own copy of the source code, so you can change branches,
1256 add commits, etc. without affecting the build in progress.
1258 The <list of things to build> can include board names, architectures or the
1259 like. There are no flags to disambiguate since ambiguities are rare. Using
1260 the examples from MAKEALL:
1263 - build all Power Architecture boards:
1265 MAKEALL --arch powerpc
1267 ** buildman -b <branch> powerpc
1268 - build all PowerPC boards manufactured by vendor "esd":
1269 MAKEALL -a powerpc -v esd
1270 ** buildman -b <branch> esd
1271 - build all PowerPC boards manufactured either by "keymile" or "siemens":
1272 MAKEALL -a powerpc -v keymile -v siemens
1273 ** buildman -b <branch> keymile siemens
1274 - build all Freescale boards with MPC83xx CPUs, plus all 4xx boards:
1275 MAKEALL -c mpc83xx -v freescale 4xx
1276 ** buildman -b <branch> mpc83xx freescale 4xx
1278 Buildman automatically tries to use all the CPUs in your machine. If you
1279 are building a lot of boards it will use one thread for every CPU core
1280 it detects in your machine. This is like MAKEALL's BUILD_NBUILDS option.
1281 You can use the -T flag to change the number of threads. If you are only
1282 building a few boards, buildman will automatically run make with the -j
1283 flag to increase the number of concurrent make tasks. It isn't normally
1284 that helpful to fiddle with this option, but if you use the BUILD_NCPUS
1285 option in MAKEALL then -j is the equivalent in buildman.
1287 Buildman puts its output in ../<branch_name> by default but you can change
1288 this with the -o option. Buildman normally does out-of-tree builds: use -i
1289 to disable that if you really want to. But be careful that once you have
1290 used -i you pollute buildman's copies of the source tree, and you will need
1291 to remove the build directory (normally ../<branch_name>) to run buildman
1292 in normal mode (without -i).
1294 Buildman doesn't keep the output result normally, but use the -k option to
1297 Please read 'Theory of Operation' a few times as it will make a lot of
1300 Some options you might like are:
1302 -B shows which functions are growing/shrinking in which commit - great
1303 for finding code bloat.
1304 -S shows image sizes for each commit (just an overall summary)
1305 -u shows boards that you haven't built yet
1306 --step 0 will build just the upstream commit and the last commit of your
1307 branch. This is often a quick sanity check that your branch doesn't
1308 break anything. But note this does not check bisectability!
1314 This file is no-longer needed by buildman but it is still generated in the
1315 working directory. This helps avoid a delay on every build, since scanning all
1316 the Kconfig files takes a few seconds. Use the -R flag to force regeneration
1317 of the file - in that case buildman exits after writing the file.
1319 You should use 'buildman -nv <criteria>' instead of greoing the boards.cfg file,
1320 since it may be dropped altogether in future.
1326 Many improvements have been made over the years. There is still quite a bit of
1327 scope for more though, e.g.:
1329 - easier access to log files
1330 - 'hunting' for problems, perhaps by building a few boards for each arch, or
1331 checking commits for changed files and building only boards which use those
1333 - using the same git repo for all threads instead of cloning it. Currently
1334 it uses about 500MB per thread, so on a 64-thread machine this is 32GB for
1341 Thanks to Grant Grundler <grundler@chromium.org> for his ideas for improving
1342 the build speed by building all commits for a board instead of the other
projects / platform / kernel / u-boot.git / blob