[PATCH] ARM: multi_v7_defconfig: Enable BCM283x

[Stephen Warren]

On 02/05/2016 11:07 PM, Stephen Warren wrote:
> On 02/05/2016 01:15 PM, Eric Anholt wrote:
>> Daniel Stone <daniels at collabora.com> writes:
>>
>>> Enable the BCM2835/BCM2836 options required to boot Raspberry
>>> Pi.
>>>
>>> Signed-off-by: Daniel Stone <daniels at collabora.com>
>>>
>>>> Cc: Eric Anholt <eric at anholt.net>
>>> Cc: Stephen Warren <swarren at wwwdotorg.org> Cc: Lee Jones
>>> <lee at kernel.org> Cc: Olof Johansson <olof at lixom.net> ---
>>
>> (Adding Arnd, who had asked me to update multi_v7_defconfig)
>>
>> Thanks!  I was trying to follow the process someone had told me for
>> how to start updating a defconfig by using "make
>> multi_v7_defconfig; make savedefconfig".  Even without a menuconfig
>> for my own changes in between, I was getting surprising things like
>> ARCH_MULTI_V7 not being in the defconfig output.
>>
>> However, with your patch I'm failing to get anything out of booting
>> this -- serial prints nothing after u-boot hands off, and even with
>> the regression fixes for dwc2 stacked on top, the network never
>> comes up. Did you test the built kernel?
> 
> I seem to have similar issues. I see a hang if DEBUG_LL/earlyprintk
> aren't enabled, and an immediate reset if they are.

Uggh; user error there. When I enable DEBUG_LL/earlyprintk, I do start
to see the kernel booting, but there's a hang during the boot process.

I tracked the hang down to simplefb; I modified U-Boot not to add/enable
the simplefb node in DT, and I managed to get to the (serial console)
login prompt using multi_v7_defconfig with this patch applied.

> As an aside I'm using U-Boot to boot the kernel not just the binary
> FW, and I needed the following U-Boot patch to get even
> bcm2835_defconfig working on the RPi2 (and even then that only seems
> to work with DEBUG_LL/earlyprintk enabled with the bcm2836 physical
> addresses, and "console=tty1" removed from the kernel command-line).

Aha. Disabling simplefb also helps with bcm2835_defconfig. With simplefb
in use as the console, the system would hang mid-boot just like with
multi_v7_defconfig. With "console=tty1" removed from the command-line
but simplefb still probing, the system would hang immediately before I'd
expect the serial login prompt to be printed. With simplefb removed from
DT and so the driver not probing at all, I can boot and log in with
bcm2835_defconfig on RPi2.

This might be because the RPi2 U-Boot is using the wrong address for the
framebuffer RAM. The top 2 MSBs indicate some form of on-SoC caching
configuration and need to be different between RPi1 and RPi2. I fixed
this issue for the RAM that dwc2 uses, but I think I never made the same
fix to the framebuffer RAM address. Perhaps that's the issue. I'm not
sure why it doesn't hang in U-Boot though. Perhaps the MMU configuration
is different and so U-Boot doesn't trigger some specific access pattern
on the bus.

> http://lists.denx.de/pipermail/u-boot/2016-February/244831.html
> ARM: rpi: set fdt_high in the default environment