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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot