[Buildroot] Analysis of defconfig build failures

[Buildroot] Analysis of defconfig build failures

[Thomas Petazzoni]

Hello,

Today, I analyzed the defconfig build failures of
https://gitlab.com/buildroot.org/buildroot/pipelines/27617503. I fixed
a number of them, except two:

 - Problem of U-Boot failing to build due to a clash between the libfdt
   headers part of U-Boot, and the libfdt headers installed by our
   host-dtc package. We already made several changes in uboot.mk to try
   to fix this, but it still doesn't work properly.

   Does anybody has an idea ? Thomas DS, you already worked on this
   issue (you're the author of commit
   baae5156ce37e8b2775f04710f7d1c8e97e4114c). Any clue ?

   The problem is fixed in U-Boot 2018.01 but present in 2017.11.
   However, we have a number of vendor-provided U-Boot, and it's not
   necessarily easy to upgrade all defconfigs to use at least 2018.01.

 - Problem of recent U-Boot that needs host-bison to build kconfig.
   Yann posted a patch series to make bison and flex hard requirements
   of Buildroot. Do we want to go this way ?

Here is the detailed list of the defconfig build failures:

 - Filesystem too small

   raspberrypi2_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314938

   Fixed by
   https://git.buildroot.org/buildroot/commit/?id=272bf797c9c4d67154316619ff6fcadb63d38511

 - U-Boot FDT headers issues

   engicam_imx6qdl_icore_qt5_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314813

   at91sam9x5ek_mmc_dev_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314788

   atmel_sama5d4_xplained_mmc_dev_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314800

   atmel_sama5d27_som1_ek_mmc_dev_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314789

   atmel_sama5d3_xplained_mmc_dev_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314795

   atmel_sama5d4_xplained_dev_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314798

   at91sam9x5ek_dev_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314786

   atmel_sama5d3_xplained_dev_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314793

   atmel_sama5d2_xplained_mmc_dev_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314791

   orangepi_zero_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314891

   olimex_a20_olinuxino_lime2_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314876

   freescale_imx6qsabreauto_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314820

   freescale_imx6sxsabresd_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314822

   freescale_imx6dlsabreauto_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314818

   freescale_imx8mqevk_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314824

   linksprite_pcduino_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314843

   atmel_sama5d3_xplained_mmc_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314794

   zynq_zybo_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314970

   freescale_imx7dsabresd_defconfig
   https://gitlab.com/buildroot.org/buildroot/pipelines/27617503/failures

   freescale_imx6qsabresd_defconfig
   https://gitlab.com/buildroot.org/buildroot/pipelines/27617503/failures

   amarula_vyasa_rk3288_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314767

   engicam_imx6qdl_icore_rqs_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314814

   freescale_imx6dlsabresd_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314819

   bananapro_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314804

   orangepi_pc_defconfig
   https://gitlab.com/buildroot.org/buildroot/pipelines/27617503/failures

   olimex_a20_olinuxino_lime_mali_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314878

   engicam_imx6ul_geam_defconfig
   https://gitlab.com/buildroot.org/buildroot/pipelines/27617503/failures

   olimex_a20_olinuxino_lime_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314877

   olimex_a10_olinuxino_lime_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314871

   nanopi_neo_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314855

   bananapi_m2_plus_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314802

   bananapi_m1_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314801

   engicam_imx6ul_isiot_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314816

   orangepi_one_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314884

   nanopi_m1_plus_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314853

   orangepi_plus_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314888

   engicam_imx6qdl_icore_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314812

   atmel_sama5d2_xplained_mmc_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314790

   zynq_zc706_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314968

   atmel_sama5d4_xplained_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314797

   olimex_a20_olinuxino_micro_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314879

   olimex_a13_olinuxino_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314873

   zynq_zed_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314969

   roseapplepi_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314944

   nanopi_m1_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314852

   atmel_sama5d3_xplained_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314792

   zynq_microzed_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314967

   atmel_sama5d4_xplained_mmc_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314799

   cubieboard2_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314811

   beagleboardx15_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314805

   at91sam9x5ek_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314785

   atmel_sama5d3xek_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314796

   orangepi_zero_plus2_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314892

   at91sam9x5ek_mmc_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314787

   nitrogen8m_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314866

   solidrun_macchiatobin_marvell_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314956

   arcturus_ucls1012a_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314768

   sheevaplug_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314946

 - ATF doesn't build

   arm_juno_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314771

   Fixed by
   https://git.buildroot.org/buildroot/commit/?id=395bc11dde5b4ef034118a9be568131f134daaa3.

 - Overlay doesn't exist

   snps_archs38_vdk_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314952

   Fixed in
   https://git.buildroot.org/buildroot/commit/?id=f9707ac5840df8bd707a3fad9894441c34c2cf79.

 - U-Boot needs Bison

   asus_tinker_rk3288_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314775

   The proposal from Yann in
   http://patchwork.ozlabs.org/project/buildroot/list/?series=59260 is
   to make flex and bison hard requirements of Buildroot. We need to
   take a decision on this.

 - Kernel needs OpenSSL

   imx6ulpico_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314839

   imx7dpico_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314841

   mx51evk_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314847

   orangepi_lite_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314883

   Fixed by
   https://git.buildroot.org/buildroot/commit/?id=6ee74275367d565ee988f92a93e64002e6f529ef.

 - Weird "ERROR: Invalid size suffix 'B' in '512B'" issue

   ts7680_defconfig
   https://gitlab.com/buildroot.org/buildroot/-/jobs/88314963

   Fixed by
   https://git.buildroot.org/buildroot/commit/?id=f1bdb63ff4fddc53cdb43ad670dbf6f3401c19ca.

 - Failed because of Gitlab issues. I restarted them, but didn't wait
   for their new build to complete.

   lego_ev3_defconfig
   raspberrypi0w_defconfig
   orangepi_pc_plus_defconfig
   mx6cubox_defconfig
   qemu_mips32r2el_malta_defconfig
   armadeus_apf27_defconfig

