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 <tr...@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 <s...@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
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
