[PATCH 10/17] bootwrapper: Add dt_set_mac_addresses().
David Gibson
david at gibson.dropbear.id.au
Fri Mar 23 14:22:14 EST 2007
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
More information about the Linuxppc-dev
mailing list