* [Buildroot] Analysis of defconfig build failures @ 2018-08-12 15:01 Thomas Petazzoni 2018-08-15 19:09 ` Peter Korsgaard 0 siblings, 1 reply; 16+ messages in thread From: Thomas Petazzoni @ 2018-08-12 15:01 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of defconfig build failures 2018-08-12 15:01 [Buildroot] Analysis of defconfig build failures Thomas Petazzoni @ 2018-08-15 19:09 ` Peter Korsgaard 2018-08-15 19:34 ` Thomas Petazzoni 0 siblings, 1 reply; 16+ messages in thread From: Peter Korsgaard @ 2018-08-15 19:09 UTC (permalink / raw) To: buildroot >>>>> "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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of defconfig build failures 2018-08-15 19:09 ` Peter Korsgaard @ 2018-08-15 19:34 ` Thomas Petazzoni 2018-08-15 21:27 ` Peter Korsgaard 0 siblings, 1 reply; 16+ messages in thread From: Thomas Petazzoni @ 2018-08-15 19:34 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of defconfig build failures 2018-08-15 19:34 ` Thomas Petazzoni @ 2018-08-15 21:27 ` Peter Korsgaard 2018-08-15 22:18 ` Thomas Petazzoni 0 siblings, 1 reply; 16+ messages in thread From: Peter Korsgaard @ 2018-08-15 21:27 UTC (permalink / raw) To: buildroot >>>>> "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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of defconfig build failures 2018-08-15 21:27 ` Peter Korsgaard @ 2018-08-15 22:18 ` Thomas Petazzoni 2018-08-16 19:52 ` Thomas De Schampheleire 0 siblings, 1 reply; 16+ messages in thread From: Thomas Petazzoni @ 2018-08-15 22:18 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of defconfig build failures 2018-08-15 22:18 ` Thomas Petazzoni @ 2018-08-16 19:52 ` Thomas De Schampheleire 2018-08-16 20:06 ` Thomas Petazzoni 0 siblings, 1 reply; 16+ messages in thread From: Thomas De Schampheleire @ 2018-08-16 19:52 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of defconfig build failures 2018-08-16 19:52 ` Thomas De Schampheleire @ 2018-08-16 20:06 ` Thomas Petazzoni 2018-08-23 19:49 ` Thomas De Schampheleire 0 siblings, 1 reply; 16+ messages in thread From: Thomas Petazzoni @ 2018-08-16 20:06 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of defconfig build failures 2018-08-16 20:06 ` Thomas Petazzoni @ 2018-08-23 19:49 ` Thomas De Schampheleire 2018-08-25 20:21 ` Thomas De Schampheleire 0 siblings, 1 reply; 16+ messages in thread From: Thomas De Schampheleire @ 2018-08-23 19:49 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of defconfig build failures 2018-08-23 19:49 ` Thomas De Schampheleire @ 2018-08-25 20:21 ` Thomas De Schampheleire 2018-08-25 20:54 ` Thomas De Schampheleire 0 siblings, 1 reply; 16+ messages in thread From: Thomas De Schampheleire @ 2018-08-25 20:21 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of defconfig build failures 2018-08-25 20:21 ` Thomas De Schampheleire @ 2018-08-25 20:54 ` Thomas De Schampheleire 2018-08-27 8:12 ` Peter Korsgaard 0 siblings, 1 reply; 16+ messages in thread From: Thomas De Schampheleire @ 2018-08-25 20:54 UTC (permalink / raw) To: buildroot 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of defconfig build failures 2018-08-25 20:54 ` Thomas De Schampheleire @ 2018-08-27 8:12 ` Peter Korsgaard 2018-08-27 8:28 ` Thomas Petazzoni 0 siblings, 1 reply; 16+ messages in thread From: Peter Korsgaard @ 2018-08-27 8:12 UTC (permalink / raw) To: buildroot >>>>> "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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of defconfig build failures 2018-08-27 8:12 ` Peter Korsgaard @ 2018-08-27 8:28 ` Thomas Petazzoni 2018-08-27 8:45 ` Peter Korsgaard 0 siblings, 1 reply; 16+ messages in thread From: Thomas Petazzoni @ 2018-08-27 8:28 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of defconfig build failures 2018-08-27 8:28 ` Thomas Petazzoni @ 2018-08-27 8:45 ` Peter Korsgaard 2018-08-27 21:01 ` Thomas De Schampheleire 0 siblings, 1 reply; 16+ messages in thread From: Peter Korsgaard @ 2018-08-27 8:45 UTC (permalink / raw) To: buildroot >>>>> "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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of defconfig build failures 2018-08-27 8:45 ` Peter Korsgaard @ 2018-08-27 21:01 ` Thomas De Schampheleire 2018-08-27 21:19 ` Peter Korsgaard 0 siblings, 1 reply; 16+ messages in thread From: Thomas De Schampheleire @ 2018-08-27 21:01 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of defconfig build failures 2018-08-27 21:01 ` Thomas De Schampheleire @ 2018-08-27 21:19 ` Peter Korsgaard 2018-08-28 8:07 ` Luca Ceresoli 0 siblings, 1 reply; 16+ messages in thread From: Peter Korsgaard @ 2018-08-27 21:19 UTC (permalink / raw) To: buildroot >>>>> "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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of defconfig build failures 2018-08-27 21:19 ` Peter Korsgaard @ 2018-08-28 8:07 ` Luca Ceresoli 0 siblings, 0 replies; 16+ messages in thread From: Luca Ceresoli @ 2018-08-28 8:07 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2018-08-28 8:07 UTC | newest] Thread overview: 16+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-08-12 15:01 [Buildroot] Analysis of defconfig build failures Thomas Petazzoni 2018-08-15 19:09 ` Peter Korsgaard 2018-08-15 19:34 ` Thomas Petazzoni 2018-08-15 21:27 ` Peter Korsgaard 2018-08-15 22:18 ` Thomas Petazzoni 2018-08-16 19:52 ` Thomas De Schampheleire 2018-08-16 20:06 ` Thomas Petazzoni 2018-08-23 19:49 ` Thomas De Schampheleire 2018-08-25 20:21 ` Thomas De Schampheleire 2018-08-25 20:54 ` Thomas De Schampheleire 2018-08-27 8:12 ` Peter Korsgaard 2018-08-27 8:28 ` Thomas Petazzoni 2018-08-27 8:45 ` Peter Korsgaard 2018-08-27 21:01 ` Thomas De Schampheleire 2018-08-27 21:19 ` Peter Korsgaard 2018-08-28 8:07 ` Luca Ceresoli
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox