[PATCH 10/17] bootwrapper: Add dt_set_mac_addresses().

[Timur Tabi]

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.

>> 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