[U-Boot] [PATCH] fdt: Enhance dts/Makefile to be all things to all men

[Simon Glass]

Hi,

On Wed, May 29, 2013 at 4:07 PM, Stephen Warren <swarren at wwwdotorg.org>wrote:

> On 05/29/2013 04:36 PM, Wolfgang Denk wrote:
> > Dear Stephen Warren,
> >
> > In message <51A67EC1.2000208 at wwwdotorg.org> you wrote:
> >>
> >> To keep this process in check a bit, we could always pick a specific git
> >> commit or release version of dtc that each U-Boot version (release) will
> >> be allowed to assume. That will limit the number of times people need to
> >> update their locally-built dtc to at most once per U-Boot release.
> >> Hopefully much less often.
> >
> > I think this is broken by design, in several aspects.  First, U-Boot
> > is usually not the only user of DTC.  Second, assume you run a "git
> > bisect" over a U-Boot tree - would you really want to switch DTC in-
> > flight?
> >
> > Sorry, instead we should strive to be compatible to a reasonably old,
> > stable version of DTC, like we do for all other tools as well.  As
> > mentioned before - just because RHEL 5 ships an ancient version of -
> > say - "make" we will NOT start building this from the sources ourself.
> > This cannot be the way to go.
>
> So the result of that is that we can never ever use new features in any
> tool, at least in any meaningful time-frame.
>
> I think we need to differentiate between tools that are already stable
> and/or core to all aspects of the U-Boot build process (such as make),
> and tools that enable new features that are under development.
>
> Clearly the U-Boot makefiles have to be fairly cautious in their use of
> any new make features, so that everyone with any reasonable version of
> make can build U-Boot.
>
> However, when enabling a new feature, such as using device trees to
> configure U-Boot[1], for which tool support is new and evolving along
> with the feature itself, and which is only used on a very very few
> boards and even fewer SoCs right now within U-Boot, it seems entirely
> reasonable to demand that the people working on/with that new feature
> are aware that it's evolving, and that they may need to take a few extra
> steps to go out and get tools that support that new feature. No doubt
> once this feature has settled down a bit, and distros have pulled in
> newer versions of dtc, everthing will "just work" just like any other
> stable feature.
>
> If you don't accept this, then we simply have to ban any include use in
> U-Boot; dtc -i isn't in distro-packaged versions of dtc, so we'd need to
> stop using that. We'd need to move *.dts into a single directory within
> U-Boot to work around that, or perhaps hard-coding relative include
> paths in *.dts might work. Similarly for the patches to support dtc+cpp
> usage, so we wouldn't be able to use named constants in DT files for
> many years, which would prevent sharing DT files with the kernel and/or
> any other standard repository of DT files, which are bound to use this
> feature.
>
> [1] Which is very specifically a different feature than simply having
> U-Boot pass a DT to the Linux kernel during boot, and perhaps modify it
> a little, which clearly is not a new feature.
>

My patch:

- doesn't require -i but uses it if available (ARCH_CPU_DTS works around
this)
- honours #define, #include, etc.
- works with old and new versions of dtc
- uses -Ulinux which we are thinking might be better done another way

Let's not throw the baby out with the bathwater. I have no problem with
updating my dtc as needed, but it would certainly be nice if U-Boot didn't
require this.

However, let's say Tegra needs a newer dtc than 1.3. I wonder whether we
should just add a setting to tell U-Boot to not build the device tree at
all? The same U-Boot binary can run on many different board times, just
needing a different device tree. Rather than pick one, we could just pick
none. Then if you want to use new features in dtc, just define
CONFIG_OF_NO_BUILD, or similar, and you can deal with the device tree
details yourself. MAKEALL/buildman will be happy with this.

Otherwise for now I think my patch is a reasonable compromise in terms of
features.

Regards,
Simon