Hi.
On Wed, 18 Feb 2015 23:00:36 -0700 Stephen Warren swarren@wwwdotorg.org wrote:
On 02/17/2015 01:22 PM, Tom Rini wrote:
On Tue, Feb 17, 2015 at 12:35:41PM -0700, Stephen Warren wrote:
On 02/16/2015 06:03 PM, Tom Rini wrote:
On Mon, Feb 16, 2015 at 12:16:15PM -0700, Stephen Warren wrote:
USB doesn't seem to work yet; the controller detects the on-board Hub/ Ethernet device but can't read the descriptors from it. I haven't investigated yet.
Signed-off-by: Stephen Warren swarren@wwwdotorg.org --- v3: Rebased on top of u-boot-dm merge. v2: Implement new board_rev decoding scheme, to avoid hard-coding the board revision onthe RPi 2.
+(rpi_2) make[3]: *** No rule to make target `arch/arm/cpu/armv7/bcm2835/../../arm1176/bcm2835//init.o', needed by `arch/arm/cpu/armv7/bcm2835/built-in.o'. Stop. +(rpi_2) make[2]: *** [arch/arm/cpu/armv7/bcm2835] Error 2 +(rpi_2) make[1]: *** [arch/arm/cpu/armv7] Error 2
When I try and build it with buildman. Something get left out somewhere? Thanks!
I've reproduced this error on my machine at work, where I previously worked out the right stuff to put into ~/.buildman.
Now that I try the regular build process (in-tree build using just make) multiple times after a "git clean -f -d -x" , I see the same error that way too, sometimes, so it's nothing to do with buildman.
However, I don't always get the error with either plain make or with buildman, and it doesn't always complain about the same file:
+make[1]: *** No rule to make target `arch//cpu/u-boot.lds', needed by `u-boot.lds'. Stop.
+make[3]: *** No rule to make target `arch/arm/cpu/armv7/bcm2835/../../arm1176/bcm2835//init.o', needed by `arch/arm/cpu/armv7/bcm2835/built-in.o'. Stop.
This isn't anything to do with these patches; I can see the exact same issue building the following existing boards in unmodified u-boot/master:
rpi (arm1176, no SPL) tnetv107x_evm_defconfigs (arm1176 no SPL) mx35pdk_defconfig (arm1136, no SPL) nhk8815_defconfig (arm926ejs, no SPL) imx27lite_defconfig (arm926ejs, SPL) vexpress_ca15_tc2_defconfig (ARMv7, no SPL)
Strangely I don't see the issue for:
seaboard (ARMv7, SPL) maxbcm_defconfig (ARMv7, SPL)
I wonder if bisecting would show up where this issue was introduced.
I bet it will and I bet it's when we switch to Kconfig. Masahiro, any ideas?
Yes, a git bisect (running up to 100 successful builds to test each commit, or failing on the first failure) says:
first bad commit: [51148790f26e42ef1fd4a1a8d056bf0252539525] kconfig: switch to Kconfig
(which was applied at the end of July last year)
Interesting: The problem never seems to happen on my laptop (where I do all my rpi dev work), but is quite easy to reproduce on my faster machine at work. I would guess it only affects parallel builds in certain timing circumstances, but haven't checked that.
Sorry for my late reply and inconveniene about this.
I recongnize this problem is the same as what has been reported by some people for a few months.
Although I have never been able to reproduce this problem (I guess my computer is too slow...), I do understand this is a real, significant and urgent problem.
I bet the root cause of this issue is the following lines.
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
This comes from the difference about how ARCH is given.
In Linux, ARCH is given from the command line by the user, so the correct arch/$(ARCH)/Makefile can be always included.
In U-boot, on the other hand, ARCH is decided by Kconfig. It is impossible to include arch/$(ARCH)/Makefile until Kconfig creates the include/configs/auto.conf for the target board, i.e. "make silentoldconfig" is done.
I do not know the reason exactly, but $(autoconf_is_current) might not be set correctly in some cases depending on some race condition.
Of course, if we adopted the "ARCH from the command line", this problem would immediately go away, but I am not sure how many people are happy about the more typing every time, considering that most of the target boards of U-Boot use cross-compiling.
I will take a closer look on it, but I am doing some big changes for the build system.
- single .config switch ( I have just posted the series.) - Moving SoC directory arch/arm/cpu/$(CPU)/$(SOC) -> arch/arm/mach-$(SOC)
As usual, I'd like to solve the problems one by one, so as not to mess up things by big conflicts.
Best Regards Masahiro Yamada