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

[Tom Rini <trini@ti.com>]

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@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@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.

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.
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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140926/aadfad25/attachment.pgp>