<div dir="ltr">Hi,<div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 29, 2013 at 4:07 PM, Stephen Warren <span dir="ltr"><<a href="mailto:swarren@wwwdotorg.org" target="_blank">swarren@wwwdotorg.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On 05/29/2013 04:36 PM, Wolfgang Denk wrote:<br>

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