[U-Boot] [PATCH 1/2] kbuild: Fix a false error of generic board support

[U-Boot] [PATCH 1/2] kbuild: Fix a false error of generic board support

[mgerlach]

Hello Masahiro Yamada,

Even the with this patch, we encountered a false error of generic board
support.  The problem was very interrmittent for us, but we were able 
to debug the problem to performing builds on EXT3 file systems which
have a time stamp resolution of one second.  To reproduce the problem,
touch ./include/config/auto.conf and .config on a configured uboot tree on
an EXT3 file system.

The patch below fixes the problem for us.  

Thanks,

Matthew Gerlach

---
 Makefile | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 99097e1..84de2f9 100644
--- a/Makefile
+++ b/Makefile
@@ -493,8 +493,12 @@ include/config/%.conf: $(KCONFIG_CONFIG) 
include/config/auto.conf.cmd
 # is up-to-date. When we switch to a different board configuration, old 
CONFIG
 # macros are still remaining in include/config/auto.conf. Without the 
following
 # gimmick, wrong config.mk would be included leading nasty 
warnings/errors.
-autoconf_is_current := $(if $(wildcard $(KCONFIG_CONFIG)),$(shell find . 
\
-		-path ./include/config/auto.conf -newer 
$(KCONFIG_CONFIG)))
+# We use if not (not -newer) so that we include config.mk in the event 
that the
+# file timestamps are exacty equal which can happen on EXT3 filesystems.
+autoconf_is_current := $(if $(wildcard $(KCONFIG_CONFIG)),\
+		$(if $(shell find . -path ./include/config/auto.conf \
+		\! -newer $(KCONFIG_CONFIG)),,./include/config/auto.conf))
+
 ifneq ($(autoconf_is_current),)
 include $(srctree)/config.mk
 endif
-- 
1.8.2.

> Before this commit, make terminated with an error
> where it shouldn't under some condition.
>
> This bug happened when we built a board unsupporting
> generic board right after building with generic board.
>
> For example, the following sequence failed.
> (harmony uses generic board but microblaze-generic does not
> support it)
>
>   $ make harmony_config
>   Configuring for harmony board...
>   $ make CROSS_COMPILE=arm-linux-gnueabi-
>     [ Build succeed ]
>   $ make microblaze-generic_config
>   Configuring for microblaze-generic board...
>   $ make CROSS_COMPILE=microblaze-linux-
>   Makefile:488: *** Your architecture does not support generic board.
>   Please undefined CONFIG_SYS_GENERIC_BOARD in your board config file.
> Stop.
>
> We had to do "make mrproper" before building the microblaze board.
>
> This commit fixes this unconvenience.
>
> Move generic board sanity check to "prepare1" target,
> which is run after generation of include/autoconf.mk.
>
> Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
> ---
~                                  

[U-Boot] [PATCH 1/2] kbuild: Fix a false error of generic board support

[Tom Rini]

On Tue, Dec 16, 2014 at 02:56:44PM -0600, mgerlach wrote:

> Hello Masahiro Yamada,
> 
> Even the with this patch, we encountered a false error of generic board
> support.  The problem was very interrmittent for us, but we were able 
> to debug the problem to performing builds on EXT3 file systems which
> have a time stamp resolution of one second.  To reproduce the problem,
> touch ./include/config/auto.conf and .config on a configured uboot tree on
> an EXT3 file system.
> 
> The patch below fixes the problem for us.  

