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

[Simon Glass]

Hi Tom,

On 26 September 2014 09:24, Tom Rini <trini at ti.com> 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.
>
> 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).
>

If you look at Exynos there is a static table of information.
See ./arch/arm/include/asm/arch-exynos/spl.h. In Chrome OS this is just
copied from the device tree by a tool, so in principle it would be good to
just have the DT available in SPL. There is actually no impediment to this
really, it was done at the time to save time for the two settings that were
needed and it grew from there. Provided that the DT is available I think it
can in principle be used for everything, but I suppose there may be hard
cases / exceptions. I feel that DT should buy Stephen flowers as there
seems to have been a falling out :-)


>
> Of course there's lots of other fun bits around here to worry and think
> about.
>
> --
> Tom
>

Regards,
Simon