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

[Stephen Warren <swarren@wwwdotorg.org>]

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.