This makes an odd race condition problem I run into when doing massively
paralell builds worse :(  With MAKEALL no ARM boards build (ARCH wasn't
set in time so it tried arch//Makefile for something) and buildman was
also broken in a bunch of places.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20141216/ac75f115/attachment.pgp>

[U-Boot] [PATCH 1/2] kbuild: Fix a false error of generic board support

[Marek Vasut]

On Wednesday, December 17, 2014 at 12:56:46 AM, Tom Rini wrote:
> On Tue, Dec 16, 2014 at 02:56:44PM -0600, mgerlach wrote:
> > Hello Masahiro Yamada,
> > 
> > Even the with this patch, we encountered a false error of generic board
> > support.  The problem was very interrmittent for us, but we were able
> > to debug the problem to performing builds on EXT3 file systems which
> > have a time stamp resolution of one second.  To reproduce the problem,
> > touch ./include/config/auto.conf and .config on a configured uboot tree
> > on an EXT3 file system.
> > 
> > The patch below fixes the problem for us.
> 
> This makes an odd race condition problem I run into when doing massively
> paralell builds worse :(  With MAKEALL no ARM boards build (ARCH wasn't
> set in time so it tried arch//Makefile for something) and buildman was
> also broken in a bunch of places.

Let me just chime in, I recall I did report something possibly similar some time 
ago [1]. I did not manage to put a finger on this issue though and I can no 
longer trigger it.

[1] http://lists.denx.de/pipermail/u-boot/2013-June/157481.html

Best regards,
Marek Vasut

[U-Boot] [PATCH 1/2] kbuild: Fix a false error of generic board support

[Tom Rini]

On Wed, Dec 17, 2014 at 02:04:32AM +0100, Marek Vasut wrote:
> On Wednesday, December 17, 2014 at 12:56:46 AM, Tom Rini wrote:
> > On Tue, Dec 16, 2014 at 02:56:44PM -0600, mgerlach wrote:
> > > Hello Masahiro Yamada,
> > > 
> > > Even the with this patch, we encountered a false error of generic board
> > > support.  The problem was very interrmittent for us, but we were able
> > > to debug the problem to performing builds on EXT3 file systems which
> > > have a time stamp resolution of one second.  To reproduce the problem,
> > > touch ./include/config/auto.conf and .config on a configured uboot tree
> > > on an EXT3 file system.
> > > 
> > > The patch below fixes the problem for us.
> > 
> > This makes an odd race condition problem I run into when doing massively
> > paralell builds worse :(  With MAKEALL no ARM boards build (ARCH wasn't
> > set in time so it tried arch//Makefile for something) and buildman was
> > also broken in a bunch of places.
> 
> Let me just chime in, I recall I did report something possibly similar some time 
> ago [1]. I did not manage to put a finger on this issue though and I can no 
> longer trigger it.
> 
> [1] http://lists.denx.de/pipermail/u-boot/2013-June/157481.html

No, my problem was introduced with the switch to Kbuild itself.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20141217/2caa3f00/attachment.pgp>

[U-Boot] [PATCH 1/2] kbuild: Fix a false error of generic board support

[Masahiro Yamada]

Hi Marek, Tom,


On Wed, 17 Dec 2014 10:52:32 -0500
Tom Rini <trini@ti.com> wrote:

> On Wed, Dec 17, 2014 at 02:04:32AM +0100, Marek Vasut wrote:
> > On Wednesday, December 17, 2014 at 12:56:46 AM, Tom Rini wrote:
> > > On Tue, Dec 16, 2014 at 02:56:44PM -0600, mgerlach wrote:
> > > > Hello Masahiro Yamada,
> > > > 
> > > > Even the with this patch, we encountered a false error of generic board
> > > > support.  The problem was very interrmittent for us, but we were able
> > > > to debug the problem to performing builds on EXT3 file systems which
> > > > have a time stamp resolution of one second.  To reproduce the problem,
> > > > touch ./include/config/auto.conf and .config on a configured uboot tree
> > > > on an EXT3 file system.
> > > > 
> > > > The patch below fixes the problem for us.
> > > 
> > > This makes an odd race condition problem I run into when doing massively
> > > paralell builds worse :(  With MAKEALL no ARM boards build (ARCH wasn't
> > > set in time so it tried arch//Makefile for something) and buildman was
> > > also broken in a bunch of places.
> > 
> > Let me just chime in, I recall I did report something possibly similar some time 
> > ago [1]. I did not manage to put a finger on this issue though and I can no 
> > longer trigger it.
> > 
> > [1] http://lists.denx.de/pipermail/u-boot/2013-June/157481.html
> 
> No, my problem was introduced with the switch to Kbuild itself.


Marek's problem is unrelated to this issue.  (2013-June is before Kbuild)


York Sun also reported the similar build error in this thread.
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/203331/focus=203468

This is really related to what Mathew saw, I think.


Some bug reports imply "autoconf_is_current" is not working on some cases
although I have never been able to reproduce the problem on my box.

I guess it is almost time for further build-system refactoring.


Best Regards
Masahiro Yamada

[U-Boot] [PATCH 1/2] kbuild: Fix a false error of generic board support

[Masahiro Yamada]

Hi Matthew, Tom,



On Tue, 16 Dec 2014 18:56:46 -0500
Tom Rini <trini@ti.com> wrote:

> On Tue, Dec 16, 2014 at 02:56:44PM -0600, mgerlach wrote:
> 
> > Hello Masahiro Yamada,
> > 
> > Even the with this patch, we encountered a false error of generic board
> > support.  The problem was very interrmittent for us, but we were able 
> > to debug the problem to performing builds on EXT3 file systems which
> > have a time stamp resolution of one second.  To reproduce the problem,
> > touch ./include/config/auto.conf and .config on a configured uboot tree on
> > an EXT3 file system.
> > 
> > The patch below fixes the problem for us.  
> 
> This makes an odd race condition problem I run into when doing massively
> paralell builds worse :(  With MAKEALL no ARM boards build (ARCH wasn't
> set in time so it tried arch//Makefile for something) and buildman was
> also broken in a bunch of places.
> 

Me too.

Although I do not know why, Methew's patch makes it worse.
Without MAKEALL or buildman, I hit the same error every time.


$ LANG=C make -j8 CROSS_COMPILE=arm-linux-gnueabi-  ph1_ld4_defconfig all
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/kconfig/conf.o
  SHIPPED scripts/kconfig/zconf.tab.c
  SHIPPED scripts/kconfig/zconf.lex.c
  SHIPPED scripts/kconfig/zconf.hash.c
  HOSTCC  scripts/kconfig/zconf.tab.o
  HOSTLD  scripts/kconfig/conf
#
# configuration written to .config
#
#
# configuration written to spl/.config
#
./Makefile:511: arch//Makefile: No such file or directory
make[1]: *** No rule to make target `arch//Makefile'.  Stop.
make: *** [__build_one_by_one] Error 2


Best Regards
Masahiro Yamada

[U-Boot] [PATCH 1/2] kbuild: Fix a false error of generic board support

[mgerlach]

Hi Tom and Masahiro,

Neither my collegue nor I could reproduce the problem you encountered with 
our patch and the build line, "LANG=C make -j8 
CROSS_COMPILE=arm-linux-gnueabi-  ph1_ld4_defconfig all". Any
suggestions on other ways to fix the false error and not break paralell 
builds would be extremely appreciated.

Thanks,

Matthew Gerlach

On Thu, 18 Dec 2014, Masahiro Yamada wrote:

> Hi Matthew, Tom,
> 
> 
> 
> On Tue, 16 Dec 2014 18:56:46 -0500
> Tom Rini <trini@ti.com> wrote:
> 
> > On Tue, Dec 16, 2014 at 02:56:44PM -0600, mgerlach wrote:
> > 
> > > Hello Masahiro Yamada,
> > > 
> > > Even the with this patch, we encountered a false error of generic board
> > > support.  The problem was very interrmittent for us, but we were able 
> > > to debug the problem to performing builds on EXT3 file systems which
> > > have a time stamp resolution of one second.  To reproduce the problem,
> > > touch ./include/config/auto.conf and .config on a configured uboot tree on
> > > an EXT3 file system.
> > > 
> > > The patch below fixes the problem for us.  
> > 
> > This makes an odd race condition problem I run into when doing massively
> > paralell builds worse :(  With MAKEALL no ARM boards build (ARCH wasn't
> > set in time so it tried arch//Makefile for something) and buildman was
> > also broken in a bunch of places.
> > 
> 
> Me too.
> 
> Although I do not know why, Methew's patch makes it worse.
> Without MAKEALL or buildman, I hit the same error every time.
> 
> 
> $ LANG=C make -j8 CROSS_COMPILE=arm-linux-gnueabi-  ph1_ld4_defconfig all
>   HOSTCC  scripts/basic/fixdep
>   HOSTCC  scripts/kconfig/conf.o
>   SHIPPED scripts/kconfig/zconf.tab.c
>   SHIPPED scripts/kconfig/zconf.lex.c
>   SHIPPED scripts/kconfig/zconf.hash.c
>   HOSTCC  scripts/kconfig/zconf.tab.o
>   HOSTLD  scripts/kconfig/conf
> #
> # configuration written to .config
> #
> #
> # configuration written to spl/.config
> #
> ./Makefile:511: arch//Makefile: No such file or directory
> make[1]: *** No rule to make target `arch//Makefile'.  Stop.
> make: *** [__build_one_by_one] Error 2
> 
> 
> Best Regards
> Masahiro Yamada
> 
> 

[U-Boot] [PATCH 0/2] Kbuild: Fix a false error of sanity check

[Masahiro Yamada]

Masahiro Yamada (2):
  kbuild: Fix a false error of generic board support
  kbuild: Move linker sciript check to prepare1

 Makefile | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

-- 
1.8.3.2

[U-Boot] [PATCH 1/2] kbuild: Fix a false error of generic board support

[Masahiro Yamada]

Before this commit, make terminated with an error
where it shouldn't under some condition.

This bug happened when we built a board unsupporting
generic board right after building with generic board.

For example, the following sequence failed.
(harmony uses generic board but microblaze-generic does not
support it)

  $ make harmony_config
  Configuring for harmony board...
  $ make CROSS_COMPILE=arm-linux-gnueabi-
    [ Build succeed ]
  $ make microblaze-generic_config
  Configuring for microblaze-generic board...
  $ make CROSS_COMPILE=microblaze-linux-
  Makefile:488: *** Your architecture does not support generic board.
  Please undefined CONFIG_SYS_GENERIC_BOARD in your board config file.  Stop.

We had to do "make mrproper" before building the microblaze board.

This commit fixes this unconvenience.

Move generic board sanity check to "prepare1" target,
which is run after generation of include/autoconf.mk.

Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
---

 Makefile | 15 +++++++--------
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/Makefile b/Makefile
index 84d6db4..fffeb7e 100644
--- a/Makefile
+++ b/Makefile
@@ -485,13 +485,6 @@ ifeq ($(wildcard include/config.mk),)
 $(error "System not configured - see README")
 endif
 
-ifeq ($(__HAVE_ARCH_GENERIC_BOARD),)
-ifneq ($(CONFIG_SYS_GENERIC_BOARD),)
-$(error Your architecture does not support generic board. \
-Please undefined CONFIG_SYS_GENERIC_BOARD in your board config file)
-endif
-endif
-
 # If board code explicitly specified LDSCRIPT or CONFIG_SYS_LDSCRIPT, use
 # that (or fail if absent).  Otherwise, search for a linker script in a
 # standard location.
@@ -996,7 +989,13 @@ endif
 prepare2: prepare3 outputmakefile
 
 prepare1: prepare2 $(version_h) $(timestamp_h)
-	@:
+ifeq ($(__HAVE_ARCH_GENERIC_BOARD),)
+ifeq ($(CONFIG_SYS_GENERIC_BOARD),y)
+	@echo >&2 "  Your architecture does not support generic board."
+	@echo >&2 "  Please undefine CONFIG_SYS_GENERIC_BOARD in your board config file."
+	@/bin/false
+endif
+endif
 
 archprepare: prepare1 scripts_basic
 
-- 
1.8.3.2

[U-Boot] [PATCH 1/2] kbuild: Fix a false error of generic board support

[Masahiro Yamada]

Hello Tom,

On Mon, 24 Feb 2014 22:11:45 +0900
Masahiro Yamada <yamada.m@jp.panasonic.com> wrote:

> Before this commit, make terminated with an error
> where it shouldn't under some condition.
> 
> This bug happened when we built a board unsupporting
> generic board right after building with generic board.
> 
> For example, the following sequence failed.
> (harmony uses generic board but microblaze-generic does not
> support it)
> 
>   $ make harmony_config
>   Configuring for harmony board...
>   $ make CROSS_COMPILE=arm-linux-gnueabi-
>     [ Build succeed ]
>   $ make microblaze-generic_config
>   Configuring for microblaze-generic board...
>   $ make CROSS_COMPILE=microblaze-linux-
>   Makefile:488: *** Your architecture does not support generic board.
>   Please undefined CONFIG_SYS_GENERIC_BOARD in your board config file.  Stop.
> 
> We had to do "make mrproper" before building the microblaze board.

I've noticed a mistake here in commit log.
"make mrproper" should be "make clean".

So, correct description is:
We had to do "make clean" before building the microblaze board.


If possible, could you directly edit the commit log on your queue?

Or better to submit v2 ?

Best Regards
Masahiro Yamada