| Message ID | 1392816403-9101-1-git-send-email-yamada.m@jp.panasonic.com |
|---|---|
| State | Accepted |
| Delegated to: | Tom Rini |
| Headers | show |
Hi Masahiro, On Wed, 19 Feb 2014 22:26:43 +0900, Masahiro Yamada <yamada.m@jp.panasonic.com> wrote: > In Kbuild, every makefile must have non-empty obj- or obj-y. > Otherwise, built-in.o will not be created and the link stage > will fail. > > Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> > --- > > Tom, > Please apply this along with the Kbuild series. > > > > arch/arm/cpu/armv7/tegra124/Makefile | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/arch/arm/cpu/armv7/tegra124/Makefile b/arch/arm/cpu/armv7/tegra124/Makefile > index 7f127b1..9478d44 100644 > --- a/arch/arm/cpu/armv7/tegra124/Makefile > +++ b/arch/arm/cpu/armv7/tegra124/Makefile > @@ -4,3 +4,6 @@ > # > # SPDX-License-Identifier: GPL-2.0+ > # > + > +# necessary to create built-in.o > +obj- := __dummy__.o Is there really no other way than to specify an unexisting __dummy__.o in order to build a useless built-in.o? Amicalement,
On 02/19/2014 07:46 AM, Albert ARIBAUD wrote: > Hi Masahiro, > > On Wed, 19 Feb 2014 22:26:43 +0900, Masahiro Yamada > <yamada.m@jp.panasonic.com> wrote: > >> In Kbuild, every makefile must have non-empty obj- or obj-y. >> Otherwise, built-in.o will not be created and the link stage >> will fail. ... >> diff --git a/arch/arm/cpu/armv7/tegra124/Makefile b/arch/arm/cpu/armv7/tegra124/Makefile ... >> +# necessary to create built-in.o >> +obj- := __dummy__.o obj- or obj-y? Adding something to obj-, which presumably isn't used at all, seems very odd. > Is there really no other way than to specify an unexisting __dummy__.o > in order to build a useless built-in.o? I haven't looked at Kbuild at all, but in the build systems I've written, for each sub-directory makefile that was included, the makefiles would include a "pre-makefile" first and a "post-makefile" after. The "post-makefile" could easily do something like: ifeq ($(obj-y),) obg-y := __dummy__.o endif
On Wed, Feb 19, 2014 at 09:36:14AM -0700, Stephen Warren wrote: > On 02/19/2014 07:46 AM, Albert ARIBAUD wrote: > > Hi Masahiro, > > > > On Wed, 19 Feb 2014 22:26:43 +0900, Masahiro Yamada > > <yamada.m@jp.panasonic.com> wrote: > > > >> In Kbuild, every makefile must have non-empty obj- or obj-y. > >> Otherwise, built-in.o will not be created and the link stage > >> will fail. > ... > >> diff --git a/arch/arm/cpu/armv7/tegra124/Makefile b/arch/arm/cpu/armv7/tegra124/Makefile > ... > >> +# necessary to create built-in.o > >> +obj- := __dummy__.o > > obj- or obj-y? > > Adding something to obj-, which presumably isn't used at all, seems very > odd. Why do we even need arch/arm/cpu/armv7/tegra124/Makefile ? I assume we need the config.mk because we can't stick CONFIG_ARCH_DEVICE_TREE into the config header? > > > Is there really no other way than to specify an unexisting __dummy__.o > > in order to build a useless built-in.o? > > I haven't looked at Kbuild at all, but in the build systems I've > written, for each sub-directory makefile that was included, the > makefiles would include a "pre-makefile" first and a "post-makefile" > after. The "post-makefile" could easily do something like: > > ifeq ($(obj-y),) > obg-y := __dummy__.o > endif > > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot
On 02/19/2014 01:40 PM, Tom Rini wrote: > On Wed, Feb 19, 2014 at 09:36:14AM -0700, Stephen Warren wrote: >> On 02/19/2014 07:46 AM, Albert ARIBAUD wrote: >>> Hi Masahiro, >>> >>> On Wed, 19 Feb 2014 22:26:43 +0900, Masahiro Yamada >>> <yamada.m@jp.panasonic.com> wrote: >>> >>>> In Kbuild, every makefile must have non-empty obj- or obj-y. >>>> Otherwise, built-in.o will not be created and the link stage >>>> will fail. >> ... >>>> diff --git a/arch/arm/cpu/armv7/tegra124/Makefile b/arch/arm/cpu/armv7/tegra124/Makefile >> ... >>>> +# necessary to create built-in.o >>>> +obj- := __dummy__.o >> >> obj- or obj-y? >> >> Adding something to obj-, which presumably isn't used at all, seems very >> odd. > > Why do we even need arch/arm/cpu/armv7/tegra124/Makefile ? I assume we > need the config.mk because we can't stick CONFIG_ARCH_DEVICE_TREE into > the config header? At least with the current build system, if I delete it, the build fails: > + make BUILD_DIR=/home/swarren/shared/git_wa/tegra-uboot-flasher/_build/venice2/u-boot -s -j9 > /home/swarren/shared/git_wa/tegra-uboot-flasher/u-boot/scripts/Makefile.build:11: Makefile: No such file or directory > make[1]: *** No rule to make target `Makefile'. Stop. > make: *** [/home/swarren/shared/git_wa/tegra-uboot-flasher/_build/venice2/u-boot/arch/arm/cpu/armv7/tegra124/built-in.o] Error 2
On Wed, Feb 19, 2014 at 10:26:43PM +0900, Masahiro Yamada wrote: > In Kbuild, every makefile must have non-empty obj- or obj-y. > Otherwise, built-in.o will not be created and the link stage > will fail. > > Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> > --- > > Tom, > Please apply this along with the Kbuild series. So with this, I then get: Configuring for venice2 board... make[2]: *** [arch/arm/dts/tegra124-venice2.dtb] Error 1 make[1]: *** [dts/dt.dtb] Error 2 make: *** [sub-make] Error 2 text data bss dec hex filename 260562 15030 309960 585552 8ef50 venice2/u-boot 18527 421 72 19020 4a4c venice2/spl/u-boot-spl Device Tree Source is not correctly specified. Please define 'CONFIG_DEFAULT_DEVICE_TREE' or build with 'DEVICE_TREE=<device_tree>' argument make[2]: *** [arch/arm/dts/tegra124-venice2.dtb] Error 1 make[1]: *** [dts/dt.dtb] Error 2 make: *** [sub-make] Error 2 --------------------- SUMMARY ---------------------------- Boards compiled: 1 Boards with errors: 1 ( venice2 ) ---------------------------------------------------------- What's going on as the config file sets CONFIG_DEFAULT_DEVICE_TREE
On Wed, Feb 19, 2014 at 10:26:43PM +0900, Masahiro Yamada wrote: > In Kbuild, every makefile must have non-empty obj- or obj-y. > Otherwise, built-in.o will not be created and the link stage > will fail. > > Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Applied to u-boot/master, thanks!
Hello Tom, (ccing Simon and Stephan) > > Tom, > > Please apply this along with the Kbuild series. > > So with this, I then get: > Configuring for venice2 board... > make[2]: *** [arch/arm/dts/tegra124-venice2.dtb] Error 1 > make[1]: *** [dts/dt.dtb] Error 2 > make: *** [sub-make] Error 2 > text data bss dec hex filename > 260562 15030 309960 585552 8ef50 venice2/u-boot > 18527 421 72 19020 4a4c venice2/spl/u-boot-spl > > Device Tree Source is not correctly specified. > Please define 'CONFIG_DEFAULT_DEVICE_TREE' > or build with 'DEVICE_TREE=<device_tree>' argument > > make[2]: *** [arch/arm/dts/tegra124-venice2.dtb] Error 1 > make[1]: *** [dts/dt.dtb] Error 2 > make: *** [sub-make] Error 2 > > --------------------- SUMMARY ---------------------------- > Boards compiled: 1 > Boards with errors: 1 ( venice2 ) > ---------------------------------------------------------- > > What's going on as the config file sets CONFIG_DEFAULT_DEVICE_TREE > Commit 5ab502cb89 has been applied and the build system now expects device tree sources should reside under arch/$(ARCH)/dts/. But the device tree of venice2 board is still remaining in board/nvidia/dts/. This is the cause of the build error. (Commit 5ab502cb89 had been posted before venice2 board support was merged. So there happened an unvisible conflict.) Actually I did not expect dts series was applied so soon because Simon and I was still discussing that series. And I guess Simon is not happy about Commit 5ab502cb89. Anyway, we need to do something with venice2's build error immediately. I think we have two options. [1] Move also venice2 device tree to arch/arm/dts directory. I have posted a patch: http://patchwork.ozlabs.org/patch/322082/ [2] revert the following commits in this order 3284c8b8ca (dts: generate multiple device tree blobs) 5ab502cb89 (dts: move device tree sources to arch/$(ARCH)/dts/) If we like to gather all device trees to arch/$(ARCH)/dts, the choice will be [1]. On the other hand, if we like to put *.dtsi to arch/$(ARCH)/dts whilst *.dts to board/$(VENDOR)/dts, the choice will be [2]. Best Regards Masahiro Yamada
Hello Albert, > > --- a/arch/arm/cpu/armv7/tegra124/Makefile > > +++ b/arch/arm/cpu/armv7/tegra124/Makefile > > @@ -4,3 +4,6 @@ > > # > > # SPDX-License-Identifier: GPL-2.0+ > > # > > + > > +# necessary to create built-in.o > > +obj- := __dummy__.o > > Is there really no other way than to specify an unexisting __dummy__.o > in order to build a useless built-in.o? I believe this is the simplest workaround we can do now. But I promise I'll refactor makefiles and delete arch/arm/cpu/armv7/{tegra114,tegra30}/Makefile lator. For now, let me go with this solution.. We still have a mountain of refactoring to do. Best Regards Masahiro Yamada
Hello Stephen, On Wed, 19 Feb 2014 09:36:14 -0700 Stephen Warren <swarren@wwwdotorg.org> wrote: > On 02/19/2014 07:46 AM, Albert ARIBAUD wrote: > > Hi Masahiro, > > > > On Wed, 19 Feb 2014 22:26:43 +0900, Masahiro Yamada > > <yamada.m@jp.panasonic.com> wrote: > > > >> In Kbuild, every makefile must have non-empty obj- or obj-y. > >> Otherwise, built-in.o will not be created and the link stage > >> will fail. > ... > >> diff --git a/arch/arm/cpu/armv7/tegra124/Makefile b/arch/arm/cpu/armv7/tegra124/Makefile > ... > >> +# necessary to create built-in.o > >> +obj- := __dummy__.o > > obj- or obj-y? Definitely obj-. If you add a non-existing object to obj-y, build will fail. > Adding something to obj-, which presumably isn't used at all, seems very > odd. > > > Is there really no other way than to specify an unexisting __dummy__.o > > in order to build a useless built-in.o? > > I haven't looked at Kbuild at all, but in the build systems I've > written, for each sub-directory makefile that was included, the > makefiles would include a "pre-makefile" first and a "post-makefile" > after. The "post-makefile" could easily do something like: > > ifeq ($(obj-y),) > obg-y := __dummy__.o > endif You mean ifeq ($(obj-y),) obj- := __dummy__.o endif should be put in a common part(scripts/Makefile.build) ? No, no. We can't do this. It has a side effect. If we put it in the common part, build-in.o will be generated in all sub-directories, including tools/, tools/env, examples/standalone/, etc. We do not want built-in.o in host progs / standalone progs directories. Best Regards Masahiro Yamada
Hello Stephen, > >> > >> Adding something to obj-, which presumably isn't used at all, seems very > >> odd. > > > > Why do we even need arch/arm/cpu/armv7/tegra124/Makefile ? I assume we > > need the config.mk because we can't stick CONFIG_ARCH_DEVICE_TREE into > > the config header? > > At least with the current build system, if I delete it, the build fails: > > > + make BUILD_DIR=/home/swarren/shared/git_wa/tegra-uboot-flasher/_build/venice2/u-boot -s -j9 > > /home/swarren/shared/git_wa/tegra-uboot-flasher/u-boot/scripts/Makefile.build:11: Makefile: No such file or directory > > make[1]: *** No rule to make target `Makefile'. Stop. > > make: *** [/home/swarren/shared/git_wa/tegra-uboot-flasher/_build/venice2/u-boot/arch/arm/cpu/armv7/tegra124/built-in.o] Error 2 Yes, we can't delete the Makefile. (This is the same as before Kbuild.) Venice2 board specify SoC name, tegra124 in boards.cfg. If $(SOC) is not empty, the build system will descend into the SoC directory, and Makefile always must be there. I understand the special situation for Tegra, which has a different CPU for SPL. I guess you want to build under arch/arm/cpu/arm720t/tegra124/ for SPL, whereas there is nothing to build under arch/arm/cpu/armv7/tegra124/. Best Regards Masahiro Yamada
Hi Masahiro, On Thu, 20 Feb 2014 17:23:31 +0900, Masahiro Yamada <yamada.m@jp.panasonic.com> wrote: > Hello Albert, > > > > > --- a/arch/arm/cpu/armv7/tegra124/Makefile > > > +++ b/arch/arm/cpu/armv7/tegra124/Makefile > > > @@ -4,3 +4,6 @@ > > > # > > > # SPDX-License-Identifier: GPL-2.0+ > > > # > > > + > > > +# necessary to create built-in.o > > > +obj- := __dummy__.o > > > > Is there really no other way than to specify an unexisting __dummy__.o > > in order to build a useless built-in.o? > > I believe this is the simplest workaround we can do now. > > But I promise I'll refactor makefiles and delete > arch/arm/cpu/armv7/{tegra114,tegra30}/Makefile lator. > > For now, let me go with this solution.. > We still have a mountain of refactoring to do. Thanks -- as long as this is a known topic, I'm fine with it. > Best Regards > Masahiro Yamada Amicalement,
On Thu, Feb 20, 2014 at 05:22:27PM +0900, Masahiro Yamada wrote: > Hello Tom, > (ccing Simon and Stephan) > > > > > > Tom, > > > Please apply this along with the Kbuild series. > > > > So with this, I then get: > > Configuring for venice2 board... > > make[2]: *** [arch/arm/dts/tegra124-venice2.dtb] Error 1 > > make[1]: *** [dts/dt.dtb] Error 2 > > make: *** [sub-make] Error 2 > > text data bss dec hex filename > > 260562 15030 309960 585552 8ef50 venice2/u-boot > > 18527 421 72 19020 4a4c venice2/spl/u-boot-spl > > > > Device Tree Source is not correctly specified. > > Please define 'CONFIG_DEFAULT_DEVICE_TREE' > > or build with 'DEVICE_TREE=<device_tree>' argument > > > > make[2]: *** [arch/arm/dts/tegra124-venice2.dtb] Error 1 > > make[1]: *** [dts/dt.dtb] Error 2 > > make: *** [sub-make] Error 2 > > > > --------------------- SUMMARY ---------------------------- > > Boards compiled: 1 > > Boards with errors: 1 ( venice2 ) > > ---------------------------------------------------------- > > > > What's going on as the config file sets CONFIG_DEFAULT_DEVICE_TREE > > > > > > Commit 5ab502cb89 has been applied and the build system > now expects device tree sources should reside under arch/$(ARCH)/dts/. > > But the device tree of venice2 board is still remaining > in board/nvidia/dts/. > This is the cause of the build error. > (Commit 5ab502cb89 had been posted before venice2 board > support was merged. So there happened an unvisible conflict.) > > Actually I did not expect dts series was applied so soon > because Simon and I was still discussing that series. > And I guess Simon is not happy about Commit 5ab502cb89. > > Anyway, we need to do something with venice2's build error > immediately. > > I think we have two options. > > [1] Move also venice2 device tree to arch/arm/dts directory. > I have posted a patch: > http://patchwork.ozlabs.org/patch/322082/ > > [2] revert the following commits in this order > 3284c8b8ca (dts: generate multiple device tree blobs) > 5ab502cb89 (dts: move device tree sources to arch/$(ARCH)/dts/) > > > If we like to gather all device trees to arch/$(ARCH)/dts, > the choice will be [1]. > > On the other hand, if we like to put *.dtsi to arch/$(ARCH)/dts > whilst *.dts to board/$(VENDOR)/dts, the choice will be [2]. Well, I think our long term plan here is (a) mirror the kernel today and since their long term plan is "move device trees out of tree, then deal with it there" once they've got a plan there, we can follow (and indeed should be contributing to the conversation).
On 02/20/2014 01:24 AM, Masahiro Yamada wrote: > Hello Stephen, > > > On Wed, 19 Feb 2014 09:36:14 -0700 > Stephen Warren <swarren@wwwdotorg.org> wrote: > >> On 02/19/2014 07:46 AM, Albert ARIBAUD wrote: >>> Hi Masahiro, >>> >>> On Wed, 19 Feb 2014 22:26:43 +0900, Masahiro Yamada >>> <yamada.m@jp.panasonic.com> wrote: >>> >>>> In Kbuild, every makefile must have non-empty obj- or obj-y. >>>> Otherwise, built-in.o will not be created and the link stage >>>> will fail. >> ... >>>> diff --git a/arch/arm/cpu/armv7/tegra124/Makefile b/arch/arm/cpu/armv7/tegra124/Makefile >> ... >>>> +# necessary to create built-in.o >>>> +obj- := __dummy__.o >> >> obj- or obj-y? > > Definitely obj-. Really? Why would such a variable even exist or be used. Only obj-n or obj-y should exist; "" isn't a valid y/n value.
Hello Stefen, On Thu, 20 Feb 2014 09:15:21 -0700 Stephen Warren <swarren@wwwdotorg.org> wrote: > On 02/20/2014 01:24 AM, Masahiro Yamada wrote: > > Hello Stephen, > > > > > > On Wed, 19 Feb 2014 09:36:14 -0700 > > Stephen Warren <swarren@wwwdotorg.org> wrote: > > > >> On 02/19/2014 07:46 AM, Albert ARIBAUD wrote: > >>> Hi Masahiro, > >>> > >>> On Wed, 19 Feb 2014 22:26:43 +0900, Masahiro Yamada > >>> <yamada.m@jp.panasonic.com> wrote: > >>> > >>>> In Kbuild, every makefile must have non-empty obj- or obj-y. > >>>> Otherwise, built-in.o will not be created and the link stage > >>>> will fail. > >> ... > >>>> diff --git a/arch/arm/cpu/armv7/tegra124/Makefile b/arch/arm/cpu/armv7/tegra124/Makefile > >> ... > >>>> +# necessary to create built-in.o > >>>> +obj- := __dummy__.o > >> > >> obj- or obj-y? > > > > Definitely obj-. > > Really? Why would such a variable even exist or be used. Only obj-n or > obj-y should exist; "" isn't a valid y/n value. All defined CONFIG macros are included in include/autoconf.mk (and include/spl-autoconf.mk, include/tpl-autoconf.mk for SPL, TPL, respectively) If CONFIG_FOO is defined in your config header, CONFIG_FOO=y will apear in include/autoconf.mk Otherwise, it does not appear in include/autoconf.mk. As a result, obj-$(CONFIG_FOO) += foo.o becomes obj-y += foo.o (if CONFIG_FOO is defined) or obj- += foo.o (if CONFIG_FOO is not defined) Kbuild checks $(obj-) as well as $(obj-y). Let me explain shortly how Kbuild works. For example, assume we have a Makefile like this obj-$(CONFIG_FOO) += foo.o obj-$(CONFIG_BAR) += bar.o [1] Let's say CONFIG_FOO is set, but CONFIG_BAR isn't. In this case, $(obj-y) is "foo.o" $(obj-) is "bar.o" Then Kbuild builds only "foo.o" and links it into built-in.o [2] Next, let's say neither CONFIG_FOO nor CONFIG_BAR is set. In this case, $(obj-y) is empty. $(obj-) is "foo.o bar.o" Kbuild creates empty built-in.o if $(obj-y) is empty but $(obj-) is not empty. [3] Last, let's say Makefile does not have obj-$(...) lines. In this case, $(obj-y) is empty $(obj-) is empty too. Kbuild does not create built-in.o when both $(obj-y) and $(obj-) are empty. This is the case of tools/Makefile or example/standalone/Makefile. Is this clearer now? Best Regards Masahiro Yamada
On 02/21/2014 04:45 AM, Masahiro Yamada wrote: > On Thu, 20 Feb 2014 09:15:21 -0700 Stephen Warren wrote: >> On 02/20/2014 01:24 AM, Masahiro Yamada wrote: >>> On Wed, 19 Feb 2014 09:36:14 -0700 Stephen Warren wrote: >>>> On 02/19/2014 07:46 AM, Albert ARIBAUD wrote: >>>>> On Wed, 19 Feb 2014 22:26:43 +0900, Masahiro wrote: >>>>> >>>>>> In Kbuild, every makefile must have non-empty obj- or obj-y. >>>>>> Otherwise, built-in.o will not be created and the link stage >>>>>> will fail. >>>> ... >>>>>> diff --git a/arch/arm/cpu/armv7/tegra124/Makefile b/arch/arm/cpu/armv7/tegra124/Makefile >>>> ... >>>>>> +# necessary to create built-in.o >>>>>> +obj- := __dummy__.o >>>> >>>> obj- or obj-y? >>> >>> Definitely obj-. >> >> Really? Why would such a variable even exist or be used. Only obj-n or >> obj-y should exist; "" isn't a valid y/n value. > > All defined CONFIG macros are included in > include/autoconf.mk (and include/spl-autoconf.mk, > include/tpl-autoconf.mk for SPL, TPL, respectively) > > If CONFIG_FOO is defined in your config header, > CONFIG_FOO=y will apear in include/autoconf.mk > Otherwise, it does not appear in include/autoconf.mk. ... > Is this clearer now? OK, that makes sense. I would have expected that Kbuild could detect obj-y is empty, and skip building builtin.o, and skip attempting to link it in to the parent directory too. However, if it doesn't do that, then this all makes sense. Thanks.
diff --git a/arch/arm/cpu/armv7/tegra124/Makefile b/arch/arm/cpu/armv7/tegra124/Makefile index 7f127b1..9478d44 100644 --- a/arch/arm/cpu/armv7/tegra124/Makefile +++ b/arch/arm/cpu/armv7/tegra124/Makefile @@ -4,3 +4,6 @@ # # SPDX-License-Identifier: GPL-2.0+ # + +# necessary to create built-in.o +obj- := __dummy__.o
In Kbuild, every makefile must have non-empty obj- or obj-y. Otherwise, built-in.o will not be created and the link stage will fail. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> --- Tom, Please apply this along with the Kbuild series. arch/arm/cpu/armv7/tegra124/Makefile | 3 +++ 1 file changed, 3 insertions(+)