Best regards,

Thomas Petazzoni
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] Analysis of defconfig build failures

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@bootlin.com> writes:

 > Hello,
 > Today, I analyzed the defconfig build failures of
 > https://gitlab.com/buildroot.org/buildroot/pipelines/27617503. I fixed
 > a number of them, except two:

Thanks for doing that!

 >  - Problem of U-Boot failing to build due to a clash between the libfdt
 >    headers part of U-Boot, and the libfdt headers installed by our
 >    host-dtc package. We already made several changes in uboot.mk to try
 >    to fix this, but it still doesn't work properly.

 >    Does anybody has an idea ? Thomas DS, you already worked on this
 >    issue (you're the author of commit
 >    baae5156ce37e8b2775f04710f7d1c8e97e4114c). Any clue ?

 >    The problem is fixed in U-Boot 2018.01 but present in 2017.11.
 >    However, we have a number of vendor-provided U-Boot, and it's not
 >    necessarily easy to upgrade all defconfigs to use at least 2018.01.

Perhaps we could backport the changes and add as patches for the
affected defconfigs?

What is needed? Just the libfdt.h -> linux/libfdt.h you reported?

commit b08c8c4870831c9315dcae237772238e80035bd5
Author: Masahiro Yamada <yamada.masahiro@socionext.com>
Date:   Mon Mar 5 01:20:11 2018 +0900

    libfdt: move headers to <linux/libfdt.h> and <linux/libfdt_env.h>

    Thomas reported U-Boot failed to build host tools if libfdt-devel
    package is installed because tools include libfdt headers from
    /usr/include/ instead of using internal ones.


 >  - Problem of recent U-Boot that needs host-bison to build kconfig.
 >    Yann posted a patch series to make bison and flex hard requirements
 >    of Buildroot. Do we want to go this way ?

Sorry, I haven't looked at that series yet. If various packages start
needing this, and there aren't any version dependencies, then requiring
bison and flex is imho not a big problem (E.G. they are generally
available on all distributions).



 >    sheevaplug_defconfig
 >    https://gitlab.com/buildroot.org/buildroot/-/jobs/88314946

I still have this board somewhere. I'll take a look at bumping u-boot.

-- 
Bye, Peter Korsgaard

[Buildroot] Analysis of defconfig build failures

[Thomas Petazzoni]

Hello,

On Wed, 15 Aug 2018 21:09:19 +0200, Peter Korsgaard wrote:

>  >    The problem is fixed in U-Boot 2018.01 but present in 2017.11.
>  >    However, we have a number of vendor-provided U-Boot, and it's not
>  >    necessarily easy to upgrade all defconfigs to use at least 2018.01.  
> 
> Perhaps we could backport the changes and add as patches for the
> affected defconfigs?

The problem is that it will still affect anyone doing a U-Boot build,
outside of the defconfigs.

> What is needed? Just the libfdt.h -> linux/libfdt.h you reported?

I am not sure what is needed exactly.

>  >  - Problem of recent U-Boot that needs host-bison to build kconfig.
>  >    Yann posted a patch series to make bison and flex hard requirements
>  >    of Buildroot. Do we want to go this way ?  
> 
> Sorry, I haven't looked at that series yet. If various packages start
> needing this, and there aren't any version dependencies, then requiring
> bison and flex is imho not a big problem (E.G. they are generally
> available on all distributions).

We've been having a discussion on this in a separate thread (search
"[2/3,v3] linux: kconfig needs host-{flex, bison} to build the
configurators ").

>  >    sheevaplug_defconfig
>  >    https://gitlab.com/buildroot.org/buildroot/-/jobs/88314946  
> 
> I still have this board somewhere. I'll take a look at bumping u-boot.

OK, thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] Analysis of defconfig build failures

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@bootlin.com> writes:

 > Hello,
 > On Wed, 15 Aug 2018 21:09:19 +0200, Peter Korsgaard wrote:

 >> >    The problem is fixed in U-Boot 2018.01 but present in 2017.11.
 >> >    However, we have a number of vendor-provided U-Boot, and it's not
 >> >    necessarily easy to upgrade all defconfigs to use at least 2018.01.  
 >> 
 >> Perhaps we could backport the changes and add as patches for the
 >> affected defconfigs?

 > The problem is that it will still affect anyone doing a U-Boot build,
 > outside of the defconfigs.

Ok. Is this a new failure introduced by something we do
wrong/differently in Buildroot, or just something that is broken by
building with newer compilers?


 >> What is needed? Just the libfdt.h -> linux/libfdt.h you reported?

 > I am not sure what is needed exactly.

Ok :/


 >> Sorry, I haven't looked at that series yet. If various packages start
 >> needing this, and there aren't any version dependencies, then requiring
 >> bison and flex is imho not a big problem (E.G. they are generally
 >> available on all distributions).

 > We've been having a discussion on this in a separate thread (search
 > "[2/3,v3] linux: kconfig needs host-{flex, bison} to build the
 > configurators ").

