[U-Boot] [RFC PATCH] arm: bootm: Boot kernel with U-Boot's FDT blob

[Stephen Warren]

On 01/10/2017 09:58 AM, Alexander Graf wrote:
> On 01/10/2017 05:47 PM, Ryan Harkin wrote:
>> On 10 January 2017 at 16:35, Alexander Graf <agraf at suse.de> wrote:
>>> On 01/10/2017 05:31 PM, york sun wrote:
>>>> On 01/10/2017 05:02 AM, Alexander Graf wrote:
>>>>> On 01/10/2017 01:58 PM, Michal Simek wrote:
>>>>>> U-Boot configured via DTB can use the same DTB for booting the
>>>>>> kernel.
>>>>>> When OF_CONTROL is used fdtcontroladdr is setup and can be use for
>>>>>> boot.
>>>>>>
>>>>>> Signed-off-by: Michal Simek <michal.simek at xilinx.com>
>>>>>> ---
>>>>>>
>>>>>> Didn't check if there is any side effect or not but it looks weird
>>>>>> when
>>>>>> you have DT driver u-boot that you have to load dtb again.
>>>>> I agree, and I think it's very reasonable to try and use the same
>>>>> device
>>>>> tree for U-Boot and Linux.
>>>>>
>> Would this prevent the user loading a DTB into ram and using bootm to
>> over-ride the built-in DTB?
>>
>> I have a background task to refactor u-boot support for ARM Ltd
>> boards. One of many options I was considering was to have a minimal
>> DTB to configure the platform with only the nodes needed for u-boot.
>> The ARM Ltd device trees fluctuate so much, I wouldn't be able to
>> commit to one DTB that will work forever...
>
> No, it's only meant as a fallback when no manual device tree is
> provided. In an ideal world however, device trees are static and
> complete, so you could just put a final dt into U-Boot and have it
> propagated all the way through.

Can the commit message be updated to reflect this? From the commit 
message, it sounds like the control FDT will always be used. Something 
like "arm: bootm: fall back to U-Boot's FDT blob when booting kernel" 
would sound a lot less scary.