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

[Stephen Warren]

On 09/26/2014 09:24 AM, Tom Rini wrote:
> On Fri, Sep 26, 2014 at 08:52:11AM -0600, Stephen Warren wrote:
>> 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.
>
> Well part of the issue here is that at some decent levels of thinking
> why wouldn't (a) be at least a strict subset (generated?) of (b) ?
>
>> 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.
>
> Well, the issue is that I've heard of some interest in trying to move
> forward with the case where U-Boot and Kernel share a DT or at least
> bundling one with another.

Well, it depends on what you mean by "sharing a DT".

Certainly, they should share the same DT bindings (schema), so there's 
only one way of defining each device/feature/... in DT.

Certainly, they should share identical DT source files (*.dts). Or 
perhaps the U-Boot one is a subset of the kernel one, but at least 
identical content where they define the same thing.

This in turn means they'd share identical DT binary content (*.dtb), 
again perhaps with the same subset argument.

However, sharing the same physical copy of the DT in storage seems 
dangerous, since then you can't update the DT you pass to the kernel 
without risking something going wrong with the bootloader if the 
bootloader doesn't like the new DT you want to pass to the kernel.

Given that last point, CONFIG_OF_EMBED doesn't seem like any kind of 
problem to me; the DT copy that U-Boot uses would be strictly for U-Boot 
anyway, so there's no "separate updating" argument, and updating a DT 
that U-Boot uses is just as dangerous as updating the U-Boot code itself.

> Now in my mind, it seems somewhat likely that we'll need to have "SPL"
> which has hard-coded information to it and just can't rely on a full DT
> being present and used and that loads U-Boot which can use a full DT.

Indeed, that was the point I was making to Simon earlier on. My thoughts 
are that if U-Boot needs hard-coded information anywhere, it should just 
use it always and not use DT. However, if U-Boot really wants to use DT, 
it should always use it and not have hard-coded tables of devices at 
all. Mixing both seems like a maintenance disaster. I would obviously 
prefer not using DT at all myself, in a bootloader at least.

> In that case watchdog+bootcount+redundant image is recovery path
> (watchdog cycles, bootcount sees we failed N times to get into something
> further, picks backup version to boot).
>
> Of course there's lots of other fun bits around here to worry and think
> about.