README 60 KB

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