[U-Boot] [PATCH V3 3/3] rpi: add support for Raspberry Pi 2 model B

[Tom Rini <trini@ti.com>]

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 <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.

I'm OK waiting, it is a real pain in the butt to trigger race.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150219/20d7c87a/attachment.sig>