Hi,
On Wed, May 29, 2013 at 4:07 PM, Stephen Warren swarren@wwwdotorg.orgwrote:
On 05/29/2013 04:36 PM, Wolfgang Denk wrote:
Dear Stephen Warren,
In message 51A67EC1.2000208@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