[U-Boot] U-boot 2017.07 not working on Raspberry Pi

[Stephen Warren]

On 08/25/2017 03:46 AM, Paul Barker wrote:
> On Fri, Aug 25, 2017 at 2:46 AM, Simon Glass <sjg at chromium.org> wrote:
>> Hi,
>>
>> On 20 August 2017 at 20:59, Simon Glass <sjg at chromium.org> wrote:
>>> Hi Paul,
>>>
>>> On 3 August 2017 at 11:42, Tom Rini <trini at konsulko.com> wrote:
>>>> On Thu, Aug 03, 2017 at 09:42:13AM -0600, Stephen Warren wrote:
>>>>> On 08/03/2017 07:45 AM, Simon Glass wrote:
>>>>> ...
>>>>>> I'm not sure if we have a Raspberry Pi in a test farm anywhere. I
>>>>>> should be able to look next week if no one can figure these out
>>>>>> beforehand.
>>>>>
>>>>> I thought that Tom had some Pis in his test farm?
>>>>
>>>> I have an RPi 3, but we don't have Linux boot tests atm.  I'm talking
>>>> with Kevin Hilman about how I might setup kernelci to test a few things
>>>> in my lab, which might catch this kind of problem sooner rather than
>>>> later.
>>>
>>> Just a note that I can repeat the CONFIG_OF_EMBED problem. I am not
>>> sure what is going on or why this would prevent the kernel booting.
>>> But I believe rpi has a device tree pass-through from the pre-U-Boot
>>> boot loader, and I am booting with that, so perhaps it relies on
>>> CONFIG_OF_EMBED in some way?
>>
>> I can see some code in board_fdt_blob_setup() but it does not seem to
>> be enabled. For me I am able to boot Linux without CONFIG_OF_EMBED.
>>
>>>
>>> I can also repeat the USB keyboard problem. It doesn't detect the
>>> keyboard at all. For me this can be fixed by enabling
>>> CONFIG_DM_KEYBOARD, so we should probably do that for all rpi boards.
>>
>> I have sent a patch for this.
> 
> This patch looks good. I've now got working keyboard and network in
> u-boot along with a successful boot of Linux for the 2 devices I've
> tested (Original rpi and rpi3 32-bit) from the following:
> 
> * U-boot 2017.07 release
> * Revert "dm: arm: rpi: Drop CONFIG_OF_EMBED" (25877d4e)
> * Apply backported version of your patch
> 
> The rpi firmware does provide a device tree blob at boot and my only
> guess is that this is currently being overwritten or ignored. That's
> masked when CONFIG_OF_EMBED is enabled as we use an embedded device
> tree instead of the one provided by the rpi firmware.

As background information, note that there are two ways U-Boot can work:

1) Load a DTB from "disk", and pass that to the kernel. This is 
typically used for upstream kernels, since at least historically the 
DTBs supplied by the RPi Foundation and loaded/modified by the VideoCore 
firmware use a non-upstream schema, so need to be replaced with an 
upstream-compatible DTB by U-Boot.

2) Pass through the DTB from the VideoCore firmware to the kernel. This 
is almost certainly required when booting a downstream RPi Foundation 
kernel.

Historically, U-Boot has only implemented option 1. I think recent 
versions of U-Boot support option 2, although you'd have to make some 
configuration(environment) changes to use that method. That's because 
historically, U-Boot has been targeted at booting upstream kernels.

I haven't investigated whether any of this is related to the problem 
you're seeing.