On Thu, Feb 19, 2015 at 05:50:37PM +0900, Masahiro Yamada wrote: > Hi. > > > > On Wed, 18 Feb 2015 23:00:36 -0700 > Stephen Warren <swar...@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 <swar...@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.
I'm OK waiting, it is a real pain in the butt to trigger race. -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot