[U-Boot] how to read the buildman report
Simon,
I need some help to understand the report of buildman. Use this example, when I build all arm and powerpc boards,
$ tools/buildman/buildman -b working_qoriq arm powerpc -s
Summary of 19 commits for 1023 boards (24 threads, 1 job per thread) 01: ls102xa: dcu: Add platform support for DCU on LS1021ATWR board arm: + tricorder_flash vf610twr tricorder powerpc: + taishan dlvision 02: video: dcu: Add DCU driver support 03: video: dcu: Add Sii9022A HDMI Transmitter support 04: arm: ls102xa: Add LETECH support for LS1021AQDS/TWR board 05: serial: lpuart: add 32-bit registers lpuart support 06: net: tsec: Remove tx snooping support from LS1 arm: vf610twr 07: arm: ls102xa: Add basic support for LS1021ATWR board 08: arm: ls102xa: Add basic support for LS1021AQDS board arm: + ls1021atwr_nor ls1021atwr_letech 09: driver/ddr/fsl: Add support of overriding chip select write leveling arm: + ls1021aqds_nor ls1021aqds_letech 10: driver/ddr/freescale: Fix DDR3 driver for ARM 11: driver/ddr/freescale: Add support of accumulate ECC 12: ls102xa: esdhc: Add esdhc support for LS102xA 13: ls102xa: etsec: Add etsec support for LS102xA 14: net: mdio: Use mb() to be compatible for both ARM and PowerPC 15: net: mdio: Add private MDIO read/write function 16: net: Merge asm/fsl_enet.h into fsl_mdio.h 17: ls102xa: i2c: Add i2c support for LS102xA 18: arm: ls102xa: Add Freescale LS102xA SoC support 19: patman: Only use git's --no-decorate when available
First, is the build supposed to be top down or bottom up? It looks like buildman starts to build from the last commit and works it way down. What I don't understand is the new board. Under patch 08 and 09, I see two boards failed. But these two boards don't exist until a later commit. Should I use --force-reconfig switch?
Second, when I see a failed board under a commit, is this commit causing the failure? It is not the case in my example. I see vf610twr failed under 01, but the actual failure is caused by commit 05.
York
Hi York,
On 14 August 2014 15:36, York Sun yorksun@freescale.com wrote:
Simon,
I need some help to understand the report of buildman. Use this example, when I build all arm and powerpc boards,
I assume you've checked out the README.
$ tools/buildman/buildman -b working_qoriq arm powerpc -s
Summary of 19 commits for 1023 boards (24 threads, 1 job per thread) 01: ls102xa: dcu: Add platform support for DCU on LS1021ATWR board arm: + tricorder_flash vf610twr tricorder powerpc: + taishan dlvision
This means that in commit 01 these boards fail to build.
02: video: dcu: Add DCU driver support
03: video: dcu: Add Sii9022A HDMI Transmitter support 04: arm: ls102xa: Add LETECH support for LS1021AQDS/TWR board 05: serial: lpuart: add 32-bit registers lpuart support 06: net: tsec: Remove tx snooping support from LS1 arm: vf610twr
This board got fixed by this commit.
07: arm: ls102xa: Add basic support for LS1021ATWR board 08: arm: ls102xa: Add basic support for LS1021AQDS board arm: + ls1021atwr_nor ls1021atwr_letech
This commit causes these board to fail, in addition to the previous ones.
09: driver/ddr/fsl: Add support of overriding chip select write leveling
arm: + ls1021aqds_nor ls1021aqds_letech10: driver/ddr/freescale: Fix DDR3 driver for ARM 11: driver/ddr/freescale: Add support of accumulate ECC 12: ls102xa: esdhc: Add esdhc support for LS102xA 13: ls102xa: etsec: Add etsec support for LS102xA 14: net: mdio: Use mb() to be compatible for both ARM and PowerPC 15: net: mdio: Add private MDIO read/write function 16: net: Merge asm/fsl_enet.h into fsl_mdio.h 17: ls102xa: i2c: Add i2c support for LS102xA 18: arm: ls102xa: Add Freescale LS102xA SoC support 19: patman: Only use git's --no-decorate when available
First, is the build supposed to be top down or bottom up? It looks like buildman starts to build from the last commit and works it way down. What I don't understand is the new board. Under patch 08 and 09, I see two boards failed. But these two boards don't exist until a later commit. Should I use --force-reconfig switch?
It builds from the oldest commit to the newest, and shows in that order.
buildman does not understand boards that are created during a series. This is a limitation. So you will get failures for commits that don't have the board.
Second, when I see a failed board under a commit, is this commit causing the failure? It is not the case in my example. I see vf610twr failed under 01, but the actual failure is caused by commit 05.
It seems that there is a problem for commit 01 also - perhaps just a warning?
Regards, Simon
On 08/14/2014 03:17 PM, Simon Glass wrote:
Hi York,
On 14 August 2014 15:36, York Sun <yorksun@freescale.com mailto:yorksun@freescale.com> wrote:
Simon, I need some help to understand the report of buildman. Use this example, when I build all arm and powerpc boards,I assume you've checked out the README.
Yes, but not the latest one merged.
$ tools/buildman/buildman -b working_qoriq arm powerpc -s Summary of 19 commits for 1023 boards (24 threads, 1 job per thread) 01: ls102xa: dcu: Add platform support for DCU on LS1021ATWR board arm: + tricorder_flash vf610twr tricorder powerpc: + taishan dlvisionThis means that in commit 01 these boards fail to build.
02: video: dcu: Add DCU driver support 03: video: dcu: Add Sii9022A HDMI Transmitter support 04: arm: ls102xa: Add LETECH support for LS1021AQDS/TWR board 05: serial: lpuart: add 32-bit registers lpuart support 06: net: tsec: Remove tx snooping support from LS1 arm: vf610twrThis board got fixed by this commit.
07: arm: ls102xa: Add basic support for LS1021ATWR board 08: arm: ls102xa: Add basic support for LS1021AQDS board arm: + ls1021atwr_nor ls1021atwr_letechThis commit causes these board to fail, in addition to the previous ones.
09: driver/ddr/fsl: Add support of overriding chip select write leveling arm: + ls1021aqds_nor ls1021aqds_letech 10: driver/ddr/freescale: Fix DDR3 driver for ARM 11: driver/ddr/freescale: Add support of accumulate ECC 12: ls102xa: esdhc: Add esdhc support for LS102xA 13: ls102xa: etsec: Add etsec support for LS102xA 14: net: mdio: Use mb() to be compatible for both ARM and PowerPC 15: net: mdio: Add private MDIO read/write function 16: net: Merge asm/fsl_enet.h into fsl_mdio.h 17: ls102xa: i2c: Add i2c support for LS102xA 18: arm: ls102xa: Add Freescale LS102xA SoC support 19: patman: Only use git's --no-decorate when available First, is the build supposed to be top down or bottom up? It looks like buildman starts to build from the last commit and works it way down. What I don't understand is the new board. Under patch 08 and 09, I see two boards failed. But these two boards don't exist until a later commit. Should I use --force-reconfig switch?It builds from the oldest commit to the newest, and shows in that order.
Doesn't looks so. The 19 is the oldest. The 18 is the first commit I am testing. The 01 is the newest.
buildman does not understand boards that are created during a series. This is a limitation. So you will get failures for commits that don't have the board.
That explains it.
Second, when I see a failed board under a commit, is this commit causing the failure? It is not the case in my example. I see vf610twr failed under 01, but the actual failure is caused by commit 05.It seems that there is a problem for commit 01 also - perhaps just a warning?
I think the build order is backward now. Before the latest merge, it did build from the oldest to the newest. I confirmed that by checking out v2014.10-rc1.
York
Hi York,
On 14 August 2014 16:33, York Sun yorksun@freescale.com wrote:
On 08/14/2014 03:17 PM, Simon Glass wrote:
Hi York,
On 14 August 2014 15:36, York Sun <yorksun@freescale.com mailto:yorksun@freescale.com> wrote:
Simon, I need some help to understand the report of buildman. Use thisexample, when I
build all arm and powerpc boards,I assume you've checked out the README.
Yes, but not the latest one merged.
$ tools/buildman/buildman -b working_qoriq arm powerpc -s Summary of 19 commits for 1023 boards (24 threads, 1 job per thread) 01: ls102xa: dcu: Add platform support for DCU on LS1021ATWR board arm: + tricorder_flash vf610twr tricorder powerpc: + taishan dlvisionThis means that in commit 01 these boards fail to build.
02: video: dcu: Add DCU driver support 03: video: dcu: Add Sii9022A HDMI Transmitter support 04: arm: ls102xa: Add LETECH support for LS1021AQDS/TWR board 05: serial: lpuart: add 32-bit registers lpuart support 06: net: tsec: Remove tx snooping support from LS1 arm: vf610twrThis board got fixed by this commit.
07: arm: ls102xa: Add basic support for LS1021ATWR board 08: arm: ls102xa: Add basic support for LS1021AQDS board arm: + ls1021atwr_nor ls1021atwr_letechThis commit causes these board to fail, in addition to the previous ones.
09: driver/ddr/fsl: Add support of overriding chip select writeleveling
arm: + ls1021aqds_nor ls1021aqds_letech 10: driver/ddr/freescale: Fix DDR3 driver for ARM 11: driver/ddr/freescale: Add support of accumulate ECC 12: ls102xa: esdhc: Add esdhc support for LS102xA 13: ls102xa: etsec: Add etsec support for LS102xA 14: net: mdio: Use mb() to be compatible for both ARM and PowerPC 15: net: mdio: Add private MDIO read/write function 16: net: Merge asm/fsl_enet.h into fsl_mdio.h 17: ls102xa: i2c: Add i2c support for LS102xA 18: arm: ls102xa: Add Freescale LS102xA SoC support 19: patman: Only use git's --no-decorate when available First, is the build supposed to be top down or bottom up? It lookslike buildman
starts to build from the last commit and works it way down. What Idon't
understand is the new board. Under patch 08 and 09, I see two boardsfailed. But
these two boards don't exist until a later commit. Should I use--force-reconfig
switch?It builds from the oldest commit to the newest, and shows in that order.
Doesn't looks so. The 19 is the oldest. The 18 is the first commit I am testing. The 01 is the newest.
Well you have found a bug!
buildman does not understand boards that are created during a series.
This is a
limitation. So you will get failures for commits that don't have the
board.
That explains it.
Second, when I see a failed board under a commit, is this commitcausing the
failure? It is not the case in my example. I see vf610twr failedunder 01, but
the actual failure is caused by commit 05.It seems that there is a problem for commit 01 also - perhaps just a
warning?
I think the build order is backward now. Before the latest merge, it did build from the oldest to the newest. I confirmed that by checking out v2014.10-rc1.
Ah, yes I changed something during the 'git log' refactoring. I'll submit a fix as that would be very confusing. Thanks for testing this. I should have left those last two patches out until I heard from you.
Regards, Simon
participants (2)
-
Simon Glass -
York Sun