<div dir="ltr">Hi Stephen,<div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 29, 2013 at 10:11 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 05/29/2013 10:46 PM, Simon Glass wrote:<br>
> Hi,<br>
><br>
> On Wed, May 29, 2013 at 4:07 PM, Stephen Warren <<a href="mailto:swarren@wwwdotorg.org">swarren@wwwdotorg.org</a><br>
</div><div class="im">> <mailto:<a href="mailto:swarren@wwwdotorg.org">swarren@wwwdotorg.org</a>>> wrote:<br>
><br>
> 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><br>
</div><div><div class="h5">> <mailto:<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<br>
> specific git<br>
> >> commit or release version of dtc that each U-Boot version<br>
> (release) will<br>
> >> be allowed to assume. That will limit the number of times people<br>
> 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>
> 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>
><br>
><br>
> My patch:<br>
><br>
> - doesn't require -i but uses it if available (ARCH_CPU_DTS works around<br>
> this)<br></div></div></blockquote><div><br></div><div style>I had to remove all sharp objects from the room half-way through reading your email :-) Gosh, things aren't that bad!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div class="h5">
<br>
</div></div>If we ever need to support a dtc that doesn't implement -i, then we<br>
always need to support that. So, there's no point using -i when it's<br>
available; we should simply have a single way of writing the *.dts files<br>
that doesn't ever assume dtc -i is available. Otherwise, there will be<br>
rampant inconsistency between different *.dts files; how they're<br>
written, the flow by which they're compiled, etc.<br>
<br>
In other words, we /always/ have to use "ARCH_CPU_DTS" in *.dts<br>
throughout the entire U-Boot source tree if we're to support not using<br>
dtc -i.<br></blockquote><div><br></div><div style>Well realistically at some point there will be a new dtc release, and perhaps a year or so after that we can maybe start deprecating this and requiring -i.</div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> - honours #define, #include, etc.<br>
> - works with old and new versions of dtc<br>
<br>
</div>If we are forced to rely only upon features in old versions of dtc, we<br>
specifically shouldn't allow use of features that will only work with<br>
newer dtc. If we don't actively enforce this rule, we haven't achieved<br>
the goal of not relying upon new versions of dtc.<br></blockquote><div><br></div><div style>As you know I'm uncomfortable with the idea of using CPP to do things that I feel dtc should do for itself, but yes if dtc does not grow these features, we have little choice. But as an example, both #include and symbols can be syntactically very similar whether CPP is used or not.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
...<br>
<div class="im">> However, let's say Tegra needs a newer dtc than 1.3. I wonder whether we<br>
<br>
</div>This shouldn't be about whether a specific Soc's DT requires some<br>
feature or not. All the U-Boot *.dts should work the same way.<br>
<div class="im"><br>
> should just add a setting to tell U-Boot to not build the device tree at<br>
> all? The same U-Boot binary can run on many different board times, just<br>
> needing a different device tree.<br>
<br>
</div>Unfortunately, that's not remotely true yet for any Tegra system at<br>
least; there's still a bunch of C code specific to each board. The<br>
amount is reducing as things get migrated to DT, but we certainly aren't<br>
there yet.<br></blockquote><div><br></div><div style>OK, but that wasn't quite my point.... </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> Rather than pick one, we could just<br>
> pick none. Then if you want to use new features in dtc, just define<br>
> CONFIG_OF_NO_BUILD, or similar, and you can deal with the device tree<br>
> details yourself. MAKEALL/buildman will be happy with this.<br>
<br>
</div>So you're saying: move the *.dts files out of U-Boot into some separate<br>
project. It'd be nice to do that; hopefully that separate project could<br>
be the one where the kernel's *.dts files move to. The big issue here is<br>
that the DT bindings U-Boot uses are often different to the standard<br>
bindings, so U-Boot currently contains U-Boot-specific *.dts so there<br>
wouldn't be much point moving them out of U-Boot into some common DT<br>
repository. Again, hopefully that's changing over time, but we're still<br>
not there yet.<br></blockquote><div><br></div><div style>a. I didn't say move them out of U-Boot</div><div style>b. If there are differences between the U-Boot and kernel bindings, we should fix that</div><div style>
c. My point was that 'building nothing' fudges the 'failed build' problem and might be an acceptable compromise. Then Tegra can use the whiz-bang new features without breaking the build.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> Otherwise for now I think my patch is a reasonable compromise in terms<br>
> of features.<br>
<br>
</div>It seems to be aimed specifically at enabling use of new dtc features<br>
when present. That seems to be specifically against Wolfgang's goal of<br>
not requiring new dtc features. There's no point allowing use of new dtc<br>
features if we can't require them, since there's no fallback when they<br>
aren't there to use.<br>
</blockquote></div><br></div><div class="gmail_extra" style>My patch is specifically designed to provide a fallback when the are not there to use. I'm not sure how feasible this is long term, but it works for now.</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>I have no problem with including dtc in with U-Boot if that is the chosen approach. It solves some problems. In fact my Kbuild patch set could make that quite easy. However I do understand Wolfgang's POV that it is philosophically a dangerous path.</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>You know my strong support for some sort of symbolic support in dtc, and I share your frustration that it hasn't happened yet.</div><div class="gmail_extra" style>
<br></div><div class="gmail_extra" style>Is my patch better than what is there, or is it just making things worse?</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> </div></div>