diff options
Diffstat (limited to 'roms/u-boot/tools/buildman/README')
| -rw-r--r-- | roms/u-boot/tools/buildman/README | 690 |
1 files changed, 690 insertions, 0 deletions
diff --git a/roms/u-boot/tools/buildman/README b/roms/u-boot/tools/buildman/README new file mode 100644 index 00000000..c30c1d41 --- /dev/null +++ b/roms/u-boot/tools/buildman/README @@ -0,0 +1,690 @@ +# Copyright (c) 2013 The Chromium OS Authors. +# +# SPDX-License-Identifier: GPL-2.0+ +# + +What is this? +============= + +This tool handles building U-Boot to check that you have not broken it +with your patch series. It can build each individual commit and report +which boards fail on which commits, and which errors come up. It aims +to make full use of multi-processor machines. + +A key feature of buildman is its output summary, which allows warnings, +errors or image size increases in a particular commit or board to be +quickly identified and the offending commit pinpointed. This can be a big +help for anyone working with >10 patches at a time. + + +Caveats +======= + +Buildman is still in its infancy. It is already a very useful tool, but +expect to find problems and send patches. + +Buildman can be stopped and restarted, in which case it will continue +where it left off. This should happen cleanly and without side-effects. +If not, it is a bug, for which a patch would be welcome. + +Buildman gets so tied up in its work that it can ignore the outside world. +You may need to press Ctrl-C several times to quit it. Also it will print +out various exceptions when stopped. + + +Theory of Operation +=================== + +(please read this section in full twice or you will be perpetually confused) + +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. All the output (errors, warnings and binaries if you +are ask for them) is stored in output directories, which you can look at +while the build is progressing, or when it is finished. + +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. + +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. + +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. + +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 +threads do not affect the state of your git repository. Any checkouts done +by the thread affect only the working directory for that thread. + +Buildman automatically selects the correct toolchain for each board. You +must supply suitable toolchains, but buildman takes care of selecting the +right one. + +Buildman always builds a branch, and always 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. + +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 +available CPU power. When it gets to the end, or if you are building just +a few commits or boards, it will be pretty slow. As a tip, if you don't +plan to use your machine for anything else, you can use -T to increase the +number of threads beyond the default. + +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 +allowed. Each argument will be interpreted as a regular expression, so +behaviour is a superset of exact or substring matching. Examples are: + +* 'tegra20' All boards with a Tegra20 SoC +* 'tegra' All boards with any Tegra Soc (Tegra20, Tegra30, Tegra114...) +* '^tegra[23]0$' All boards with either Tegra20 or Tegra30 SoC +* 'powerpc' All PowerPC boards + +Buildman does not store intermediate object files. It optionally copies +the binary output into a directory when a build is successful. Size +information is always recorded. It needs a fair bit of disk space to work, +typically 250MB per thread. + + +Setting up +========== + +1. Get the U-Boot source. You probably already have it, but if not these +steps should get you started with a repo and some commits for testing. + +$ cd /path/to/u-boot +$ git clone git://git.denx.de/u-boot.git . +$ git checkout -b my-branch origin/master +$ # Add some commits to the branch, reading for testing + +2. Create ~/.buildman to tell buildman where to find tool chains. As an +example: + +# Buildman settings file + +[toolchain] +root: / +rest: /toolchains/* +eldk: /opt/eldk-4.2 + +[toolchain-alias] +x86: i386 +blackfin: bfin +sh: sh4 +nds32: nds32le +openrisc: or32 + + +This selects the available toolchain paths. Add the base directory for +each of your toolchains here. Buildman will search inside these directories +and also in any '/usr' and '/usr/bin' subdirectories. + +Make sure the tags (here root: rest: and eldk:) are unique. + +The toolchain-alias section indicates that the i386 toolchain should be used +to build x86 commits. + + +2. Check the available toolchains + +Run this check to make sure that you have a toolchain for every architecture. + +$ ./tools/buildman/buildman --list-tool-chains +Scanning for tool chains + - scanning path '/' + - looking in '/.' + - looking in '/bin' + - looking in '/usr/bin' + - found '/usr/bin/gcc' +Tool chain test: OK + - found '/usr/bin/c89-gcc' +Tool chain test: OK + - found '/usr/bin/c99-gcc' +Tool chain test: OK + - found '/usr/bin/x86_64-linux-gnu-gcc' +Tool chain test: OK + - scanning path '/toolchains/powerpc-linux' + - looking in '/toolchains/powerpc-linux/.' + - looking in '/toolchains/powerpc-linux/bin' + - found '/toolchains/powerpc-linux/bin/powerpc-linux-gcc' +Tool chain test: OK + - looking in '/toolchains/powerpc-linux/usr/bin' + - scanning path '/toolchains/nds32le-linux-glibc-v1f' + - looking in '/toolchains/nds32le-linux-glibc-v1f/.' + - looking in '/toolchains/nds32le-linux-glibc-v1f/bin' + - found '/toolchains/nds32le-linux-glibc-v1f/bin/nds32le-linux-gcc' +Tool chain test: OK + - looking in '/toolchains/nds32le-linux-glibc-v1f/usr/bin' + - scanning path '/toolchains/nios2' + - looking in '/toolchains/nios2/.' + - looking in '/toolchains/nios2/bin' + - found '/toolchains/nios2/bin/nios2-linux-gcc' +Tool chain test: OK + - found '/toolchains/nios2/bin/nios2-linux-uclibc-gcc' +Tool chain test: OK + - looking in '/toolchains/nios2/usr/bin' + - found '/toolchains/nios2/usr/bin/nios2-linux-gcc' +Tool chain test: OK + - found '/toolchains/nios2/usr/bin/nios2-linux-uclibc-gcc' +Tool chain test: OK + - scanning path '/toolchains/microblaze-unknown-linux-gnu' + - looking in '/toolchains/microblaze-unknown-linux-gnu/.' + - looking in '/toolchains/microblaze-unknown-linux-gnu/bin' + - found '/toolchains/microblaze-unknown-linux-gnu/bin/microblaze-unknown-linux-gnu-gcc' +Tool chain test: OK + - found '/toolchains/microblaze-unknown-linux-gnu/bin/mb-linux-gcc' +Tool chain test: OK + - looking in '/toolchains/microblaze-unknown-linux-gnu/usr/bin' + - scanning path '/toolchains/mips-linux' + - looking in '/toolchains/mips-linux/.' + - looking in '/toolchains/mips-linux/bin' + - found '/toolchains/mips-linux/bin/mips-linux-gcc' +Tool chain test: OK + - looking in '/toolchains/mips-linux/usr/bin' + - scanning path '/toolchains/old' + - looking in '/toolchains/old/.' + - looking in '/toolchains/old/bin' + - looking in '/toolchains/old/usr/bin' + - scanning path '/toolchains/i386-linux' + - looking in '/toolchains/i386-linux/.' + - looking in '/toolchains/i386-linux/bin' + - found '/toolchains/i386-linux/bin/i386-linux-gcc' +Tool chain test: OK + - looking in '/toolchains/i386-linux/usr/bin' + - scanning path '/toolchains/bfin-uclinux' + - looking in '/toolchains/bfin-uclinux/.' + - looking in '/toolchains/bfin-uclinux/bin' + - found '/toolchains/bfin-uclinux/bin/bfin-uclinux-gcc' +Tool chain test: OK + - looking in '/toolchains/bfin-uclinux/usr/bin' + - scanning path '/toolchains/sparc-elf' + - looking in '/toolchains/sparc-elf/.' + - looking in '/toolchains/sparc-elf/bin' + - found '/toolchains/sparc-elf/bin/sparc-elf-gcc' +Tool chain test: OK + - looking in '/toolchains/sparc-elf/usr/bin' + - scanning path '/toolchains/arm-2010q1' + - looking in '/toolchains/arm-2010q1/.' + - looking in '/toolchains/arm-2010q1/bin' + - found '/toolchains/arm-2010q1/bin/arm-none-linux-gnueabi-gcc' +Tool chain test: OK + - looking in '/toolchains/arm-2010q1/usr/bin' + - scanning path '/toolchains/from' + - looking in '/toolchains/from/.' + - looking in '/toolchains/from/bin' + - looking in '/toolchains/from/usr/bin' + - scanning path '/toolchains/sh4-gentoo-linux-gnu' + - looking in '/toolchains/sh4-gentoo-linux-gnu/.' + - looking in '/toolchains/sh4-gentoo-linux-gnu/bin' + - found '/toolchains/sh4-gentoo-linux-gnu/bin/sh4-gentoo-linux-gnu-gcc' +Tool chain test: OK + - looking in '/toolchains/sh4-gentoo-linux-gnu/usr/bin' + - scanning path '/toolchains/avr32-linux' + - looking in '/toolchains/avr32-linux/.' + - looking in '/toolchains/avr32-linux/bin' + - found '/toolchains/avr32-linux/bin/avr32-gcc' +Tool chain test: OK + - looking in '/toolchains/avr32-linux/usr/bin' + - scanning path '/toolchains/m68k-linux' + - looking in '/toolchains/m68k-linux/.' + - looking in '/toolchains/m68k-linux/bin' + - found '/toolchains/m68k-linux/bin/m68k-linux-gcc' +Tool chain test: OK + - looking in '/toolchains/m68k-linux/usr/bin' +List of available toolchains (17): +arm : /toolchains/arm-2010q1/bin/arm-none-linux-gnueabi-gcc +avr32 : /toolchains/avr32-linux/bin/avr32-gcc +bfin : /toolchains/bfin-uclinux/bin/bfin-uclinux-gcc +c89 : /usr/bin/c89-gcc +c99 : /usr/bin/c99-gcc +i386 : /toolchains/i386-linux/bin/i386-linux-gcc +m68k : /toolchains/m68k-linux/bin/m68k-linux-gcc +mb : /toolchains/microblaze-unknown-linux-gnu/bin/mb-linux-gcc +microblaze: /toolchains/microblaze-unknown-linux-gnu/bin/microblaze-unknown-linux-gnu-gcc +mips : /toolchains/mips-linux/bin/mips-linux-gcc +nds32le : /toolchains/nds32le-linux-glibc-v1f/bin/nds32le-linux-gcc +nios2 : /toolchains/nios2/bin/nios2-linux-gcc +powerpc : /toolchains/powerpc-linux/bin/powerpc-linux-gcc +sandbox : /usr/bin/gcc +sh4 : /toolchains/sh4-gentoo-linux-gnu/bin/sh4-gentoo-linux-gnu-gcc +sparc : /toolchains/sparc-elf/bin/sparc-elf-gcc +x86_64 : /usr/bin/x86_64-linux-gnu-gcc + + +You can see that everything is covered, even some strange ones that won't +be used (c88 and c99). This is a feature. + + +How to run it +============= + +First do a dry run using the -n flag: (replace <branch> with a real, local +branch with a valid upstream) + +$ ./tools/buildman/buildman -b <branch> -n + +If it can't detect the upstream branch, try checking out the branch, and +doing something like 'git branch --set-upstream <branch> upstream/master' +or something similar. + +As an exmmple: + +Dry run, so not doing much. But I would do this: + +Building 18 commits for 1059 boards (4 threads, 1 job per thread) +Build directory: ../lcd9b + 5bb3505 Merge branch 'master' of git://git.denx.de/u-boot-arm + c18f1b4 tegra: Use const for pinmux_config_pingroup/table() + 2f043ae tegra: Add display support to funcmux + e349900 tegra: fdt: Add pwm binding and node + 424a5f0 tegra: fdt: Add LCD definitions for Tegra + 0636ccf tegra: Add support for PWM + a994fe7 tegra: Add SOC support for display/lcd + fcd7350 tegra: Add LCD driver + 4d46e9d tegra: Add LCD support to Nvidia boards + 991bd48 arm: Add control over cachability of memory regions + 54e8019 lcd: Add CONFIG_LCD_ALIGNMENT to select frame buffer alignment + d92aff7 lcd: Add support for flushing LCD fb from dcache after update + dbd0677 tegra: Align LCD frame buffer to section boundary + 0cff9b8 tegra: Support control of cache settings for LCD + 9c56900 tegra: fdt: Add LCD definitions for Seaboard + 5cc29db lcd: Add CONFIG_CONSOLE_SCROLL_LINES option to speed console + cac5a23 tegra: Enable display/lcd support on Seaboard + 49ff541 wip + +Total boards to build for each commit: 1059 + +This shows that it will build all 1059 boards, using 4 threads (because +we have a 4-core CPU). Each thread will run with -j1, meaning that each +make job will use a single CPU. The list of commits to be built helps you +confirm that things look about right. Notice that buildman has chosen a +'base' directory for you, immediately above your source tree. + +Buildman works entirely inside the base directory, here ../lcd9b, +creating a working directory for each thread, and creating output +directories for each commit and board. + + +Suggested Workflow +================== + +To run the build for real, take off the -n: + +$ ./tools/buildman/buildman -b <branch> + +Buildman will set up some working directories, and get started. After a +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 + +This means that it is building 19062 board/commit combinations. So far it +has managed to succesfully build 528. Another 36 have built with warnings, +and 124 more didn't build at all. Buildman expects to complete the process +in an hour and 15 minutes. Use this time to buy a faster computer. + + +To find out how the build went, ask for a summary with -s. You can do this +either before the build completes (presumably in another terminal) or or +afterwards. Let's work through an example of how this is used: + +$ ./tools/buildman/buildman -b lcd9b -s +... +01: Merge branch 'master' of git://git.denx.de/u-boot-arm + powerpc: + galaxy5200_LOWBOOT +02: tegra: Use const for pinmux_config_pingroup/table() +03: tegra: Add display support to funcmux +04: tegra: fdt: Add pwm binding and node +05: tegra: fdt: Add LCD definitions for Tegra +06: tegra: Add support for PWM +07: tegra: Add SOC support for display/lcd +08: tegra: Add LCD driver +09: tegra: Add LCD support to Nvidia boards +10: arm: Add control over cachability of memory regions +11: lcd: Add CONFIG_LCD_ALIGNMENT to select frame buffer alignment +12: lcd: Add support for flushing LCD fb from dcache after update + arm: + lubbock +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 +17: tegra: Enable display/lcd support on Seaboard +18: wip + +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 +never builds correctly. This could be a problem with our toolchain, or it +could be a bug in the upstream. The good news is that we probably don't need +to blame our commits. The bad news is it isn't tested on that board. + +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 +. + +To see the actual error: + +$ ./tools/buildman/buildman -b <branch> -se lubbock +... +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' ++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 +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' +17: tegra: Enable display/lcd support on Seaboard +18: wip + +So the problem is in lcd.c, due to missing cache operations. This information +should be enough to work out what that commit is doing to break these +boards. (In this case pxa did not have cache operations defined). + +If you see error lines marked with - that means that the errors were fixed +by that commit. Sometimes commits can be in the wrong order, so that a +breakage is introduced for a few commits and fixed by later commits. This +shows up clearly with buildman. You can then reorder the commits and try +again. + +At commit 16, the error moves - you can see that the old error at line 120 +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 futher 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. + +The full build output in this case is available in: + +../lcd9b/12_of_18_gd92aff7_lcd--Add-support-for/lubbock/ + + done: Indicates the build was done, and holds the return code from make. + This is 0 for a good build, typically 2 for a failure. + + err: Output from stderr, if any. Errors and warnings appear here. + + log: Output from stdout. Normally there isn't any since buildman runs + in silent mode for now. + + toolchain: Shows information about the toolchain used for the build. + + sizes: Shows image size information. + +It is possible to get the build output there also. Use the -k option for +this. In that case you will also see some output files, like: + + System.map toolchain u-boot u-boot.bin u-boot.map autoconf.mk + (also SPL versions u-boot-spl and u-boot-spl.bin if available) + + +Checking Image Sizes +==================== + +A key requirement for U-Boot is that you keep code/data size to a minimum. +Where a new feature increases this noticeably it should normally be put +behind a CONFIG flag so that boards can leave it off and keep the image +size more or less the same with each new release. + +To check the impact of your commits on image size, use -S. For example: + +$ ./tools/buildman/buildman -b us-x86 -sS +Summary of 10 commits for 1066 boards (4 threads, 1 job per thread) +01: MAKEALL: add support for per architecture toolchains +02: x86: Add function to get top of usable ram + x86: (for 1/3 boards) text -272.0 rodata +41.0 +03: x86: Add basic cache operations +04: x86: Permit bootstage and timer data to be used prior to relocation + x86: (for 1/3 boards) data +16.0 +05: x86: Add an __end symbol to signal the end of the U-Boot binary + x86: (for 1/3 boards) text +76.0 +06: x86: Rearrange the output input to remove BSS + x86: (for 1/3 boards) bss -2140.0 +07: x86: Support relocation of FDT on start-up + x86: + coreboot-x86 +08: x86: Add error checking to x86 relocation code +09: x86: Adjust link device tree include file +10: x86: Enable CONFIG_OF_CONTROL on coreboot + + +You can see that image size only changed on x86, which is good because this +series is not supposed to change any other board. From commit 7 onwards the +build fails so we don't get code size numbers. The numbers are fractional +because they are an average of all boards for that architecture. The +intention is to allow you to quickly find image size problems introduced by +your commits. + +Note that the 'text' region and 'rodata' are split out. You should add the +two together to get the total read-only size (reported as the first column +in the output from binutil's 'size' utility). + +A useful option is --step which lets you skip some commits. For example +--step 2 will show the image sizes for only every 2nd commit (so it will +compare the image sizes of the 1st, 3rd, 5th... commits). You can also use +--step 0 which will compare only the first and last commits. This is useful +for an overview of how your entire series affects code size. + +You can also use -d to see a detailed size breakdown for each board. This +list is sorted in order from largest growth to largest reduction. + +It is possible to go a little further with the -B option (--bloat). This +shows where U-Boot has bloted, breaking the size change down to the function +level. Example output is below: + +$ ./tools/buildman/buildman -b us-mem4 -sSdB +... +19: Roll crc32 into hash infrastructure + arm: (for 10/10 boards) all -143.4 bss +1.2 data -4.8 rodata -48.2 text -91.6 + paz00 : all +23 bss -4 rodata -29 text +56 + u-boot: add: 1/0, grow: 3/-2 bytes: 168/-104 (64) + function old new delta + hash_command 80 160 +80 + crc32_wd_buf - 56 +56 + ext4fs_read_file 540 568 +28 + insert_var_value_sub 688 692 +4 + run_list_real 1996 1992 -4 + do_mem_crc 168 68 -100 + trimslice : all -9 bss +16 rodata -29 text +4 + u-boot: add: 1/0, grow: 1/-3 bytes: 136/-124 (12) + function old new delta + hash_command 80 160 +80 + crc32_wd_buf - 56 +56 + ext4fs_iterate_dir 672 668 -4 + ext4fs_read_file 568 548 -20 + do_mem_crc 168 68 -100 + whistler : all -9 bss +16 rodata -29 text +4 + u-boot: add: 1/0, grow: 1/-3 bytes: 136/-124 (12) + function old new delta + hash_command 80 160 +80 + crc32_wd_buf - 56 +56 + ext4fs_iterate_dir 672 668 -4 + ext4fs_read_file 568 548 -20 + do_mem_crc 168 68 -100 + seaboard : all -9 bss -28 rodata -29 text +48 + u-boot: add: 1/0, grow: 3/-2 bytes: 160/-104 (56) + function old new delta + hash_command 80 160 +80 + crc32_wd_buf - 56 +56 + ext4fs_read_file 548 568 +20 + run_list_real 1996 2000 +4 + do_nandboot 760 756 -4 + do_mem_crc 168 68 -100 + colibri_t20_iris: all -9 rodata -29 text +20 + u-boot: add: 1/0, grow: 2/-3 bytes: 140/-112 (28) + function old new delta + hash_command 80 160 +80 + crc32_wd_buf - 56 +56 + read_abs_bbt 204 208 +4 + do_nandboot 760 756 -4 + ext4fs_read_file 576 568 -8 + do_mem_crc 168 68 -100 + ventana : all -37 bss -12 rodata -29 text +4 + u-boot: add: 1/0, grow: 1/-3 bytes: 136/-124 (12) + function old new delta + hash_command 80 160 +80 + crc32_wd_buf - 56 +56 + ext4fs_iterate_dir 672 668 -4 + ext4fs_read_file 568 548 -20 + do_mem_crc 168 68 -100 + harmony : all -37 bss -16 rodata -29 text +8 + u-boot: add: 1/0, grow: 2/-3 bytes: 140/-124 (16) + function old new delta + hash_command 80 160 +80 + crc32_wd_buf - 56 +56 + nand_write_oob_syndrome 428 432 +4 + ext4fs_iterate_dir 672 668 -4 + ext4fs_read_file 568 548 -20 + do_mem_crc 168 68 -100 + medcom-wide : all -417 bss +28 data -16 rodata -93 text -336 + u-boot: add: 1/-1, grow: 1/-2 bytes: 88/-376 (-288) + function old new delta + crc32_wd_buf - 56 +56 + do_fat_read_at 2872 2904 +32 + hash_algo 16 - -16 + do_mem_crc 168 68 -100 + hash_command 420 160 -260 + tec : all -449 bss -4 data -16 rodata -93 text -336 + u-boot: add: 1/-1, grow: 1/-2 bytes: 88/-376 (-288) + function old new delta + crc32_wd_buf - 56 +56 + do_fat_read_at 2872 2904 +32 + hash_algo 16 - -16 + do_mem_crc 168 68 -100 + hash_command 420 160 -260 + plutux : all -481 bss +16 data -16 rodata -93 text -388 + u-boot: add: 1/-1, grow: 1/-3 bytes: 68/-408 (-340) + function old new delta + crc32_wd_buf - 56 +56 + do_load_serial_bin 1688 1700 +12 + hash_algo 16 - -16 + do_fat_read_at 2904 2872 -32 + do_mem_crc 168 68 -100 + hash_command 420 160 -260 + powerpc: (for 5/5 boards) all +37.4 data -3.2 rodata -41.8 text +82.4 + MPC8610HPCD : all +55 rodata -29 text +84 + u-boot: add: 1/0, grow: 0/-1 bytes: 176/-96 (80) + function old new delta + hash_command - 176 +176 + do_mem_crc 184 88 -96 + MPC8641HPCN : all +55 rodata -29 text +84 + u-boot: add: 1/0, grow: 0/-1 bytes: 176/-96 (80) + function old new delta + hash_command - 176 +176 + do_mem_crc 184 88 -96 + MPC8641HPCN_36BIT: all +55 rodata -29 text +84 + u-boot: add: 1/0, grow: 0/-1 bytes: 176/-96 (80) + function old new delta + hash_command - 176 +176 + do_mem_crc 184 88 -96 + sbc8641d : all +55 rodata -29 text +84 + u-boot: add: 1/0, grow: 0/-1 bytes: 176/-96 (80) + function old new delta + hash_command - 176 +176 + do_mem_crc 184 88 -96 + xpedite517x : all -33 data -16 rodata -93 text +76 + u-boot: add: 1/-1, grow: 0/-1 bytes: 176/-112 (64) + function old new delta + hash_command - 176 +176 + hash_algo 16 - -16 + do_mem_crc 184 88 -96 +... + + +This shows that commit 19 has increased text size for arm (although only one +board was built) and by 96 bytes for powerpc. This increase was offset in both +cases by reductions in rodata and data/bss. + +Shown below the summary lines is the sizes for each board. Below each board +is the sizes for each function. This information starts with: + + add - number of functions added / removed + grow - number of functions which grew / shrunk + bytes - number of bytes of code added to / removed from all functions, + plus the total byte change in brackets + +The change seems to be that hash_command() has increased by more than the +do_mem_crc() function has decreased. The function sizes typically add up to +roughly the text area size, but note that every read-only section except +rodata is included in 'text', so the function total does not exactly +correspond. + +It is common when refactoring code for the rodata to decrease as the text size +increases, and vice versa. + + +Providing 'make' flags +====================== + +U-Boot's build system supports a few flags (such as BUILD_TAG) which affect +the build product. These flags can be specified in the buildman settings +file. They can also be useful when building U-Boot against other open source +software. + +[make-flags] +at91-boards=ENABLE_AT91_TEST=1 +snapper9260=${at91-boards} BUILD_TAG=442 +snapper9g45=${at91-boards} BUILD_TAG=443 + +This will use 'make ENABLE_AT91_TEST=1 BUILD_TAG=442' for snapper9260 +and 'make ENABLE_AT91_TEST=1 BUILD_TAG=443' for snapper9g45. A special +variable ${target} is available to access the target name (snapper9260 and +snapper9g20 in this case). Variables are resolved recursively. + +It is expected that any variables added are dealt with in U-Boot's +config.mk file and documented in the README. + + +Other options +============= + +Buildman has various other command line options. Try --help to see them. + + +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, easier access +to log files, error display while building. Also it would be nice it 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. + + +Credits +======= + +Thanks to Grant Grundler <grundler@chromium.org> for his ideas for improving +the build speed by building all commits for a board instead of the other +way around. + + +Simon Glass +sjg@chromium.org +Halloween 2012 +Updated 12-12-12 +Updated 23-02-13 |