Hi Stephen,
Thanks for your analisys!
2015-04-02 7:33 GMT+09:00 Stephen Warren <swar...@wwwdotorg.org>:
> On 03/31/2015 06:02 AM, Masahiro Yamada wrote:
>>
>> Since the Kconfig conversion, some developers have reported that
>> Kbuild sometimes fails completely at random. According to the error
>> reports, it seems to occur for any target board, but only on very
>> fast computers.
>>
>> The log message for the fail case is like this:
>>
>> make[1]: *** No rule to make target `../arch//cpu/u-boot.lds',
>> needed by `u-boot.lds'. Stop.
>>
>> It looks like the top config.mk has not been included for *some*
>> reason, and $(ARCH) has been left blank.
>>
>> I suspect "autoconf_is_current" is not working in some situation.
>
>
> That's certainly true. The following code doesn't end up including config.mk
> in the bad case:
>
>> # We want to include arch/$(ARCH)/config.mk only when
>> include/config/auto.conf
>> # 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)))
>> ifneq ($(autoconf_is_current),)
>> include $(srctree)/config.mk
>> include $(srctree)/arch/$(ARCH)/Makefile
>> endif
>
>
> That's because:
>
>> [swarren@swarren-lx1 tegra-uboot-flasher]$ ls -l --full-time
>> u-boot-*/{.config,include/config/auto.conf}|cat
>> -rw-rw-r-- 1 swarren swarren 9219 2015-04-01 15:50:08.000000000 -0600
>> u-boot-bad/.config
>> -rw-rw-r-- 1 swarren swarren 928 2015-04-01 15:50:08.000000000 -0600
>> u-boot-bad/include/config/auto.conf
>> -rw-rw-r-- 1 swarren swarren 9219 2015-04-01 15:51:25.000000000 -0600
>> u-boot-ok/.config
>> -rw-rw-r-- 1 swarren swarren 928 2015-04-01 15:51:26.000000000 -0600
>> u-boot-ok/include/config/auto.conf
>
>
> In the bad case, the timestamps are equal (and hence the -newer check
> fails), whereas in the good case they're different. Recall ext* filesystems
> have a 1s timestamp resolution.
It makes sense that this problem happens more frequently on faster computers.
> Note that this is state left over from "make xxx_defconfig"; If I just
> manually run "make all" in a tree in this state, it'll stay in this state
> forever, and vice-versa for a working tree.
>
> I expect that simulating this condition with some judicious manually
> executed touch commands would be extremely easy.
>
> Possible solutions are:
>
> Is there a -newer-or-equal that could be used in the find command rather
> than -newer?
I checked the "man find", but I could only find a -newer option,
but it works enough for our purpose.
Please check if this patch solves the problem:
http://patchwork.ozlabs.org/patch/457838/
> When running "make xxx_defconfig", can the code there compare the timestamp
> of those two files, and keep looping and touching the auto.conf file until
> the timestamps differ.
>
> Something else entirely? I couldn't see anything relating to
> autoconf_is_current in the kernel's makefiles.
Right. The kernel does not need this hack.
When we build the kernel, ARCH= is given from the command line,
i.e. the correct arch/${ARCH}/Makefile is always included.
(In other words, it is users who are responsible
for passing the correct ARCH from the command line.)
For U-boot, on the other hand, ARCH is decided by the board configuration.
(It was done by mkconfig+boards.cfg, and it is by Kconfig now.)
If we build ARM board after PowerPC board, for example,
the .config points to ARM, but include/config/auto.conf to PowerPC,
it causes a wrong arch/${ARCH}/{config.mk,Makefile} to be included at
the first run.
I know the autoconf_is_current is an ugly hack,
but it requires more changes to the build system to rip it off.
--
Best Regards
Masahiro Yamada
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
