David Gibson wrote:

I mean, does the u-boot source tree have its own copies of the dts
files which are built into a dtb during the u-boot build process?  

No.

Or
do you take the dts from the kernel tree and make the dtb from that
when you build a dtb aware u-boot for a particular machine?

You don't build the DTB with U-Boot.  You build the DTB completely separately from U-Boot. 
  As far as U-Boot concerned, until you actually boot the kernel, the DTB is just another 
binary blob.

Yes, but if have a version of u-boot that *only* sets mac-address and
not local-mac-address, doing so would clobber the only information
about the MAC address we have. 

That's true.

In any case, I don't think is relevant
for discussion of this function, because its only designed for use
with *non* device tree aware firmware.

Ok.

In terms of the generated dtb output there is no difference.  Well,
probably.  It would It's
purely syntactic sugar / internal documentation.

Then I suggest we just leave the compiler as is, and just update the U-Boot documentation 
to specify what it does with the various device tree properties.

quoted

In both cases, the property exists in the DTS.  The whole point was to 
remove it from the DTS entirely, 

Well, no.  You wanted to get rid of the property from the dts, I
didn't.  What I'm suggesting here is an idea to addresses at least one
possible objection to having the properties in the dts: the fact that
with actual values there it looks like the tree is complete and it
might not be obvious that a bootloader *must* tweak values to produce
a working tree.

Hmmm... I can understand that.  But I still think documenting it in U-Boot is the easier 
solution.

I think it's useful to document in the dts that certain properties are
expected to be there, even if their actual values have to be
determined during boot. 

The only problem with this is that the list of properties needed/used by U-Boot can change 
from one version of U-Boot to another, and I'd hate to have to update all of the DTS files 
every time this happens.

For instance,

It has the nice additional
property that it lets the bootloader avoid extra memmove()s and
possibly string table scans.

True, but I don't see why we should go through such an effort to avoid these things. 
Besides, JVB is almost done getting libfdt into U-Boot, and that should make all this moot.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale