On Wednesday 01 September 2021 23:44:52 Pali Rohár wrote:
On Wednesday 01 September 2021 17:33:57 Tom Rini wrote:
On Wed, Sep 01, 2021 at 11:28:54PM +0200, Pali Rohár wrote:
On Wednesday 01 September 2021 17:17:06 Tom Rini wrote:
On Wed, Sep 01, 2021 at 11:05:45PM +0200, Pali Rohár wrote:
On Wednesday 01 September 2021 16:59:09 Tom Rini wrote:
On Mon, Aug 02, 2021 at 03:18:27PM +0200, Pali Rohár wrote:
> Including timestamp.h (either directly or transitionally) cause build > system to recompile binaries at every 'make' run. This has disadvantage > in U-Boot development as for every small change 'make' recompiles lot of > other irrelevant files which were not touched / changed. > > This patch series eliminate transitional / indirect usage of > timestamp.h by removing unneeded inclusion of header files, moving > timestamp values from macros to global variables, etc... > > After these patches, U-Boot tools are not recompiled by every 'make' run, > which decrease time for incremental U-Boot recompilation. > > Please test these patches, specially m68k and powerpc parts as I do not > have any of these boards. > > Patch series depend on this patch (now marked as accepted): > http://patchwork.ozlabs.org/project/uboot/patch/20210710111001.32325-1-pali@... > > Pali Rohár (11): > Remove #include <timestamp.h> from files which do not need it > Remove #include <version.h> from files which do not need it > efi_loader: Use directly version_string variable > version: Move version_string[] from version.h to version_string.h > m68k: mcf: Remove overloading version_string > version: Put version_string[] variable into section > .text_version_string > powerpc: mpc: Put U-Boot version string at correct place by linker > script > version: Do not make version_string[] variable as a weak > x86: quark: MRC: Remove U_BOOT_DATE and U_BOOT_TIME from debug log > version: Remove global macro U_BOOT_VERSION_STRING from version.h > Remove including timestamp.h in version.h
So, looking at https://source.denx.de/u-boot/u-boot/-/pipelines/8948 this fails to build for at least qemu-ppce500 and xtfpga. Over in doc/develop/ci_testing.rst we document how to run a world build. Please fix these build errors and re-submit, thanks.
Already happened about month ago https://patchwork.ozlabs.org/project/uboot/patch/20210808112038.7942-1-pali@...
As stated, following build command now passes: make CROSS_COMPILE=powerpc-linux-gnu- MCR3000_defconfig u-boot.bin
OK, I'll make sure to grab that. Note that xtfpga isn't PowerPC...
I saw only error https://source.denx.de/u-boot/u-boot/-/jobs/316601 and this should be fixed above patch. At least I got similar error for MCR3000_defconfig with new gcc before that.
But now after scrolling down I see that second xtfpga error https://source.denx.de/u-boot/u-boot/-/jobs/316614 But seems that in this UI is error log truncated. I see only
+xtensa-dc233c-elf-ld.bfd: section .text_version_string LMA [00000000fe021584,00000000fe0215c7] overlaps section .u_boot_list LMA [00000000fe021584,00000000fe021e6b]
Is there a way how to show full build log? And which defconfig and compiler is used? Because that error does not help me what is wrong here...
That's the full error log, from the linker, I believe. It's the xtfpga config for the xtensa architecture. It's one of the few that buildman won't fetch a good toolchain for so you'll want to look at tools/docker/Dockerfile and see we get it from https://github.com/foss-xtensa/toolchain/releases/download/2020.07/x86_64-20... if you don't have the CI builder container itself handy already.
So this is the only other build which failed, right? I suspect that there is some other bug in xtfpga linker script, that it missed specifying wildcard sections and this change triggered it.
I will try to look at it.
Just a quick look... https://source.denx.de/u-boot/u-boot/-/blob/master/arch/xtensa/cpu/u-boot.ld... Probably it is needed to specify .text_version_string section here, like is specified .text section there.
It is pity that in above gitlab build log is missing full command which produced that error as in its arguments could be something interesting, like path to linker script or compile flags...