[U-Boot] [PATCH v3 09/10] kconfig: move CONFIG_OF_* to Kconfig

[Stephen Warren]

On 09/26/2014 07:49 AM, Tom Rini wrote:
> On Thu, Sep 25, 2014 at 07:44:30AM -0600, Simon Glass wrote:
>> Hi,
>>
>> On 25 September 2014 07:18, Tom Rini <trini at ti.com> wrote:
>>> On Thu, Sep 25, 2014 at 04:38:09PM +0900, Masahiro Yamada wrote:
>>>> Hi Simon,
>>>>
>>>>
>>>>
>>>> On Wed, 24 Sep 2014 17:08:11 -0600
>>>> Simon Glass <sjg at chromium.org> wrote:
>>>>
>>>>>> +config OF_EMBED
>>>>>> +       bool "Embedded DTB for DT control"
>>>>>> +       help
>>>>>> +         If this option is enabled, the device tree will be picked up and
>>>>>> +         built into the U-Boot image.
>>>>>
>>>>> Can you please add " This is suitable for debugging
>>>>> and development only and is not recommended for production devices."
>>>>
>>>>
>>>> Why is CONFIG_OF_EMBED not recommended for production devices?
>>>
>>> It's kind-of a question for the devicetree folks.  The last time (a
>>> while back now) I asked for some general advice on how a DT should be
>>> shipped with hardware, being able to update the DT without replacing the
>>> whole of firmware was seen as a good thing.  Combine this with that we
>>> should try (yes, we can't today due to incompatible bindings) share the
>>> DT between U-Boot and the kernel (or really, U-Boot and anything but
>>> again, last I checked the BSD bindings were very very different),
>>> embedding doesn't seem good.
>>
>> Addressing the binding differences, it's hard to see what these are
>> right now since the sorting and other churn in the Linux device tree
>> files. I think it would be good to sync the U-Boot files to the Linux
>> ones so we can see what bindings still differ.
>
> Yes, agreed.

There's a difference between:

a) The DT that U-Boot uses.

b) The DT that is passed to the kernel.

I don't see any problem embedding (a) into the U-Boot binary at all, 
since U-Boot is the only consumer. There's no need to update the DT 
separately. Even when not using CONFIG_OF_EMBED, the DT really is 
logically part of the bootloader.

(b) is the case where people care about updating the DT separately from 
the firmware.

Now, if we ever get to the point where we pass the same DT to both 
U-Boot and the kernel, then yes, embedding the DT into the U-Boot binary 
would be a bad idea, since the DT couldn't be updated separately then.

However, I think it's a bad idea to pass the same DT to both, since then 
updating it might break your bootloader and kernel, rather than just 
your kernel, which complicates recovery. Ideally, the only thing shared 
between bootloader and kernel should be the ability for the bootloader 
to load data (DT, initrd, kernel image) into memory, set up the 
appropriate CPU state, and jump to the kernel.