|
|
|
@ -22,16 +22,14 @@ help for anyone working with >10 patches at a time. |
|
|
|
|
Caveats |
|
|
|
|
======= |
|
|
|
|
|
|
|
|
|
Buildman is still in its infancy. It is already a very useful tool, but |
|
|
|
|
expect to find problems and send patches. |
|
|
|
|
|
|
|
|
|
Buildman can be stopped and restarted, in which case it will continue |
|
|
|
|
where it left off. This should happen cleanly and without side-effects. |
|
|
|
|
If not, it is a bug, for which a patch would be welcome. |
|
|
|
|
|
|
|
|
|
Buildman gets so tied up in its work that it can ignore the outside world. |
|
|
|
|
You may need to press Ctrl-C several times to quit it. Also it will print |
|
|
|
|
out various exceptions when stopped. |
|
|
|
|
out various exceptions when stopped. You may have to kill it since the |
|
|
|
|
Ctrl-C handling is somewhat broken. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Theory of Operation |
|
|
|
@ -46,6 +44,13 @@ 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. |
|
|
|
|
|
|
|
|
|
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. |
|
|
|
|
|
|
|
|
|
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 |
|
|
|
@ -420,10 +425,7 @@ Tool chain test: OK |
|
|
|
|
|
|
|
|
|
Or download them all from kernel.org and move them to /toolchains directory, |
|
|
|
|
|
|
|
|
|
$ for i in aarch64 arm avr32 i386 m68k microblaze mips or32 powerpc sparc |
|
|
|
|
do |
|
|
|
|
./tools/buildman/buildman --fetch-arch $i |
|
|
|
|
done |
|
|
|
|
$ ./tools/buildman/buildman --fetch-arch all |
|
|
|
|
$ sudo mkdir -p /toolchains |
|
|
|
|
$ sudo mv ~/.buildman-toolchains/*/* /toolchains/ |
|
|
|
|
|
|
|
|
@ -440,8 +442,8 @@ nios2: http://sourcery.mentor.com/public/gnu_toolchain/nios2-linux-gnu/ |
|
|
|
|
sh: http://sourcery.mentor.com/public/gnu_toolchain/sh-linux-gnu/ |
|
|
|
|
renesas-4.4-200-sh-linux-gnu-i686-pc-linux-gnu.tar.bz2 |
|
|
|
|
|
|
|
|
|
Note openrisc kernel.org toolchain is out of date, download latest one from |
|
|
|
|
http://opencores.org/or1k/OpenRISC_GNU_tool_chain#Prebuilt_versions, eg: |
|
|
|
|
Note openrisc kernel.org toolchain is out of date. Download the latest one from |
|
|
|
|
http://opencores.org/or1k/OpenRISC_GNU_tool_chain#Prebuilt_versions - eg: |
|
|
|
|
ftp://ocuser:ocuser@openrisc.opencores.org/toolchain/gcc-or1k-elf-4.8.1-x86.tar.bz2. |
|
|
|
|
|
|
|
|
|
Buildman should now be set up to use your new toolchain. |
|
|
|
@ -521,7 +523,7 @@ Building 18 commits for 1059 boards (4 threads, 1 job per thread) |
|
|
|
|
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 an hour and 15 minutes. Use this time to buy a faster computer. |
|
|
|
|
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 |
|
|
|
@ -556,7 +558,8 @@ the build is still in progress so many boards are not built yet (use -u to |
|
|
|
|
see which ones). But still we can see a few failures. The galaxy5200_LOWBOOT |
|
|
|
|
never builds correctly. This could be a problem with our toolchain, or it |
|
|
|
|
could be a bug in the upstream. The good news is that we probably don't need |
|
|
|
|
to blame our commits. The bad news is it isn't tested on that board. |
|
|
|
|
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, |
|
|
|
@ -585,19 +588,20 @@ So the problem is in lcd.c, due to missing cache operations. This information |
|
|
|
|
should be enough to work out what that commit is doing to break these |
|
|
|
|
boards. (In this case pxa did not have cache operations defined). |
|
|
|
|
|
|
|
|
|
If you see error lines marked with - that means that the errors were fixed |
|
|
|
|
If you see error lines marked with '-', that means that the errors were fixed |
|
|
|
|
by that commit. Sometimes commits can be in the wrong order, so that a |
|
|
|
|
breakage is introduced for a few commits and fixed by later commits. This |
|
|
|
|
shows up clearly with buildman. You can then reorder the commits and try |
|
|
|
|
again. |
|
|
|
|
|
|
|
|
|
At commit 16, the error moves - you can see that the old error at line 120 |
|
|
|
|
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. |
|
|
|
|
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. |
|
|
|
@ -619,8 +623,8 @@ The full build output in this case is available in: |
|
|
|
|
|
|
|
|
|
sizes: Shows image size information. |
|
|
|
|
|
|
|
|
|
It is possible to get the build output there also. Use the -k option for |
|
|
|
|
this. In that case you will also see some output files, like: |
|
|
|
|
It is possible to get the build binary output there also. Use the -k option |
|
|
|
|
for this. In that case you will also see some output files, like: |
|
|
|
|
|
|
|
|
|
System.map toolchain u-boot u-boot.bin u-boot.map autoconf.mk |
|
|
|
|
(also SPL versions u-boot-spl and u-boot-spl.bin if available) |
|
|
|
@ -631,7 +635,7 @@ Checking Image Sizes |
|
|
|
|
|
|
|
|
|
A key requirement for U-Boot is that you keep code/data size to a minimum. |
|
|
|
|
Where a new feature increases this noticeably it should normally be put |
|
|
|
|
behind a CONFIG flag so that boards can leave it off and keep the image |
|
|
|
|
behind a CONFIG flag so that boards can leave it disabled and keep the image |
|
|
|
|
size more or less the same with each new release. |
|
|
|
|
|
|
|
|
|
To check the impact of your commits on image size, use -S. For example: |
|
|
|
@ -670,12 +674,13 @@ A useful option is --step which lets you skip some commits. For example |
|
|
|
|
--step 2 will show the image sizes for only every 2nd commit (so it will |
|
|
|
|
compare the image sizes of the 1st, 3rd, 5th... commits). You can also use |
|
|
|
|
--step 0 which will compare only the first and last commits. This is useful |
|
|
|
|
for an overview of how your entire series affects code size. |
|
|
|
|
for an overview of how your entire series affects code size. It will build |
|
|
|
|
only the upstream commit and your final branch commit. |
|
|
|
|
|
|
|
|
|
You can also use -d to see a detailed size breakdown for each board. This |
|
|
|
|
list is sorted in order from largest growth to largest reduction. |
|
|
|
|
|
|
|
|
|
It is possible to go a little further with the -B option (--bloat). This |
|
|
|
|
It is even possible to go a little further with the -B option (--bloat). This |
|
|
|
|
shows where U-Boot has bloated, breaking the size change down to the function |
|
|
|
|
level. Example output is below: |
|
|
|
|
|
|
|
|
@ -798,9 +803,9 @@ $ ./tools/buildman/buildman -b us-mem4 -sSdB |
|
|
|
|
... |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This shows that commit 19 has increased text size for arm (although only one |
|
|
|
|
board was built) and by 96 bytes for powerpc. This increase was offset in both |
|
|
|
|
cases by reductions in rodata and data/bss. |
|
|
|
|
This shows that commit 19 has reduced codesize for arm slightly and increased |
|
|
|
|
it for powerpc. This increase was offset in by reductions in rodata and |
|
|
|
|
data/bss. |
|
|
|
|
|
|
|
|
|
Shown below the summary lines are the sizes for each board. Below each board |
|
|
|
|
are the sizes for each function. This information starts with: |
|
|
|
@ -1063,6 +1068,8 @@ 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. |
|
|
|
|
|
|
|
|
|
A specific problem to fix is that Ctrl-C does not exit buildman cleanly when |
|
|
|
|
multiple builder threads are active. |
|
|
|
|
|
|
|
|
|
Credits |
|
|
|
|
======= |
|
|
|
|