Hi, On Wed, May 29, 2013 at 4:07 PM, Stephen Warren <swar...@wwwdotorg.org>wrote:
> On 05/29/2013 04:36 PM, Wolfgang Denk wrote: > > Dear Stephen Warren, > > > > In message <51a67ec1.2000...@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
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
