1# Copyright (c) 2013 The Chromium OS Authors. 2# 3# SPDX-License-Identifier: GPL-2.0+ 4# 5 6What is this? 7============= 8 9This tool handles building U-Boot to check that you have not broken it 10with your patch series. It can build each individual commit and report 11which boards fail on which commits, and which errors come up. It aims 12to make full use of multi-processor machines. 13 14A key feature of buildman is its output summary, which allows warnings, 15errors or image size increases in a particular commit or board to be 16quickly identified and the offending commit pinpointed. This can be a big 17help for anyone working with >10 patches at a time. 18 19 20Caveats 21======= 22 23Buildman is still in its infancy. It is already a very useful tool, but 24expect to find problems and send patches. 25 26Buildman can be stopped and restarted, in which case it will continue 27where it left off. This should happen cleanly and without side-effects. 28If not, it is a bug, for which a patch would be welcome. 29 30Buildman gets so tied up in its work that it can ignore the outside world. 31You may need to press Ctrl-C several times to quit it. Also it will print 32out various exceptions when stopped. 33 34 35Theory of Operation 36=================== 37 38(please read this section in full twice or you will be perpetually confused) 39 40Buildman is a builder. It is not make, although it runs make. It does not 41produce any useful output on the terminal while building, except for 42progress information. All the output (errors, warnings and binaries if you 43are ask for them) is stored in output directories, which you can look at 44while the build is progressing, or when it is finished. 45 46Buildman produces a concise summary of which boards succeeded and failed. 47It shows which commit introduced which board failure using a simple 48red/green colour coding. Full error information can be requested, in which 49case it is de-duped and displayed against the commit that introduced the 50error. An example workflow is below. 51 52Buildman stores image size information and can report changes in image size 53from commit to commit. An example of this is below. 54 55Buildman starts multiple threads, and each thread builds for one board at 56a time. A thread starts at the first commit, configures the source for your 57board and builds it. Then it checks out the next commit and does an 58incremental build. Eventually the thread reaches the last commit and stops. 59If errors or warnings are found along the way, the thread will reconfigure 60after every commit, and your build will be very slow. This is because a 61file that produces just a warning would not normally be rebuilt in an 62incremental build. 63 64Buildman works in an entirely separate place from your U-Boot repository. 65It creates a separate working directory for each thread, and puts the 66output files in the working directory, organised by commit name and board 67name, in a two-level hierarchy. 68 69Buildman is invoked in your U-Boot directory, the one with the .git 70directory. It clones this repository into a copy for each thread, and the 71threads do not affect the state of your git repository. Any checkouts done 72by the thread affect only the working directory for that thread. 73 74Buildman automatically selects the correct toolchain for each board. You 75must supply suitable toolchains, but buildman takes care of selecting the 76right one. 77 78Buildman always builds a branch, and always builds the upstream commit as 79well, for comparison. It cannot build individual commits at present, unless 80(maybe) you point it at an empty branch. Put all your commits in a branch, 81set the branch's upstream to a valid value, and all will be well. Otherwise 82buildman will perform random actions. Use -n to check what the random 83actions might be. 84 85Buildman is optimised for building many commits at once, for many boards. 86On multi-core machines, Buildman is fast because it uses most of the 87available CPU power. When it gets to the end, or if you are building just 88a few commits or boards, it will be pretty slow. As a tip, if you don't 89plan to use your machine for anything else, you can use -T to increase the 90number of threads beyond the default. 91 92Buildman lets you build all boards, or a subset. Specify the subset using 93the board name, architecture name, SOC name, or anything else in the 94boards.cfg file. So 'at91' will build all AT91 boards (arm), powerpc will 95build all PowerPC boards. 96 97Buildman does not store intermediate object files. It optionally copies 98the binary output into a directory when a build is successful. Size 99information is always recorded. It needs a fair bit of disk space to work, 100typically 250MB per thread. 101 102 103Setting up 104========== 105 1061. Get the U-Boot source. You probably already have it, but if not these 107steps should get you started with a repo and some commits for testing. 108 109$ cd /path/to/u-boot 110$ git clone git://git.denx.de/u-boot.git . 111$ git checkout -b my-branch origin/master 112$ # Add some commits to the branch, reading for testing 113 1142. Create ~/.buildman to tell buildman where to find tool chains. As an 115example: 116 117# Buildman settings file 118 119[toolchain] 120root: / 121rest: /toolchains/* 122eldk: /opt/eldk-4.2 123 124[toolchain-alias] 125x86: i386 126blackfin: bfin 127sh: sh4 128nds32: nds32le 129openrisc: or32 130 131 132This selects the available toolchain paths. Add the base directory for 133each of your toolchains here. Buildman will search inside these directories 134and also in any '/usr' and '/usr/bin' subdirectories. 135 136Make sure the tags (here root: rest: and eldk:) are unique. 137 138The toolchain-alias section indicates that the i386 toolchain should be used 139to build x86 commits. 140 141 1422. Check the available toolchains 143 144Run this check to make sure that you have a toolchain for every architecture. 145 146$ ./tools/buildman/buildman --list-tool-chains 147Scanning for tool chains 148 - scanning path '/' 149 - looking in '/.' 150 - looking in '/bin' 151 - looking in '/usr/bin' 152 - found '/usr/bin/gcc' 153Tool chain test: OK 154 - found '/usr/bin/c89-gcc' 155Tool chain test: OK 156 - found '/usr/bin/c99-gcc' 157Tool chain test: OK 158 - found '/usr/bin/x86_64-linux-gnu-gcc' 159Tool chain test: OK 160 - scanning path '/toolchains/powerpc-linux' 161 - looking in '/toolchains/powerpc-linux/.' 162 - looking in '/toolchains/powerpc-linux/bin' 163 - found '/toolchains/powerpc-linux/bin/powerpc-linux-gcc' 164Tool chain test: OK 165 - looking in '/toolchains/powerpc-linux/usr/bin' 166 - scanning path '/toolchains/nds32le-linux-glibc-v1f' 167 - looking in '/toolchains/nds32le-linux-glibc-v1f/.' 168 - looking in '/toolchains/nds32le-linux-glibc-v1f/bin' 169 - found '/toolchains/nds32le-linux-glibc-v1f/bin/nds32le-linux-gcc' 170Tool chain test: OK 171 - looking in '/toolchains/nds32le-linux-glibc-v1f/usr/bin' 172 - scanning path '/toolchains/nios2' 173 - looking in '/toolchains/nios2/.' 174 - looking in '/toolchains/nios2/bin' 175 - found '/toolchains/nios2/bin/nios2-linux-gcc' 176Tool chain test: OK 177 - found '/toolchains/nios2/bin/nios2-linux-uclibc-gcc' 178Tool chain test: OK 179 - looking in '/toolchains/nios2/usr/bin' 180 - found '/toolchains/nios2/usr/bin/nios2-linux-gcc' 181Tool chain test: OK 182 - found '/toolchains/nios2/usr/bin/nios2-linux-uclibc-gcc' 183Tool chain test: OK 184 - scanning path '/toolchains/microblaze-unknown-linux-gnu' 185 - looking in '/toolchains/microblaze-unknown-linux-gnu/.' 186 - looking in '/toolchains/microblaze-unknown-linux-gnu/bin' 187 - found '/toolchains/microblaze-unknown-linux-gnu/bin/microblaze-unknown-linux-gnu-gcc' 188Tool chain test: OK 189 - found '/toolchains/microblaze-unknown-linux-gnu/bin/mb-linux-gcc' 190Tool chain test: OK 191 - looking in '/toolchains/microblaze-unknown-linux-gnu/usr/bin' 192 - scanning path '/toolchains/mips-linux' 193 - looking in '/toolchains/mips-linux/.' 194 - looking in '/toolchains/mips-linux/bin' 195 - found '/toolchains/mips-linux/bin/mips-linux-gcc' 196Tool chain test: OK 197 - looking in '/toolchains/mips-linux/usr/bin' 198 - scanning path '/toolchains/old' 199 - looking in '/toolchains/old/.' 200 - looking in '/toolchains/old/bin' 201 - looking in '/toolchains/old/usr/bin' 202 - scanning path '/toolchains/i386-linux' 203 - looking in '/toolchains/i386-linux/.' 204 - looking in '/toolchains/i386-linux/bin' 205 - found '/toolchains/i386-linux/bin/i386-linux-gcc' 206Tool chain test: OK 207 - looking in '/toolchains/i386-linux/usr/bin' 208 - scanning path '/toolchains/bfin-uclinux' 209 - looking in '/toolchains/bfin-uclinux/.' 210 - looking in '/toolchains/bfin-uclinux/bin' 211 - found '/toolchains/bfin-uclinux/bin/bfin-uclinux-gcc' 212Tool chain test: OK 213 - looking in '/toolchains/bfin-uclinux/usr/bin' 214 - scanning path '/toolchains/sparc-elf' 215 - looking in '/toolchains/sparc-elf/.' 216 - looking in '/toolchains/sparc-elf/bin' 217 - found '/toolchains/sparc-elf/bin/sparc-elf-gcc' 218Tool chain test: OK 219 - looking in '/toolchains/sparc-elf/usr/bin' 220 - scanning path '/toolchains/arm-2010q1' 221 - looking in '/toolchains/arm-2010q1/.' 222 - looking in '/toolchains/arm-2010q1/bin' 223 - found '/toolchains/arm-2010q1/bin/arm-none-linux-gnueabi-gcc' 224Tool chain test: OK 225 - looking in '/toolchains/arm-2010q1/usr/bin' 226 - scanning path '/toolchains/from' 227 - looking in '/toolchains/from/.' 228 - looking in '/toolchains/from/bin' 229 - looking in '/toolchains/from/usr/bin' 230 - scanning path '/toolchains/sh4-gentoo-linux-gnu' 231 - looking in '/toolchains/sh4-gentoo-linux-gnu/.' 232 - looking in '/toolchains/sh4-gentoo-linux-gnu/bin' 233 - found '/toolchains/sh4-gentoo-linux-gnu/bin/sh4-gentoo-linux-gnu-gcc' 234Tool chain test: OK 235 - looking in '/toolchains/sh4-gentoo-linux-gnu/usr/bin' 236 - scanning path '/toolchains/avr32-linux' 237 - looking in '/toolchains/avr32-linux/.' 238 - looking in '/toolchains/avr32-linux/bin' 239 - found '/toolchains/avr32-linux/bin/avr32-gcc' 240Tool chain test: OK 241 - looking in '/toolchains/avr32-linux/usr/bin' 242 - scanning path '/toolchains/m68k-linux' 243 - looking in '/toolchains/m68k-linux/.' 244 - looking in '/toolchains/m68k-linux/bin' 245 - found '/toolchains/m68k-linux/bin/m68k-linux-gcc' 246Tool chain test: OK 247 - looking in '/toolchains/m68k-linux/usr/bin' 248List of available toolchains (17): 249arm : /toolchains/arm-2010q1/bin/arm-none-linux-gnueabi-gcc 250avr32 : /toolchains/avr32-linux/bin/avr32-gcc 251bfin : /toolchains/bfin-uclinux/bin/bfin-uclinux-gcc 252c89 : /usr/bin/c89-gcc 253c99 : /usr/bin/c99-gcc 254i386 : /toolchains/i386-linux/bin/i386-linux-gcc 255m68k : /toolchains/m68k-linux/bin/m68k-linux-gcc 256mb : /toolchains/microblaze-unknown-linux-gnu/bin/mb-linux-gcc 257microblaze: /toolchains/microblaze-unknown-linux-gnu/bin/microblaze-unknown-linux-gnu-gcc 258mips : /toolchains/mips-linux/bin/mips-linux-gcc 259nds32le : /toolchains/nds32le-linux-glibc-v1f/bin/nds32le-linux-gcc 260nios2 : /toolchains/nios2/bin/nios2-linux-gcc 261powerpc : /toolchains/powerpc-linux/bin/powerpc-linux-gcc 262sandbox : /usr/bin/gcc 263sh4 : /toolchains/sh4-gentoo-linux-gnu/bin/sh4-gentoo-linux-gnu-gcc 264sparc : /toolchains/sparc-elf/bin/sparc-elf-gcc 265x86_64 : /usr/bin/x86_64-linux-gnu-gcc 266 267 268You can see that everything is covered, even some strange ones that won't 269be used (c88 and c99). This is a feature. 270 271 272How to run it 273============= 274 275First do a dry run using the -n flag: (replace <branch> with a real, local 276branch with a valid upstream) 277 278$ ./tools/buildman/buildman -b <branch> -n 279 280If it can't detect the upstream branch, try checking out the branch, and 281doing something like 'git branch --set-upstream <branch> upstream/master' 282or something similar. 283 284As an exmmple: 285 286Dry run, so not doing much. But I would do this: 287 288Building 18 commits for 1059 boards (4 threads, 1 job per thread) 289Build directory: ../lcd9b 290 5bb3505 Merge branch 'master' of git://git.denx.de/u-boot-arm 291 c18f1b4 tegra: Use const for pinmux_config_pingroup/table() 292 2f043ae tegra: Add display support to funcmux 293 e349900 tegra: fdt: Add pwm binding and node 294 424a5f0 tegra: fdt: Add LCD definitions for Tegra 295 0636ccf tegra: Add support for PWM 296 a994fe7 tegra: Add SOC support for display/lcd 297 fcd7350 tegra: Add LCD driver 298 4d46e9d tegra: Add LCD support to Nvidia boards 299 991bd48 arm: Add control over cachability of memory regions 300 54e8019 lcd: Add CONFIG_LCD_ALIGNMENT to select frame buffer alignment 301 d92aff7 lcd: Add support for flushing LCD fb from dcache after update 302 dbd0677 tegra: Align LCD frame buffer to section boundary 303 0cff9b8 tegra: Support control of cache settings for LCD 304 9c56900 tegra: fdt: Add LCD definitions for Seaboard 305 5cc29db lcd: Add CONFIG_CONSOLE_SCROLL_LINES option to speed console 306 cac5a23 tegra: Enable display/lcd support on Seaboard 307 49ff541 wip 308 309Total boards to build for each commit: 1059 310 311This shows that it will build all 1059 boards, using 4 threads (because 312we have a 4-core CPU). Each thread will run with -j1, meaning that each 313make job will use a single CPU. The list of commits to be built helps you 314confirm that things look about right. Notice that buildman has chosen a 315'base' directory for you, immediately above your source tree. 316 317Buildman works entirely inside the base directory, here ../lcd9b, 318creating a working directory for each thread, and creating output 319directories for each commit and board. 320 321 322Suggested Workflow 323================== 324 325To run the build for real, take off the -n: 326 327$ ./tools/buildman/buildman -b <branch> 328 329Buildman will set up some working directories, and get started. After a 330minute or so it will settle down to a steady pace, with a display like this: 331 332Building 18 commits for 1059 boards (4 threads, 1 job per thread) 333 528 36 124 /19062 1:13:30 : SIMPC8313_SP 334 335This means that it is building 19062 board/commit combinations. So far it 336has managed to succesfully build 528. Another 36 have built with warnings, 337and 124 more didn't build at all. Buildman expects to complete the process 338in an hour and 15 minutes. Use this time to buy a faster computer. 339 340 341To find out how the build went, ask for a summary with -s. You can do this 342either before the build completes (presumably in another terminal) or or 343afterwards. Let's work through an example of how this is used: 344 345$ ./tools/buildman/buildman -b lcd9b -s 346... 34701: Merge branch 'master' of git://git.denx.de/u-boot-arm 348 powerpc: + galaxy5200_LOWBOOT 34902: tegra: Use const for pinmux_config_pingroup/table() 35003: tegra: Add display support to funcmux 35104: tegra: fdt: Add pwm binding and node 35205: tegra: fdt: Add LCD definitions for Tegra 35306: tegra: Add support for PWM 35407: tegra: Add SOC support for display/lcd 35508: tegra: Add LCD driver 35609: tegra: Add LCD support to Nvidia boards 35710: arm: Add control over cachability of memory regions 35811: lcd: Add CONFIG_LCD_ALIGNMENT to select frame buffer alignment 35912: lcd: Add support for flushing LCD fb from dcache after update 360 arm: + lubbock 36113: tegra: Align LCD frame buffer to section boundary 36214: tegra: Support control of cache settings for LCD 36315: tegra: fdt: Add LCD definitions for Seaboard 36416: lcd: Add CONFIG_CONSOLE_SCROLL_LINES option to speed console 36517: tegra: Enable display/lcd support on Seaboard 36618: wip 367 368This shows which commits have succeeded and which have failed. In this case 369the build is still in progress so many boards are not built yet (use -u to 370see which ones). But still we can see a few failures. The galaxy5200_LOWBOOT 371never builds correctly. This could be a problem with our toolchain, or it 372could be a bug in the upstream. The good news is that we probably don't need 373to blame our commits. The bad news is it isn't tested on that board. 374 375Commit 12 broke lubbock. That's what the '+ lubbock' means. The failure 376is never fixed by a later commit, or you would see lubbock again, in green, 377without the +. 378 379To see the actual error: 380 381$ ./tools/buildman/buildman -b <branch> -se lubbock 382... 38312: lcd: Add support for flushing LCD fb from dcache after update 384 arm: + lubbock 385+common/libcommon.o: In function `lcd_sync': 386+/u-boot/lcd9b/.bm-work/00/common/lcd.c:120: undefined reference to `flush_dcache_range' 387+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 388+make: *** [/u-boot/lcd9b/.bm-work/00/build/u-boot] Error 139 38913: tegra: Align LCD frame buffer to section boundary 39014: tegra: Support control of cache settings for LCD 39115: tegra: fdt: Add LCD definitions for Seaboard 39216: lcd: Add CONFIG_CONSOLE_SCROLL_LINES option to speed console 393-/u-boot/lcd9b/.bm-work/00/common/lcd.c:120: undefined reference to `flush_dcache_range' 394+/u-boot/lcd9b/.bm-work/00/common/lcd.c:125: undefined reference to `flush_dcache_range' 39517: tegra: Enable display/lcd support on Seaboard 39618: wip 397 398So the problem is in lcd.c, due to missing cache operations. This information 399should be enough to work out what that commit is doing to break these 400boards. (In this case pxa did not have cache operations defined). 401 402If you see error lines marked with - that means that the errors were fixed 403by that commit. Sometimes commits can be in the wrong order, so that a 404breakage is introduced for a few commits and fixed by later commits. This 405shows up clearly with buildman. You can then reorder the commits and try 406again. 407 408At commit 16, the error moves - you can see that the old error at line 120 409is fixed, but there is a new one at line 126. This is probably only because 410we added some code and moved the broken line futher down the file. 411 412If many boards have the same error, then -e will display the error only 413once. This makes the output as concise as possible. 414 415The full build output in this case is available in: 416 417../lcd9b/12_of_18_gd92aff7_lcd--Add-support-for/lubbock/ 418 419 done: Indicates the build was done, and holds the return code from make. 420 This is 0 for a good build, typically 2 for a failure. 421 422 err: Output from stderr, if any. Errors and warnings appear here. 423 424 log: Output from stdout. Normally there isn't any since buildman runs 425 in silent mode for now. 426 427 toolchain: Shows information about the toolchain used for the build. 428 429 sizes: Shows image size information. 430 431It is possible to get the build output there also. Use the -k option for 432this. In that case you will also see some output files, like: 433 434 System.map toolchain u-boot u-boot.bin u-boot.map autoconf.mk 435 (also SPL versions u-boot-spl and u-boot-spl.bin if available) 436 437 438Checking Image Sizes 439==================== 440 441A key requirement for U-Boot is that you keep code/data size to a minimum. 442Where a new feature increases this noticeably it should normally be put 443behind a CONFIG flag so that boards can leave it off and keep the image 444size more or less the same with each new release. 445 446To check the impact of your commits on image size, use -S. For example: 447 448$ ./tools/buildman/buildman -b us-x86 -sS 449Summary of 10 commits for 1066 boards (4 threads, 1 job per thread) 45001: MAKEALL: add support for per architecture toolchains 45102: x86: Add function to get top of usable ram 452 x86: (for 1/3 boards) text -272.0 rodata +41.0 45303: x86: Add basic cache operations 45404: x86: Permit bootstage and timer data to be used prior to relocation 455 x86: (for 1/3 boards) data +16.0 45605: x86: Add an __end symbol to signal the end of the U-Boot binary 457 x86: (for 1/3 boards) text +76.0 45806: x86: Rearrange the output input to remove BSS 459 x86: (for 1/3 boards) bss -2140.0 46007: x86: Support relocation of FDT on start-up 461 x86: + coreboot-x86 46208: x86: Add error checking to x86 relocation code 46309: x86: Adjust link device tree include file 46410: x86: Enable CONFIG_OF_CONTROL on coreboot 465 466 467You can see that image size only changed on x86, which is good because this 468series is not supposed to change any other board. From commit 7 onwards the 469build fails so we don't get code size numbers. The numbers are fractional 470because they are an average of all boards for that architecture. The 471intention is to allow you to quickly find image size problems introduced by 472your commits. 473 474Note that the 'text' region and 'rodata' are split out. You should add the 475two together to get the total read-only size (reported as the first column 476in the output from binutil's 'size' utility). 477 478A useful option is --step which lets you skip some commits. For example 479--step 2 will show the image sizes for only every 2nd commit (so it will 480compare the image sizes of the 1st, 3rd, 5th... commits). You can also use 481--step 0 which will compare only the first and last commits. This is useful 482for an overview of how your entire series affects code size. 483 484You can also use -d to see a detailed size breakdown for each board. This 485list is sorted in order from largest growth to largest reduction. 486 487It is possible to go a little further with the -B option (--bloat). This 488shows where U-Boot has bloted, breaking the size change down to the function 489level. Example output is below: 490 491$ ./tools/buildman/buildman -b us-mem4 -sSdB 492... 49319: Roll crc32 into hash infrastructure 494 arm: (for 10/10 boards) all -143.4 bss +1.2 data -4.8 rodata -48.2 text -91.6 495 paz00 : all +23 bss -4 rodata -29 text +56 496 u-boot: add: 1/0, grow: 3/-2 bytes: 168/-104 (64) 497 function old new delta 498 hash_command 80 160 +80 499 crc32_wd_buf - 56 +56 500 ext4fs_read_file 540 568 +28 501 insert_var_value_sub 688 692 +4 502 run_list_real 1996 1992 -4 503 do_mem_crc 168 68 -100 504 trimslice : all -9 bss +16 rodata -29 text +4 505 u-boot: add: 1/0, grow: 1/-3 bytes: 136/-124 (12) 506 function old new delta 507 hash_command 80 160 +80 508 crc32_wd_buf - 56 +56 509 ext4fs_iterate_dir 672 668 -4 510 ext4fs_read_file 568 548 -20 511 do_mem_crc 168 68 -100 512 whistler : all -9 bss +16 rodata -29 text +4 513 u-boot: add: 1/0, grow: 1/-3 bytes: 136/-124 (12) 514 function old new delta 515 hash_command 80 160 +80 516 crc32_wd_buf - 56 +56 517 ext4fs_iterate_dir 672 668 -4 518 ext4fs_read_file 568 548 -20 519 do_mem_crc 168 68 -100 520 seaboard : all -9 bss -28 rodata -29 text +48 521 u-boot: add: 1/0, grow: 3/-2 bytes: 160/-104 (56) 522 function old new delta 523 hash_command 80 160 +80 524 crc32_wd_buf - 56 +56 525 ext4fs_read_file 548 568 +20 526 run_list_real 1996 2000 +4 527 do_nandboot 760 756 -4 528 do_mem_crc 168 68 -100 529 colibri_t20_iris: all -9 rodata -29 text +20 530 u-boot: add: 1/0, grow: 2/-3 bytes: 140/-112 (28) 531 function old new delta 532 hash_command 80 160 +80 533 crc32_wd_buf - 56 +56 534 read_abs_bbt 204 208 +4 535 do_nandboot 760 756 -4 536 ext4fs_read_file 576 568 -8 537 do_mem_crc 168 68 -100 538 ventana : all -37 bss -12 rodata -29 text +4 539 u-boot: add: 1/0, grow: 1/-3 bytes: 136/-124 (12) 540 function old new delta 541 hash_command 80 160 +80 542 crc32_wd_buf - 56 +56 543 ext4fs_iterate_dir 672 668 -4 544 ext4fs_read_file 568 548 -20 545 do_mem_crc 168 68 -100 546 harmony : all -37 bss -16 rodata -29 text +8 547 u-boot: add: 1/0, grow: 2/-3 bytes: 140/-124 (16) 548 function old new delta 549 hash_command 80 160 +80 550 crc32_wd_buf - 56 +56 551 nand_write_oob_syndrome 428 432 +4 552 ext4fs_iterate_dir 672 668 -4 553 ext4fs_read_file 568 548 -20 554 do_mem_crc 168 68 -100 555 medcom-wide : all -417 bss +28 data -16 rodata -93 text -336 556 u-boot: add: 1/-1, grow: 1/-2 bytes: 88/-376 (-288) 557 function old new delta 558 crc32_wd_buf - 56 +56 559 do_fat_read_at 2872 2904 +32 560 hash_algo 16 - -16 561 do_mem_crc 168 68 -100 562 hash_command 420 160 -260 563 tec : all -449 bss -4 data -16 rodata -93 text -336 564 u-boot: add: 1/-1, grow: 1/-2 bytes: 88/-376 (-288) 565 function old new delta 566 crc32_wd_buf - 56 +56 567 do_fat_read_at 2872 2904 +32 568 hash_algo 16 - -16 569 do_mem_crc 168 68 -100 570 hash_command 420 160 -260 571 plutux : all -481 bss +16 data -16 rodata -93 text -388 572 u-boot: add: 1/-1, grow: 1/-3 bytes: 68/-408 (-340) 573 function old new delta 574 crc32_wd_buf - 56 +56 575 do_load_serial_bin 1688 1700 +12 576 hash_algo 16 - -16 577 do_fat_read_at 2904 2872 -32 578 do_mem_crc 168 68 -100 579 hash_command 420 160 -260 580 powerpc: (for 5/5 boards) all +37.4 data -3.2 rodata -41.8 text +82.4 581 MPC8610HPCD : all +55 rodata -29 text +84 582 u-boot: add: 1/0, grow: 0/-1 bytes: 176/-96 (80) 583 function old new delta 584 hash_command - 176 +176 585 do_mem_crc 184 88 -96 586 MPC8641HPCN : all +55 rodata -29 text +84 587 u-boot: add: 1/0, grow: 0/-1 bytes: 176/-96 (80) 588 function old new delta 589 hash_command - 176 +176 590 do_mem_crc 184 88 -96 591 MPC8641HPCN_36BIT: all +55 rodata -29 text +84 592 u-boot: add: 1/0, grow: 0/-1 bytes: 176/-96 (80) 593 function old new delta 594 hash_command - 176 +176 595 do_mem_crc 184 88 -96 596 sbc8641d : all +55 rodata -29 text +84 597 u-boot: add: 1/0, grow: 0/-1 bytes: 176/-96 (80) 598 function old new delta 599 hash_command - 176 +176 600 do_mem_crc 184 88 -96 601 xpedite517x : all -33 data -16 rodata -93 text +76 602 u-boot: add: 1/-1, grow: 0/-1 bytes: 176/-112 (64) 603 function old new delta 604 hash_command - 176 +176 605 hash_algo 16 - -16 606 do_mem_crc 184 88 -96 607... 608 609 610This shows that commit 19 has increased text size for arm (although only one 611board was built) and by 96 bytes for powerpc. This increase was offset in both 612cases by reductions in rodata and data/bss. 613 614Shown below the summary lines is the sizes for each board. Below each board 615is the sizes for each function. This information starts with: 616 617 add - number of functions added / removed 618 grow - number of functions which grew / shrunk 619 bytes - number of bytes of code added to / removed from all functions, 620 plus the total byte change in brackets 621 622The change seems to be that hash_command() has increased by more than the 623do_mem_crc() function has decreased. The function sizes typically add up to 624roughly the text area size, but note that every read-only section except 625rodata is included in 'text', so the function total does not exactly 626correspond. 627 628It is common when refactoring code for the rodata to decrease as the text size 629increases, and vice versa. 630 631 632Providing 'make' flags 633====================== 634 635U-Boot's build system supports a few flags (such as BUILD_TAG) which affect 636the build product. These flags can be specified in the buildman settings 637file. They can also be useful when building U-Boot against other open source 638software. 639 640[make-flags] 641at91-boards=ENABLE_AT91_TEST=1 642snapper9260=${at91-boards} BUILD_TAG=442 643snapper9g45=${at91-boards} BUILD_TAG=443 644 645This will use 'make ENABLE_AT91_TEST=1 BUILD_TAG=442' for snapper9260 646and 'make ENABLE_AT91_TEST=1 BUILD_TAG=442' for snapper9g45. A special 647variable ${target} is available to access the target name (snapper9260 and 648snapper9g20 in this case). Variables are resolved recursively. 649 650It is expected that any variables added are dealt with in U-Boot's 651config.mk file and documented in the README. 652 653 654Other options 655============= 656 657Buildman has various other command line options. Try --help to see them. 658 659 660TODO 661==== 662 663This has mostly be written in my spare time as a response to my difficulties 664in testing large series of patches. Apart from tidying up there is quite a 665bit of scope for improvement. Things like better error diffs, easier access 666to log files, error display while building. Also it would be nice it buildman 667could 'hunt' for problems, perhaps by building a few boards for each arch, 668or checking commits for changed files and building only boards which use 669those files. 670 671 672Credits 673======= 674 675Thanks to Grant Grundler <grundler@chromium.org> for his ideas for improving 676the build speed by building all commits for a board instead of the other 677way around. 678 679 680Simon Glass 681sjg@chromium.org 682Halloween 2012 683Updated 12-12-12 684Updated 23-02-13 685