From f972836593b6324763aa72d5196bf7bfbaa416ab Mon Sep 17 00:00:00 2001 From: Simon Glass Date: Thu, 9 Apr 2020 15:08:48 -0600 Subject: buildman: Update the 'theory of operation' a little Make a few updates to this important section of the documentation, to make things clearer. Signed-off-by: Simon Glass --- tools/buildman/README | 69 +++++++++++++++++++++++++++++---------------------- 1 file changed, 39 insertions(+), 30 deletions(-) (limited to 'tools/buildman/README') diff --git a/tools/buildman/README b/tools/buildman/README index 4cf0114157..86f5dfe501 100644 --- a/tools/buildman/README +++ b/tools/buildman/README @@ -51,23 +51,25 @@ Theory of Operation Buildman is a builder. It is not make, although it runs make. It does not produce any useful output on the terminal while building, except for -progress information (except with -v, see below). All the output (errors, -warnings and binaries if you ask for them) is stored in output -directories, which you can look at while the build is progressing, or when -it is finished. +progress information (but see -v below). All the output (errors, warnings and +binaries if you ask for them) is stored in output directories, which you can +look at from a separate 'buildman -s' instance while the build is progressing, +or when it is finished. Buildman is designed to build entire git branches, i.e. muliple commits. It -can be run repeatedly on the same branch. In this case it will automatically -rebuild commits which have changed (and remove its old results for that -commit). It is possible to build a branch for one board, then later build it -for another board. If you want buildman to re-build a commit it has already -built (e.g. because of a toolchain update), use the -f flag. +can be run repeatedly on the same branch after making changes to commits on +that branch. In this case it will automatically rebuild commits which have +changed (and remove its old results for that commit). It is possible to build +a branch for one board, then later build it for another board. This adds to +the output, so now you have results for two boards. If you want buildman to +re-build a commit it has already built (e.g. because of a toolchain update), +use the -f flag. Buildman produces a concise summary of which boards succeeded and failed. It shows which commit introduced which board failure using a simple -red/green colour coding. Full error information can be requested, in which -case it is de-duped and displayed against the commit that introduced the -error. An example workflow is below. +red/green colour coding (with yellow/cyan for warnings). Full error +information can be requested, in which case it is de-duped and displayed +against the commit that introduced the error. An example workflow is below. Buildman stores image size information and can report changes in image size from commit to commit. An example of this is below. @@ -75,16 +77,20 @@ from commit to commit. An example of this is below. Buildman starts multiple threads, and each thread builds for one board at a time. A thread starts at the first commit, configures the source for your board and builds it. Then it checks out the next commit and does an -incremental build. Eventually the thread reaches the last commit and stops. -If errors or warnings are found along the way, the thread will reconfigure -after every commit, and your build will be very slow. This is because a -file that produces just a warning would not normally be rebuilt in an -incremental build. +incremental build (i.e. not using 'make xxx_defconfig' unless you use -C). +Eventually the thread reaches the last commit and stops. If a commit causes +an error or warning, buildman will try it again after reconfiguring (but see +-Q). Thus some commits may be built twice, with the first result silently +discarded. Lots of errors and warnings will causes lots of reconfigures and your +build will be very slow. This is because a file that produces just a warning +would not normally be rebuilt in an incremental build. Once a thread finishes +building all the commits for a board, it starts on the commits for another +board. Buildman works in an entirely separate place from your U-Boot repository. It creates a separate working directory for each thread, and puts the output files in the working directory, organised by commit name and board -name, in a two-level hierarchy. +name, in a two-level hierarchy (but see -P). Buildman is invoked in your U-Boot directory, the one with the .git directory. It clones this repository into a copy for each thread, and the @@ -92,20 +98,23 @@ threads do not affect the state of your git repository. Any checkouts done by the thread affect only the working directory for that thread. Buildman automatically selects the correct tool chain for each board. You -must supply suitable tool chains, but buildman takes care of selecting the -right one. +must supply suitable tool chains (see --fetch-arch), but buildman takes care +of selecting the right one. Buildman generally builds a branch (with the -b flag), and in this case -builds the upstream commit as well, for comparison. It cannot build -individual commits at present, unless (maybe) you point it at an empty -branch. Put all your commits in a branch, set the branch's upstream to a -valid value, and all will be well. Otherwise buildman will perform random -actions. Use -n to check what the random actions might be. - -If you just want to build the current source tree, leave off the -b flag -and add -e. This will display results and errors as they happen. You can -still look at them later using -se. Note that buildman will assume that the -source has changed, and will build all specified boards in this case. +builds the upstream commit as well, for comparison. So even if you have one +commit in your branch, two commits will be built. Put all your commits in a +branch, set the branch's upstream to a valid value, and all will be well. +Otherwise buildman will perform random actions. Use -n to check what the +random actions might be. + +Buildman effectively has two modes: without -s it builds, with -s it +summarises the results of previous (or active) builds. + +If you just want to build the current source tree, leave off the -b flag. +This will display results and errors as they happen. You can still look at +them later using -se. Note that buildman will assume that the source has +changed, and will build all specified boards in this case. Buildman is optimised for building many commits at once, for many boards. On multi-core machines, Buildman is fast because it uses most of the -- cgit From 9e040b574688b5b2dd670d6390a37d311814eba7 Mon Sep 17 00:00:00 2001 From: Simon Glass Date: Thu, 9 Apr 2020 15:08:49 -0600 Subject: buildman: Add the abbreviation for --boards This option may be frequency used, so mention that it can be abbreviated to --bo Signed-off-by: Simon Glass --- tools/buildman/README | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'tools/buildman/README') diff --git a/tools/buildman/README b/tools/buildman/README index 86f5dfe501..9bf4383f9f 100644 --- a/tools/buildman/README +++ b/tools/buildman/README @@ -151,9 +151,9 @@ You can also use -x to specifically exclude some boards. For example: means to build all arm boards except nvidia, freescale and anything ending with 'ball'. -For building specific boards you can use the --boards option, which takes a -comma-separated list of board target names and be used multiple times on -the command line: +For building specific boards you can use the --boards (or --bo) option, which +takes a comma-separated list of board target names and be used multiple times +on the command line: buildman --boards sandbox,snow --boards -- cgit From ea09fb5bf1ec87ed573674c361be50a7ad96ca74 Mon Sep 17 00:00:00 2001 From: Simon Glass Date: Thu, 9 Apr 2020 15:08:50 -0600 Subject: buildman: Update workflow documentation with more detail Make a few additions and change some wording in the workflow documentation. Signed-off-by: Simon Glass --- tools/buildman/README | 53 ++++++++++++++++++++++++++++++++++----------------- 1 file changed, 36 insertions(+), 17 deletions(-) (limited to 'tools/buildman/README') diff --git a/tools/buildman/README b/tools/buildman/README index 9bf4383f9f..ca0d1f6446 100644 --- a/tools/buildman/README +++ b/tools/buildman/README @@ -501,6 +501,8 @@ If it can't detect the upstream branch, try checking out the branch, and doing something like 'git branch --set-upstream-to upstream/master' or something similar. Buildman will try to guess a suitable upstream branch if it can't find one (you will see a message like" Guessing upstream as ...). +You can also use the -c option to manually specify the number of commits to +build. As an example: @@ -551,12 +553,13 @@ Buildman will set up some working directories, and get started. After a minute or so it will settle down to a steady pace, with a display like this: Building 18 commits for 1059 boards (4 threads, 1 job per thread) - 528 36 124 /19062 1:13:30 : SIMPC8313_SP + 528 36 124 /19062 -18374 1:13:30 : SIMPC8313_SP This means that it is building 19062 board/commit combinations. So far it has managed to successfully build 528. Another 36 have built with warnings, -and 124 more didn't build at all. Buildman expects to complete the process -in around an hour and a quarter. Use this time to buy a faster computer. +and 124 more didn't build at all. It has 18374 builds left to complete. +Buildman expects to complete the process in around an hour and a quarter. +Use this time to buy a faster computer. To find out how the build went, ask for a summary with -s. You can do this @@ -588,32 +591,32 @@ $ ./tools/buildman/buildman -b lcd9b -s This shows which commits have succeeded and which have failed. In this case the build is still in progress so many boards are not built yet (use -u to -see which ones). But still we can see a few failures. The galaxy5200_LOWBOOT +see which ones). But already we can see a few failures. The galaxy5200_LOWBOOT never builds correctly. This could be a problem with our toolchain, or it could be a bug in the upstream. The good news is that we probably don't need to blame our commits. The bad news is that our commits are not tested on that board. -Commit 12 broke lubbock. That's what the '+ lubbock' means. The failure -is never fixed by a later commit, or you would see lubbock again, in green, -without the +. +Commit 12 broke lubbock. That's what the '+ lubbock', in red, means. The +failure is never fixed by a later commit, or you would see lubbock again, in +green, without the +. To see the actual error: -$ ./tools/buildman/buildman -b -se lubbock +$ ./tools/buildman/buildman -b -se ... 12: lcd: Add support for flushing LCD fb from dcache after update arm: + lubbock +common/libcommon.o: In function `lcd_sync': -+/u-boot/lcd9b/.bm-work/00/common/lcd.c:120: undefined reference to `flush_dcache_range' ++common/lcd.c:120: undefined reference to `flush_dcache_range' +arm-none-linux-gnueabi-ld: BFD (Sourcery G++ Lite 2010q1-202) 2.19.51.20090709 assertion fail /scratch/julian/2010q1-release-linux-lite/obj/binutils-src-2010q1-202-arm-none-linux-gnueabi-i686-pc-linux-gnu/bfd/elf32-arm.c:12572 -+make: *** [/u-boot/lcd9b/.bm-work/00/build/u-boot] Error 139 ++make: *** [build/u-boot] Error 139 13: tegra: Align LCD frame buffer to section boundary 14: tegra: Support control of cache settings for LCD 15: tegra: fdt: Add LCD definitions for Seaboard 16: lcd: Add CONFIG_CONSOLE_SCROLL_LINES option to speed console --/u-boot/lcd9b/.bm-work/00/common/lcd.c:120: undefined reference to `flush_dcache_range' -+/u-boot/lcd9b/.bm-work/00/common/lcd.c:125: undefined reference to `flush_dcache_range' +-common/lcd.c:120: undefined reference to `flush_dcache_range' ++common/lcd.c:125: undefined reference to `flush_dcache_range' 17: tegra: Enable display/lcd support on Seaboard 18: wip @@ -621,6 +624,21 @@ So the problem is in lcd.c, due to missing cache operations. This information should be enough to work out what that commit is doing to break these boards. (In this case pxa did not have cache operations defined). +Note that if there were other boards with errors, the above command would +show their errors also. Each line is shown only once. So if lubbock and snow +produce the same error, we just see: + +12: lcd: Add support for flushing LCD fb from dcache after update + arm: + lubbock snow ++common/libcommon.o: In function `lcd_sync': ++common/lcd.c:120: undefined reference to `flush_dcache_range' ++arm-none-linux-gnueabi-ld: BFD (Sourcery G++ Lite 2010q1-202) 2.19.51.20090709 assertion fail /scratch/julian/2010q1-release-linux-lite/obj/binutils-src-2010q1-202-arm-none-linux-gnueabi-i686-pc-linux-gnu/bfd/elf32-arm.c:12572 ++make: *** [build/u-boot] Error 139 + +But if you did want to see just the errors for lubbock, use: + +$ ./tools/buildman/buildman -b -se lubbock + If you see error lines marked with '-', that means that the errors were fixed by that commit. Sometimes commits can be in the wrong order, so that a breakage is introduced for a few commits and fixed by later commits. This @@ -631,13 +649,14 @@ At commit 16, the error moves: you can see that the old error at line 120 is fixed, but there is a new one at line 126. This is probably only because we added some code and moved the broken line further down the file. -If many boards have the same error, then -e will display the error only -once. This makes the output as concise as possible. To see which boards have -each error, use -l. So it is safe to omit the board name - you will not get -lots of repeated output for every board. +As mentioned, if many boards have the same error, then -e will display the +error only once. This makes the output as concise as possible. To see which +boards have each error, use -l. So it is safe to omit the board name - you +will not get lots of repeated output for every board. Buildman tries to distinguish warnings from errors, and shows warning lines -separately with a 'w' prefix. +separately with a 'w' prefix. Warnings introduced show as yellow. Warnings +fixed show as cyan. The full build output in this case is available in: -- cgit From eb70a2c0598c416777049a89c09c32474ff918b0 Mon Sep 17 00:00:00 2001 From: Simon Glass Date: Thu, 9 Apr 2020 15:08:51 -0600 Subject: buildman: Make -I the default At present buildman defaults to running 'mrproper' on every thread before it starts building commits for each board. This can add a delay of about 5 seconds to the start of the process, since the tools and other invariants must be rebuilt. In particular, a build without '-b', to build current source, runs much slower without -I, since any existing build is removed, thus losing the possibility of an incremental build. Partly this behaviour was to avoid strange build-system problems caused by running 'make defconfig' for one board and then one with a different architecture. But these problems were fixed quite a while ago. The -I option (which disabled mrproper) was introduced four years ago and does not seem to cause any problems with builds. So make -I the default and deprecate the option. To allow use of 'mrproper', add a new -m flag. Signed-off-by: Simon Glass --- tools/buildman/README | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) (limited to 'tools/buildman/README') diff --git a/tools/buildman/README b/tools/buildman/README index ca0d1f6446..f299b0c297 100644 --- a/tools/buildman/README +++ b/tools/buildman/README @@ -958,12 +958,11 @@ will build commits in us-buildman that are not in upstream/master. Building Faster =============== -By default, buildman executes 'make mrproper' prior to building the first -commit for each board. This causes everything to be built from scratch. If you -trust the build system's incremental build capabilities, you can pass the -I -flag to skip the 'make mproper' invocation, which will reduce the amount of -work 'make' does, and hence speed up the build. This flag will speed up any -buildman invocation, since it reduces the amount of work done on any build. +By default, buildman doesn't execute 'make mrproper' prior to building the +first commit for each board. This reduces the amount of work 'make' does, and +hence speeds up the build. To force use of 'make mrproper', use -the -m flag. +This flag will slow down any buildman invocation, since it increases the amount +of work done on any build. One possible application of buildman is as part of a continual edit, build, edit, build, ... cycle; repeatedly applying buildman to the same change or @@ -994,7 +993,7 @@ Combining all of these options together yields the command-line shown below. This will provide the quickest possible feedback regarding the current content of the source tree, thus allowing rapid tested evolution of the code. - SOURCE_DATE_EPOCH=0 ./tools/buildman/buildman -I -P tegra + SOURCE_DATE_EPOCH=0 ./tools/buildman/buildman -P tegra Checking configuration -- cgit From 174592b964c762eca5e405494dda0ffc10deeb7b Mon Sep 17 00:00:00 2001 From: Simon Glass Date: Thu, 9 Apr 2020 15:08:52 -0600 Subject: buildman: Add an option to ignore device-tree warnings Unfortunately the plague of device-tree warnings has not lifted. These warnings infiltrate almost every build, adding noise and confusion. Add a buildman option to ignore them. This option works only with the summary option (-s). It does not affect the build process. Signed-off-by: Simon Glass --- tools/buildman/README | 3 +++ 1 file changed, 3 insertions(+) (limited to 'tools/buildman/README') diff --git a/tools/buildman/README b/tools/buildman/README index f299b0c297..0663ec33a5 100644 --- a/tools/buildman/README +++ b/tools/buildman/README @@ -1124,6 +1124,9 @@ warnings will produce success (since 129 is changed to 0). If there are both warnings and errors, errors win, so buildman returns 128. +The -y option is provided (for use with -s) to ignore the bountiful device-tree +warnings. + How to change from MAKEALL ========================== -- cgit From 113a8a5ff3c44637ebfc661b6c399d39bcb4c180 Mon Sep 17 00:00:00 2001 From: Simon Glass Date: Thu, 9 Apr 2020 15:08:53 -0600 Subject: buildman: Add an option to ignore migration warnings These are becoming more common now. They cause boards to show warnings which can be mistaking for compiler warnings. Add a buildman option to ignore them. This option works only with the summary option (-s). It does not affect the build process. Signed-off-by: Simon Glass --- tools/buildman/README | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'tools/buildman/README') diff --git a/tools/buildman/README b/tools/buildman/README index 0663ec33a5..fe76d4ce0e 100644 --- a/tools/buildman/README +++ b/tools/buildman/README @@ -1125,7 +1125,7 @@ warnings will produce success (since 129 is changed to 0). If there are both warnings and errors, errors win, so buildman returns 128. The -y option is provided (for use with -s) to ignore the bountiful device-tree -warnings. +warnings. Similarly, -Y tells buildman to ignore the migration warnings. How to change from MAKEALL -- cgit From a38930e227ffdeef8c87e4072b7cb59f6127c3cc Mon Sep 17 00:00:00 2001 From: Simon Glass Date: Thu, 9 Apr 2020 15:08:54 -0600 Subject: buildman: Update the TODO items A few of these have been done. Drop those and add some new ideas. Signed-off-by: Simon Glass --- tools/buildman/README | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) (limited to 'tools/buildman/README') diff --git a/tools/buildman/README b/tools/buildman/README index fe76d4ce0e..cb565b551f 100644 --- a/tools/buildman/README +++ b/tools/buildman/README @@ -1232,12 +1232,16 @@ Some options you might like are: TODO ==== -This has mostly be written in my spare time as a response to my difficulties -in testing large series of patches. Apart from tidying up there is quite a -bit of scope for improvement. Things like better error diffs and easier -access to log files. Also it would be nice if buildman could 'hunt' for -problems, perhaps by building a few boards for each arch, or checking -commits for changed files and building only boards which use those files. +Many improvements have been made over the years. There is still quite a bit of +scope for more though, e.g.: + +- easier access to log files +- 'hunting' for problems, perhaps by building a few boards for each arch, or + checking commits for changed files and building only boards which use those + files +- using the same git repo for all threads instead of cloning it. Currently + it uses about 500MB per thread, so on a 64-thread machine this is 32GB for + the build. Credits @@ -1253,3 +1257,4 @@ sjg@chromium.org Halloween 2012 Updated 12-12-12 Updated 23-02-13 +Updated 09-04-20 -- cgit From b1e5e6d22478554b4bc74afd280440732ccc9422 Mon Sep 17 00:00:00 2001 From: Simon Glass Date: Thu, 9 Apr 2020 10:49:45 -0600 Subject: buildman: Change the exit codes The current exit codes of 128 and 129 are useful in that they do not conflict with those returned by tools, but they are not actually valid. It seems better to pick some codes which work with 'bit bisect run'. Update them to 100 (for errors) and 101 (for warnings). Signed-off-by: Simon Glass --- tools/buildman/README | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) (limited to 'tools/buildman/README') diff --git a/tools/buildman/README b/tools/buildman/README index cb565b551f..f3a0dc7288 100644 --- a/tools/buildman/README +++ b/tools/buildman/README @@ -1114,15 +1114,15 @@ with -E, e.g. the migration warnings: When doing builds, Buildman's return code will reflect the overall result: 0 (success) No errors or warnings found - 128 Errors found - 129 Warnings found (only if no -W) + 100 Errors found + 101 Warnings found (only if no -W) -You can use -W to tell Buildman to return 0 (success) instead of 129 when +You can use -W to tell Buildman to return 0 (success) instead of 101 when warnings are found. Note that it can be useful to combine -E and -W. This means -that all compiler warnings will produce failures (code 128) and all other -warnings will produce success (since 129 is changed to 0). +that all compiler warnings will produce failures (code 100) and all other +warnings will produce success (since 101 is changed to 0). -If there are both warnings and errors, errors win, so buildman returns 128. +If there are both warnings and errors, errors win, so buildman returns 100. The -y option is provided (for use with -s) to ignore the bountiful device-tree warnings. Similarly, -Y tells buildman to ignore the migration warnings. -- cgit