Ok, thanks.


 >> >    sheevaplug_defconfig
 >> >    https://gitlab.com/buildroot.org/buildroot/-/jobs/88314946  
 >> 
 >> I still have this board somewhere. I'll take a look at bumping u-boot.

 > OK, thanks!

You're welcome, I'm doing a build with v2018.07 as we speak.

-- 
Bye, Peter Korsgaard

[Buildroot] Analysis of defconfig build failures

[Thomas Petazzoni]

Hello,

On Wed, 15 Aug 2018 23:27:17 +0200, Peter Korsgaard wrote:

>  >> Perhaps we could backport the changes and add as patches for the
>  >> affected defconfigs?  
> 
>  > The problem is that it will still affect anyone doing a U-Boot build,
>  > outside of the defconfigs.  
> 
> Ok. Is this a new failure introduced by something we do
> wrong/differently in Buildroot, or just something that is broken by
> building with newer compilers?

I don't think it's related to building with new compilers. It's just
some U-Boot versions that are broken if libfdt headers are already
available in the include path.

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] Analysis of defconfig build failures

[Thomas De Schampheleire]

Hi,

2018-08-16 0:18 GMT+02:00 Thomas Petazzoni <thomas.petazzoni@bootlin.com>:
> Hello,
>
> On Wed, 15 Aug 2018 23:27:17 +0200, Peter Korsgaard wrote:
>
>>  >> Perhaps we could backport the changes and add as patches for the
>>  >> affected defconfigs?
>>
>>  > The problem is that it will still affect anyone doing a U-Boot build,
>>  > outside of the defconfigs.
>>
>> Ok. Is this a new failure introduced by something we do
>> wrong/differently in Buildroot, or just something that is broken by
>> building with newer compilers?
>
> I don't think it's related to building with new compilers. It's just
> some U-Boot versions that are broken if libfdt headers are already
> available in the include path.
>

I can try to have a look somewhere next week.

From the previous solution, I have a feeling that we can only go so
far in trying to solve the issue from Buildroot. We did already one
thing, and it seems insufficient for some u-boot versions.
There is a risk that what we do to fix these new failures, may break
some of those that work today.
We could implement some kind of detection to see how we need to solve
the issue depending on the u-boot at hand, but it could be cumbersome.

