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

[David Gibson <david@gibson.dropbear.id.au>]

On Thu, Mar 22, 2007 at 10:15:16AM -0500, Jon Loeliger wrote:
> On Wed, 2007-03-21 at 19:06, 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?
> 
> There are not DTS files in U-Boot anymore.  They are all
> currently in the arch/powerpc/boot/dts directory, or some
> other private home directory. :-)

Ok

> >   Or
> > do you take the dts from the kernel tree and make the dtb from that
> 
> yes.
> 
> > when you build a dtb aware u-boot for a particular machine?
> 
> Do it whenever you want.  But it has to be downloaded
> to RAM or found in flash on the board by U-Boot by the
> time you want to do the hand-off to Linux.  That is,
> there is no need to "combine" it with U-Boot to make
> it "dtb aware".  U-Boot is still built independently of
> any DT[SB] file entirely.
> 
> > > Ok, I understand now, but I don't know what value it has.  I don't see 
> > > the difference, from the DTS point-of-view, between
> > > 
> > > 	local-mac-address = [ 00 00 00 00 00 00 ]
> > > and
> > > 	local-mac-address = [ ? ? ? ? ? ? ];
> > 
> > In terms of the generated dtb output there is no difference.  Well,
> > probably.  It would It's
> > purely syntactic sugar / internal documentation.
> 
> Right.  It is more like "make it clear to the DTS file
> reader that these fields are intended to be filled in by
> the bootloader".

Yes, that's exactly right.

> > 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.
> 
> (nit) But let's not forget that there are cases where we _do_ want
> the DTS to be complete too.

Well, that's part of why I'm contemplating this idea:  it makes it
clear to the reader whether this dts is intended to be complete, or
whether it's intended that the bootloader adjust things.

> > 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.  This syntax allows a dts to show to someone
> > reading it that a property is expected, and what its expected size is,
> > but that the value must be filled in later.  It's for the benefit of
> > people reading the dts, not programs.
> 
> Exactly.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson