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

[Stephen Warren]

On 02/19/2015 01:50 AM, Masahiro Yamada wrote:
> On Wed, 18 Feb 2015 23:00:36 -0700
> Stephen Warren <swarren at 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 at 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?