[PATCH] ARM: multi_v7_defconfig: Enable BCM283x

[Stephen Warren]

On 02/05/2016 11:50 PM, Stephen Warren wrote:
> 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.

Yes, fixing this issue in U-Boot does solve the hang with simplefb
enabled. Here's the U-Boot patch:

http://lists.denx.de/pipermail/u-boot/2016-February/244869.html
[PATCH] video: bcm2835: use bus_to_phys() on FB address

Hence for this patch, I'd say,
Tested-by: Stephen Warren <swarren at wwwdotorg.org>

BTW, bcm2835 really needs both ARMv6 and ARMv7 support enabled to be
useful on all Pis. I can send a patch for that in a while.

multi_v7_defconfig won't work on RPi0/1 since those are ARMv6 devices. I
suppose it doesn't make sense to add ARMv6 support into
multi_v7_defconfig...