On 02/19/2015 01:50 AM, Masahiro Yamada wrote:
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.
Was there any progress on this front? I'm still seeing the problem in
latest u-boot.git master branch. I've been hitting it a little more
often today; not sure if the repro frequency has changed or if I just
did a few more builds than usual?
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