An alternative solution is to document the known solution to this
problem (the patches). We can apply these patches to the defconfigs
inside buildroot, and let users with custom u-boots apply the patches
themselves (i.e. make them aware from release notes or documentation
but don't solve it automatically).

Best regards,
Thomas

[Buildroot] Analysis of defconfig build failures

[Thomas Petazzoni]

Hello,

On Thu, 16 Aug 2018 21:52:25 +0200, Thomas De Schampheleire wrote:

> > I don't think it's related to building with new compilers. It's just
> > some U-Boot versions that are broken if libfdt headers are already
> > available in the include path.
> 
> I can try to have a look somewhere next week.

OK, thanks.

> From the previous solution, I have a feeling that we can only go so
> far in trying to solve the issue from Buildroot. We did already one
> thing, and it seems insufficient for some u-boot versions.
> There is a risk that what we do to fix these new failures, may break
> some of those that work today.
> We could implement some kind of detection to see how we need to solve
> the issue depending on the u-boot at hand, but it could be cumbersome.

Indeed.

> An alternative solution is to document the known solution to this
> problem (the patches). We can apply these patches to the defconfigs
> inside buildroot, and let users with custom u-boots apply the patches
> themselves (i.e. make them aware from release notes or documentation
> but don't solve it automatically).

That would be an option yes, but not the nicest one. But still better
than having all the defconfigs failing like they are today :/

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] Analysis of defconfig build failures

[Thomas De Schampheleire]

Hi,
El jue., 16 ago. 2018 a las 22:06, Thomas Petazzoni
(<thomas.petazzoni@bootlin.com>) escribi?:
>
> Hello,
>
> On Thu, 16 Aug 2018 21:52:25 +0200, Thomas De Schampheleire wrote:
>
> > > I don't think it's related to building with new compilers. It's just
> > > some U-Boot versions that are broken if libfdt headers are already
> > > available in the include path.
> >
> > I can try to have a look somewhere next week.
>
> OK, thanks.
>
> > From the previous solution, I have a feeling that we can only go so
> > far in trying to solve the issue from Buildroot. We did already one
> > thing, and it seems insufficient for some u-boot versions.
> > There is a risk that what we do to fix these new failures, may break
> > some of those that work today.
> > We could implement some kind of detection to see how we need to solve
> > the issue depending on the u-boot at hand, but it could be cumbersome.
>
> Indeed.
>
> > An alternative solution is to document the known solution to this
> > problem (the patches). We can apply these patches to the defconfigs
> > inside buildroot, and let users with custom u-boots apply the patches
> > themselves (i.e. make them aware from release notes or documentation
> > but don't solve it automatically).
>
> That would be an option yes, but not the nicest one. But still better
> than having all the defconfigs failing like they are today :/
>


I did an analysis of the first defconfig () and came to following
patch that fixes the problem:

diff --git a/boot/uboot/uboot.mk b/boot/uboot/uboot.mk
index bddafe234d..4d34c55827 100644
--- a/boot/uboot/uboot.mk
+++ b/boot/uboot/uboot.mk
@@ -197,6 +197,9 @@ UBOOT_POST_PATCH_HOOKS += UBOOT_APPLY_LOCAL_PATCHES
 define UBOOT_FIXUP_LIBFDT_INCLUDE
     if [ -d $(@D)/scripts/dtc/libfdt ]; then \
         $(SED)
's%-I$$(srctree)/lib/libfdt%-I$$(srctree)/scripts/dtc/libfdt%'
$(@D)/tools/Makefile; \
+    elif [ -f $(@D)/include/libfdt_env.h ]; then \
+        $(SED) '\%#define _LIBFDT_ENV_H%a\
+        #define LIBFDT_ENV_H' $(@D)/include/libfdt_env.h; \
     fi
 endef
 UBOOT_POST_PATCH_HOOKS += UBOOT_FIXUP_LIBFDT_INCLUDE

The issue is that different versions of libfdt_env.h have different
include guards. In uboot 2017.07 the include guard starts with
underscore (_LIBFDT_ENV_H) but in output/host/include it does not.
The problem is thus solved by defining both symbols in the 'good'
libfdt_env.h, preventing any further inclusion of another
libfdt_env.h.

I tried solving the problem differently in the u-boot sources, i.e.
replacing -idirafter with -isystem, removing an -idirafterinclude,
adding an -Iinclude, etc. but it all came down to other problems
caused by horror in the u-boot source tree.

Due to the 'elif', newer u-boots that have scripts/dtc/libfdt should
not regress.
I still need to do checking of other defconfigs to see if they all are
solved by this patch.

/Thomas

[Buildroot] Analysis of defconfig build failures

[Thomas De Schampheleire]

Small update:

El jue., 23 ago. 2018 a las 21:49, Thomas De Schampheleire
(<patrickdepinguin+buildroot@gmail.com>) escribi?:
>
> Hi,
> El jue., 16 ago. 2018 a las 22:06, Thomas Petazzoni
> (<thomas.petazzoni@bootlin.com>) escribi?:
> >
> > Hello,
> >
> > On Thu, 16 Aug 2018 21:52:25 +0200, Thomas De Schampheleire wrote:
> >
> > > > I don't think it's related to building with new compilers. It's just
> > > > some U-Boot versions that are broken if libfdt headers are already
> > > > available in the include path.
> > >
> > > I can try to have a look somewhere next week.
> >
> > OK, thanks.
> >
> > > From the previous solution, I have a feeling that we can only go so
> > > far in trying to solve the issue from Buildroot. We did already one
> > > thing, and it seems insufficient for some u-boot versions.
> > > There is a risk that what we do to fix these new failures, may break
> > > some of those that work today.
> > > We could implement some kind of detection to see how we need to solve
> > > the issue depending on the u-boot at hand, but it could be cumbersome.
> >
> > Indeed.
> >
> > > An alternative solution is to document the known solution to this
> > > problem (the patches). We can apply these patches to the defconfigs
> > > inside buildroot, and let users with custom u-boots apply the patches
> > > themselves (i.e. make them aware from release notes or documentation
> > > but don't solve it automatically).
> >
> > That would be an option yes, but not the nicest one. But still better
> > than having all the defconfigs failing like they are today :/
> >
>
>
> I did an analysis of the first defconfig () and came to following
> patch that fixes the problem:
>
> diff --git a/boot/uboot/uboot.mk b/boot/uboot/uboot.mk
> index bddafe234d..4d34c55827 100644
> --- a/boot/uboot/uboot.mk
> +++ b/boot/uboot/uboot.mk
> @@ -197,6 +197,9 @@ UBOOT_POST_PATCH_HOOKS += UBOOT_APPLY_LOCAL_PATCHES
>  define UBOOT_FIXUP_LIBFDT_INCLUDE
>      if [ -d $(@D)/scripts/dtc/libfdt ]; then \
>          $(SED)
> 's%-I$$(srctree)/lib/libfdt%-I$$(srctree)/scripts/dtc/libfdt%'
> $(@D)/tools/Makefile; \
> +    elif [ -f $(@D)/include/libfdt_env.h ]; then \
> +        $(SED) '\%#define _LIBFDT_ENV_H%a\
> +        #define LIBFDT_ENV_H' $(@D)/include/libfdt_env.h; \
>      fi
>  endef
>  UBOOT_POST_PATCH_HOOKS += UBOOT_FIXUP_LIBFDT_INCLUDE
>

Above patch works for engicam_imx6qdl_icore_qt5_defconfig.
I extended the patch to apply the same fixup to libfdt.h to fix the
second defconfig, at91sam9x5ek_mmc_dev_defconfig.

diff --git a/boot/uboot/uboot.mk b/boot/uboot/uboot.mk
index bddafe234d..af977a99a5 100644
--- a/boot/uboot/uboot.mk
+++ b/boot/uboot/uboot.mk
@@ -197,6 +197,11 @@ UBOOT_POST_PATCH_HOOKS += UBOOT_APPLY_LOCAL_PATCHES
 define UBOOT_FIXUP_LIBFDT_INCLUDE
        if [ -d $(@D)/scripts/dtc/libfdt ]; then \
                $(SED)
's%-I$$(srctree)/lib/libfdt%-I$$(srctree)/scripts/dtc/libfdt%'
$(@D)/tools/Makefile; \
+       elif [ -f $(@D)/include/libfdt_env.h ]; then \
+               $(SED) '\%#define _LIBFDT_ENV_H%a\
+               #define LIBFDT_ENV_H' $(@D)/include/libfdt_env.h; \
+               $(SED) '\%#define _LIBFDT_H%a\
+               #define LIBFDT_H' $(@D)/include/libfdt.h; \
        fi
 endef
 UBOOT_POST_PATCH_HOOKS += UBOOT_FIXUP_LIBFDT_INCLUDE


Sadly, for the third defconfig, a problem arises:
atmel_sama5d4_xplained_mmc_dev_defconfig
Error now is:

dtc  -O dtb -o arch/arm/dts/at91-sama5d4_xplained.dtb -b 0 -i
arch/arm/dts/ -Wno-unit_address_vs_reg -d
arch/arm/dts/.at91-sama5d4_xplained.dtb.d.dtc.tmp
arch/arm/dts/.at91-sama5d4_xplained.dtb.dts.tmp

arch/arm/dts/at91-sama5d4_xplained.dtb: Warning (unit_address_format):
/sram at 00210000: unit name should not have leading 0s
arch/arm/dts/at91-sama5d4_xplained.dtb: Warning (unit_address_format):
/ahb/gadget at 00400000: unit name should not have leading 0s
arch/arm/dts/at91-sama5d4_xplained.dtb: Warning (unit_address_format):
/ahb/ohci at 00500000: unit name should not have leading 0s
arch/arm/dts/at91-sama5d4_xplained.dtb: Warning (unit_address_format):
/ahb/ehci at 00600000: unit name should not have leading 0s
arch/arm/dts/at91-sama5d4_xplained.dtb: Warning (unit_address_format):
/ahb/cache-controller at 00a00000: unit name should not have leading 0s
arch/arm/dts/at91-sama5d4_xplained.dtb: Warning (unique_unit_address):
/ahb/apb/gpio at fc06a000: duplicate unit-address (also used in node
/ahb/apb/pinctrl at fc06a000)
dtc: livetree.c:438: propval_cell: Assertion `prop->val.len ==
sizeof(cell_t)' failed.
fish: '../../host/bin/dtc  -O dtb -o a?' terminated by signal SIGABRT (Abort)


The 'dtc' in question is the one from output/host/bin/dtc.
If I change the command to use 'dtc' from my host, there is no error.
There must be an issue in using the header files from one thing but
then executing a dtc that was compiled against other header files.
Bweeuh.

So (this) uboot has some local fdt header files, but expects dtc to be
available externally. And when we force the usage of the local header
files, we get errors.

Not sure how to proceed yet... Either try to force usage of the
include files from output/host/  but they may not always be available,
plus I think that in some cases exactly this caused troubles.

/Thomas

[Buildroot] Analysis of defconfig build failures

[Thomas De Schampheleire]

El s?b., 25 ago. 2018 a las 22:21, Thomas De Schampheleire
(<patrickdepinguin+buildroot@gmail.com>) escribi?:
>
> Small update:
>
> El jue., 23 ago. 2018 a las 21:49, Thomas De Schampheleire
> (<patrickdepinguin+buildroot@gmail.com>) escribi?:
> >
> > Hi,
> > El jue., 16 ago. 2018 a las 22:06, Thomas Petazzoni
> > (<thomas.petazzoni@bootlin.com>) escribi?:
> > >
> > > Hello,
> > >
> > > On Thu, 16 Aug 2018 21:52:25 +0200, Thomas De Schampheleire wrote:
> > >
> > > > > I don't think it's related to building with new compilers. It's just
> > > > > some U-Boot versions that are broken if libfdt headers are already
> > > > > available in the include path.
> > > >
> > > > I can try to have a look somewhere next week.
> > >
> > > OK, thanks.
> > >
> > > > From the previous solution, I have a feeling that we can only go so
> > > > far in trying to solve the issue from Buildroot. We did already one
> > > > thing, and it seems insufficient for some u-boot versions.
> > > > There is a risk that what we do to fix these new failures, may break
> > > > some of those that work today.
> > > > We could implement some kind of detection to see how we need to solve
> > > > the issue depending on the u-boot at hand, but it could be cumbersome.
> > >
> > > Indeed.
> > >
> > > > An alternative solution is to document the known solution to this
> > > > problem (the patches). We can apply these patches to the defconfigs
> > > > inside buildroot, and let users with custom u-boots apply the patches
> > > > themselves (i.e. make them aware from release notes or documentation
> > > > but don't solve it automatically).
> > >
> > > That would be an option yes, but not the nicest one. But still better
> > > than having all the defconfigs failing like they are today :/
> > >
> >
> >
> > I did an analysis of the first defconfig () and came to following
> > patch that fixes the problem:
> >
> > diff --git a/boot/uboot/uboot.mk b/boot/uboot/uboot.mk
> > index bddafe234d..4d34c55827 100644
> > --- a/boot/uboot/uboot.mk
> > +++ b/boot/uboot/uboot.mk
> > @@ -197,6 +197,9 @@ UBOOT_POST_PATCH_HOOKS += UBOOT_APPLY_LOCAL_PATCHES
> >  define UBOOT_FIXUP_LIBFDT_INCLUDE
> >      if [ -d $(@D)/scripts/dtc/libfdt ]; then \
> >          $(SED)
> > 's%-I$$(srctree)/lib/libfdt%-I$$(srctree)/scripts/dtc/libfdt%'
> > $(@D)/tools/Makefile; \
> > +    elif [ -f $(@D)/include/libfdt_env.h ]; then \
> > +        $(SED) '\%#define _LIBFDT_ENV_H%a\
> > +        #define LIBFDT_ENV_H' $(@D)/include/libfdt_env.h; \
> >      fi
> >  endef
> >  UBOOT_POST_PATCH_HOOKS += UBOOT_FIXUP_LIBFDT_INCLUDE
> >
>
> Above patch works for engicam_imx6qdl_icore_qt5_defconfig.
> I extended the patch to apply the same fixup to libfdt.h to fix the
> second defconfig, at91sam9x5ek_mmc_dev_defconfig.
>
> diff --git a/boot/uboot/uboot.mk b/boot/uboot/uboot.mk
> index bddafe234d..af977a99a5 100644
> --- a/boot/uboot/uboot.mk
> +++ b/boot/uboot/uboot.mk
> @@ -197,6 +197,11 @@ UBOOT_POST_PATCH_HOOKS += UBOOT_APPLY_LOCAL_PATCHES
>  define UBOOT_FIXUP_LIBFDT_INCLUDE
>         if [ -d $(@D)/scripts/dtc/libfdt ]; then \
>                 $(SED)
> 's%-I$$(srctree)/lib/libfdt%-I$$(srctree)/scripts/dtc/libfdt%'
> $(@D)/tools/Makefile; \
> +       elif [ -f $(@D)/include/libfdt_env.h ]; then \
> +               $(SED) '\%#define _LIBFDT_ENV_H%a\
> +               #define LIBFDT_ENV_H' $(@D)/include/libfdt_env.h; \
> +               $(SED) '\%#define _LIBFDT_H%a\
> +               #define LIBFDT_H' $(@D)/include/libfdt.h; \
>         fi
>  endef
>  UBOOT_POST_PATCH_HOOKS += UBOOT_FIXUP_LIBFDT_INCLUDE
>
>
> Sadly, for the third defconfig, a problem arises:
> atmel_sama5d4_xplained_mmc_dev_defconfig
> Error now is:
>
> dtc  -O dtb -o arch/arm/dts/at91-sama5d4_xplained.dtb -b 0 -i
> arch/arm/dts/ -Wno-unit_address_vs_reg -d
> arch/arm/dts/.at91-sama5d4_xplained.dtb.d.dtc.tmp
> arch/arm/dts/.at91-sama5d4_xplained.dtb.dts.tmp
>
> arch/arm/dts/at91-sama5d4_xplained.dtb: Warning (unit_address_format):
> /sram at 00210000: unit name should not have leading 0s
> arch/arm/dts/at91-sama5d4_xplained.dtb: Warning (unit_address_format):
> /ahb/gadget at 00400000: unit name should not have leading 0s
> arch/arm/dts/at91-sama5d4_xplained.dtb: Warning (unit_address_format):
> /ahb/ohci at 00500000: unit name should not have leading 0s
> arch/arm/dts/at91-sama5d4_xplained.dtb: Warning (unit_address_format):
> /ahb/ehci at 00600000: unit name should not have leading 0s
> arch/arm/dts/at91-sama5d4_xplained.dtb: Warning (unit_address_format):
> /ahb/cache-controller at 00a00000: unit name should not have leading 0s
> arch/arm/dts/at91-sama5d4_xplained.dtb: Warning (unique_unit_address):
> /ahb/apb/gpio at fc06a000: duplicate unit-address (also used in node
> /ahb/apb/pinctrl at fc06a000)
> dtc: livetree.c:438: propval_cell: Assertion `prop->val.len ==
> sizeof(cell_t)' failed.
> fish: '../../host/bin/dtc  -O dtb -o a?' terminated by signal SIGABRT (Abort)
>
>
> The 'dtc' in question is the one from output/host/bin/dtc.
> If I change the command to use 'dtc' from my host, there is no error.
> There must be an issue in using the header files from one thing but
> then executing a dtc that was compiled against other header files.
> Bweeuh.
>
> So (this) uboot has some local fdt header files, but expects dtc to be
> available externally. And when we force the usage of the local header
> files, we get errors.
>
> Not sure how to proceed yet... Either try to force usage of the
> include files from output/host/  but they may not always be available,
> plus I think that in some cases exactly this caused troubles.
>

The full type of failing command is:
mkdir -p arch/arm/dts/ ; cat arch/arm/dts/at91sam9g45-gurnard.dts  |
/home/tdescham/repo/contrib/buildroot/output/host/bin/arm-linux-gnueabihf-gcc
-E -Wp,-MD,arch/arm/dts/.at91sam9g45-gurnard.dtb.d.pre.tmp -nostdinc
-I./arch/arm/dts -I./arch/arm/dts/include -Iinclude -I./include
-I./arch/arm/include -include ./include/linux/kconfig.h -D__ASSEMBLY__
-undef -D__DTS__ -x assembler-with-cpp -o
arch/arm/dts/.at91sam9g45-gurnard.dtb.dts.tmp - ; dtc -O dtb -o
arch/arm/dts/at91sam9g45-gurnard.dtb -b 0 -i arch/arm/dts/
-Wno-unit_address_vs_reg  -d
arch/arm/dts/.at91sam9g45-gurnard.dtb.d.dtc.tmp
arch/arm/dts/.at91sam9g45-gurnard.dtb.dts.tmp ; cat
arch/arm/dts/.at91sam9g45-gurnard.dtb.d.pre.tmp
arch/arm/dts/.at91sam9g45-gurnard.dtb.d.dtc.tmp >
arch/arm/dts/.at91sam9g45-gurnard.dtb.d

I.e. there is preprocessing of the dts file, then the actual
compilation via dtc.
With this in mind, I actually don't think that this behavior is
negatively impacted by my changes. I now think it is a failure on top
of the original failures. When I undo my changes prior to running this
command, then the same errors occur. And since no other binary than
the compiler (preprocessor) and the prebuilt dtc is used, there cannot
be other impact of the changes I did to two header files.

Nevertheless, this defconfig still does not build correctly.

[Buildroot] Analysis of defconfig build failures

[Peter Korsgaard]

>>>>> "Thomas" == Thomas De Schampheleire <patrickdepinguin+buildroot@gmail.com> writes:

Hi,

 > I.e. there is preprocessing of the dts file, then the actual
 > compilation via dtc.
 > With this in mind, I actually don't think that this behavior is
 > negatively impacted by my changes. I now think it is a failure on top
 > of the original failures. When I undo my changes prior to running this
 > command, then the same errors occur. And since no other binary than
 > the compiler (preprocessor) and the prebuilt dtc is used, there cannot
 > be other impact of the changes I did to two header files.

 > Nevertheless, this defconfig still does not build correctly.

:/

I guess giving the timing, the best solution for 2018.08 is to simply
revert the dtc bump?

-- 
Bye, Peter Korsgaard

[Buildroot] Analysis of defconfig build failures

[Thomas Petazzoni]

Hello,

On Mon, 27 Aug 2018 10:12:16 +0200, Peter Korsgaard wrote:

>  > I.e. there is preprocessing of the dts file, then the actual
>  > compilation via dtc.
>  > With this in mind, I actually don't think that this behavior is
>  > negatively impacted by my changes. I now think it is a failure on top
>  > of the original failures. When I undo my changes prior to running this
>  > command, then the same errors occur. And since no other binary than
>  > the compiler (preprocessor) and the prebuilt dtc is used, there cannot
>  > be other impact of the changes I did to two header files.  
> 
>  > Nevertheless, this defconfig still does not build correctly.  
> 
> :/
> 
> I guess giving the timing, the best solution for 2018.08 is to simply
> revert the dtc bump?

Is this fixing all issues we have, without introducing other problems ?
If so, then I'm fine with a revert of the dtc bump, of course.

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] Analysis of defconfig build failures

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@bootlin.com> writes:

 > Hello,
 > On Mon, 27 Aug 2018 10:12:16 +0200, Peter Korsgaard wrote:

 >> > I.e. there is preprocessing of the dts file, then the actual
 >> > compilation via dtc.
 >> > With this in mind, I actually don't think that this behavior is
 >> > negatively impacted by my changes. I now think it is a failure on top
 >> > of the original failures. When I undo my changes prior to running this
 >> > command, then the same errors occur. And since no other binary than
 >> > the compiler (preprocessor) and the prebuilt dtc is used, there cannot
 >> > be other impact of the changes I did to two header files.  
 >> 
 >> > Nevertheless, this defconfig still does not build correctly.  
 >> 
 >> :/
 >> 
 >> I guess giving the timing, the best solution for 2018.08 is to simply
 >> revert the dtc bump?

 > Is this fixing all issues we have, without introducing other problems ?
 > If so, then I'm fine with a revert of the dtc bump, of course.

That was my understanding based on Yann's git bisect, yes. These
defconfigs all used to work.

Yann?

-- 
Bye, Peter Korsgaard

[Buildroot] Analysis of defconfig build failures

[Thomas De Schampheleire]

Hi,

El lun., 27 ago. 2018 a las 10:45, Peter Korsgaard
(<peter@korsgaard.com>) escribi?:
>
> >>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@bootlin.com> writes:
>
>  > Hello,
>  > On Mon, 27 Aug 2018 10:12:16 +0200, Peter Korsgaard wrote:
>
>  >> > I.e. there is preprocessing of the dts file, then the actual
>  >> > compilation via dtc.
>  >> > With this in mind, I actually don't think that this behavior is
>  >> > negatively impacted by my changes. I now think it is a failure on top
>  >> > of the original failures. When I undo my changes prior to running this
>  >> > command, then the same errors occur. And since no other binary than
>  >> > the compiler (preprocessor) and the prebuilt dtc is used, there cannot
>  >> > be other impact of the changes I did to two header files.
>  >>
>  >> > Nevertheless, this defconfig still does not build correctly.
>  >>
>  >> :/
>  >>
>  >> I guess giving the timing, the best solution for 2018.08 is to simply
>  >> revert the dtc bump?
>
>  > Is this fixing all issues we have, without introducing other problems ?
>  > If so, then I'm fine with a revert of the dtc bump, of course.
>
> That was my understanding based on Yann's git bisect, yes. These
> defconfigs all used to work.

With this information (that was new to me) I bisected into dtc itself.
Culprit commit entered into v1.4.6 and is:
https://git.kernel.org/pub/scm/utils/dtc/dtc.git/commit/?id=c8b38f65fdec4226d43f0e8eb

commit c8b38f65fdec4226d43f0e8eb5cf541aff3c80a5 (HEAD, refs/bisect/bad)
Author: David Gibson <david@gibson.dropbear.id.au>
Date:   Wed Oct 18 17:22:40 2017 +1100

    libfdt: Remove leading underscores from identifiers

    In a lot of places libfdt uses a leading _ character to mark an identifier
    as "internal" (not part of the published libfdt API).  This is a bad idea,
    because identifiers with a leading _ are generally reserved by the C
    library or system.  It's particularly dangerous for libfdt, because it's
    designed to be able to be integrated into lots of different environments.

    In some cases the leading _ has no purpose, so we simply drop it.  In most
    cases we move it to the end, as our new convention for marking internal
    identifiers.

    Signed-off-by: David Gibson <david@gibson.dropbear.id.au>


In this commit, not only include guards are changed, but also actual
identifiers.

While the above commit fixes the fdt types issues, the other issue I
got after applying my fix (assertion error) is caused by a later
commit, introduced in v1.4.7:

https://git.kernel.org/pub/scm/utils/dtc/dtc.git/commit/?id=df536831d02c51556a8e88cd8da0be0244484156
commit df536831d02c51556a8e88cd8da0be0244484156 (HEAD, refs/bisect/bad)
Author: Rob Herring <robh@kernel.org>
Date:   Tue Feb 13 17:00:59 2018 -0600

    checks: add graph binding checks

    Add checks for DT graph bindings. These checks check node names,
    unit-addresses and link connections on ports, port, and endpoint nodes.

    The graph nodes are matched by finding nodes named 'endpoint' or with a
    'remote-endpoint' property. We can't match on 'ports' or 'port' nodes
    because those names are used for non-graph nodes. While the graph nodes
    aren't really buses, using the bus pointer to tag matched nodes is
    convenient.

    Signed-off-by: Rob Herring <robh@kernel.org>
    Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

Backtrace from a quick gdb session:

Program received signal SIGABRT, Aborted.
0x00007ffff7a4b010 in raise () from /lib64/libc.so.6
(gdb) bt
#0  0x00007ffff7a4b010 in raise () from /lib64/libc.so.6
#1  0x00007ffff7a4cc0d in abort () from /lib64/libc.so.6
#2  0x00007ffff7a427e7 in ?? () from /lib64/libc.so.6
#3  0x00007ffff7a428a2 in __assert_fail () from /lib64/libc.so.6
#4  0x0000555555560a6f in propval_cell ()
#5  0x000055555555b536 in check_graph_child_address ()
#6  0x0000555555558dc8 in check_nodes_props ()
#7  0x0000555555558df6 in check_nodes_props ()
#8  0x000055555555a4d7 in run_check ()
#9  0x000055555555c2cf in process_checks ()
#10 0x0000555555558797 in main ()

I haven't dug deeper. It could be that some patching is needed in
host-dtc itself, to solve the above error.

/Thomas

[Buildroot] Analysis of defconfig build failures

[Peter Korsgaard]

>>>>> "Thomas" == Thomas De Schampheleire <patrickdepinguin+buildroot@gmail.com> writes:

Hi,

 > Backtrace from a quick gdb session:

 > Program received signal SIGABRT, Aborted.
 > 0x00007ffff7a4b010 in raise () from /lib64/libc.so.6
 > (gdb) bt
 > #0  0x00007ffff7a4b010 in raise () from /lib64/libc.so.6
 > #1  0x00007ffff7a4cc0d in abort () from /lib64/libc.so.6
 > #2  0x00007ffff7a427e7 in ?? () from /lib64/libc.so.6
 > #3  0x00007ffff7a428a2 in __assert_fail () from /lib64/libc.so.6
 > #4  0x0000555555560a6f in propval_cell ()
 > #5  0x000055555555b536 in check_graph_child_address ()
 > #6  0x0000555555558dc8 in check_nodes_props ()
 > #7  0x0000555555558df6 in check_nodes_props ()
 > #8  0x000055555555a4d7 in run_check ()
 > #9  0x000055555555c2cf in process_checks ()
 > #10 0x0000555555558797 in main ()

 > I haven't dug deeper. It could be that some patching is needed in
 > host-dtc itself, to solve the above error.

Thanks for investigating. This again seems to confirm that reverting the
dtc bump will be a solution for 2018.08.

-- 
Bye, Peter Korsgaard

[Buildroot] Analysis of defconfig build failures

[Luca Ceresoli]

Hi,

On 27/08/2018 23:19, Peter Korsgaard wrote:
>>>>>> "Thomas" == Thomas De Schampheleire <patrickdepinguin+buildroot@gmail.com> writes:
> 
> Hi,
> 
>  > Backtrace from a quick gdb session:
> 
>  > Program received signal SIGABRT, Aborted.
>  > 0x00007ffff7a4b010 in raise () from /lib64/libc.so.6
>  > (gdb) bt
>  > #0  0x00007ffff7a4b010 in raise () from /lib64/libc.so.6
>  > #1  0x00007ffff7a4cc0d in abort () from /lib64/libc.so.6
>  > #2  0x00007ffff7a427e7 in ?? () from /lib64/libc.so.6
>  > #3  0x00007ffff7a428a2 in __assert_fail () from /lib64/libc.so.6
>  > #4  0x0000555555560a6f in propval_cell ()
>  > #5  0x000055555555b536 in check_graph_child_address ()
>  > #6  0x0000555555558dc8 in check_nodes_props ()
>  > #7  0x0000555555558df6 in check_nodes_props ()
>  > #8  0x000055555555a4d7 in run_check ()
>  > #9  0x000055555555c2cf in process_checks ()
>  > #10 0x0000555555558797 in main ()
> 
>  > I haven't dug deeper. It could be that some patching is needed in
>  > host-dtc itself, to solve the above error.
> 
> Thanks for investigating. This again seems to confirm that reverting the
> dtc bump will be a solution for 2018.08.

At any rate, I just sent a small series to upgrade U-Boot for 3 zynq
boards. Even with the dtc bump revert they shouldn't hurt.

Regards,
-- 
Luca