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