RFC: Location for Device Tree Sources?

RFC: Location for Device Tree Sources?

[Jon Loeliger]

Folks,

Where should we place the sources for the OF Flat Device
Tree source files?  They used to be in U-Boot, but that
isn't happening any more.

One semi-obvious place would be to co-locate them with
their corresponding Linux arch/powerpc/platform directory.
Another would be to have a new directory full of them
under, say, arch/powerpc/devtrees or so.

Are there other suggestions or better ideas?

Thanks,
jdl

Re: RFC: Location for Device Tree Sources?

[Guennadi Liakhovetski]

On Tue, 1 Aug 2006, Jon Loeliger wrote:

> Folks,
> 
> Where should we place the sources for the OF Flat Device
> Tree source files?  They used to be in U-Boot, but that
> isn't happening any more.
> 
> One semi-obvious place would be to co-locate them with
> their corresponding Linux arch/powerpc/platform directory.
> Another would be to have a new directory full of them
> under, say, arch/powerpc/devtrees or so.
> 
> Are there other suggestions or better ideas?

Mark A. Greer in his patch to port sandpoint to arch/powerpc put 
sandpoint.dts under arch/powerpc/boot/dts/sandpoint.dts

Thanks
Guennadi
---
Guennadi Liakhovetski

Re: RFC: Location for Device Tree Sources?

[Matthew McClintock]

On Tue, 2006-08-01 at 23:00 +0200, Guennadi Liakhovetski wrote:
> 
> Mark A. Greer in his patch to port sandpoint to arch/powerpc put 
> sandpoint.dts under arch/powerpc/boot/dts/sandpoint.dts 

I believe in his latest patches he removed this part. The device trees
were not included at all and he left this point open for discussion.

-Matthew

Re: RFC: Location for Device Tree Sources?

[Mark A. Greer]

On Tue, Aug 01, 2006 at 04:01:33PM -0500, Matthew McClintock wrote:
> On Tue, 2006-08-01 at 23:00 +0200, Guennadi Liakhovetski wrote:
> > 
> > Mark A. Greer in his patch to port sandpoint to arch/powerpc put 
> > sandpoint.dts under arch/powerpc/boot/dts/sandpoint.dts 
> 
> I believe in his latest patches he removed this part. The device trees
> were not included at all and he left this point open for discussion.

That's correct.

TBH, I think its wrong to keep them in the kernel source at all--yes,
the same argument could be made for arch/powerpc/boot but that's been
settled.

We already have dtc kept externally to the kernel source.  Why not
keep a single site where all things necessary to powerpc linux are kept?
It could house dtc, the dt attach tool, and all the dt source files.

I doesn't matter to me where as long as its highly available and has
reasonable bandwidth.  jdl.com?  source.mvista.com?  penguinppc.org?
other?

Mark

Re: RFC: Location for Device Tree Sources?

[Mark A. Greer]

On Tue, Aug 01, 2006 at 05:35:04PM -0700, Mark A. Greer wrote:
> I doesn't matter to me where as long as its highly available and has
> reasonable bandwidth.  jdl.com?  source.mvista.com?  penguinppc.org?
> other?

Er, forgot the obvious: ozlabs.org?

Mark

Re: RFC: Location for Device Tree Sources?

[Josh Boyer]

On Tue, 2006-08-01 at 17:35 -0700, Mark A. Greer wrote:
> On Tue, Aug 01, 2006 at 04:01:33PM -0500, Matthew McClintock wrote:
> > On Tue, 2006-08-01 at 23:00 +0200, Guennadi Liakhovetski wrote:
> > > 
> > > Mark A. Greer in his patch to port sandpoint to arch/powerpc put 
> > > sandpoint.dts under arch/powerpc/boot/dts/sandpoint.dts 
> > 
> > I believe in his latest patches he removed this part. The device trees
> > were not included at all and he left this point open for discussion.
> 
> That's correct.
> 
> TBH, I think its wrong to keep them in the kernel source at all--yes,
> the same argument could be made for arch/powerpc/boot but that's been
> settled.

Sorry, I have to disagree.  We're talking about device tree _source_
files here.  I believe they should be included in the kernel source.
Where that is, I don't have a particularly strong argument but they
should be included.

> 
> We already have dtc kept externally to the kernel source.  Why not
> keep a single site where all things necessary to powerpc linux are kept?
> It could house dtc, the dt attach tool, and all the dt source files.

I think hosting the dtc, the dt attach tool, and pre-built dtb files for
each platform in one spot would be a good idea.

josh

Re: RFC: Location for Device Tree Sources?

[Grant Likely]

On 8/1/06, Josh Boyer <jwboyer@jdub.homelinux.org> wrote:
> On Tue, 2006-08-01 at 17:35 -0700, Mark A. Greer wrote:
> > On Tue, Aug 01, 2006 at 04:01:33PM -0500, Matthew McClintock wrote:
> > > On Tue, 2006-08-01 at 23:00 +0200, Guennadi Liakhovetski wrote:
> > > >
> > > > Mark A. Greer in his patch to port sandpoint to arch/powerpc put
> > > > sandpoint.dts under arch/powerpc/boot/dts/sandpoint.dts
> > >
> > > I believe in his latest patches he removed this part. The device trees
> > > were not included at all and he left this point open for discussion.
> >
> > That's correct.
> >
> > TBH, I think its wrong to keep them in the kernel source at all--yes,
> > the same argument could be made for arch/powerpc/boot but that's been
> > settled.
>
> Sorry, I have to disagree.  We're talking about device tree _source_
> files here.  I believe they should be included in the kernel source.
> Where that is, I don't have a particularly strong argument but they
> should be included.

I have to second that opinion.  The device tree is absolutely integral
with the rest of the code/drivers needed to support a board.  I say
there are stronger arguments for keeping the dts files in the kernel
source than there are for the boot wrapper.

powerpc/boot/dts makes a lot of sense to me.

g.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

RE: RFC: Location for Device Tree Sources?

[Li Yang-r58472]

> -----Original Message-----
> From: linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org
> [mailto:linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org] On =
Behalf
Of Mark A.
> Greer
> Sent: Wednesday, August 02, 2006 8:35 AM
> To: McClintock Matthew-R56630
> Cc: linuxppc-dev@ozlabs.org; Guennadi Liakhovetski
> Subject: Re: RFC: Location for Device Tree Sources?
>=20
> On Tue, Aug 01, 2006 at 04:01:33PM -0500, Matthew McClintock wrote:
> > On Tue, 2006-08-01 at 23:00 +0200, Guennadi Liakhovetski wrote:
> > >
> > > Mark A. Greer in his patch to port sandpoint to arch/powerpc put
> > > sandpoint.dts under arch/powerpc/boot/dts/sandpoint.dts
> >
> > I believe in his latest patches he removed this part. The device
trees
> > were not included at all and he left this point open for discussion.
>=20
> That's correct.
>=20
> TBH, I think its wrong to keep them in the kernel source at all--yes,
> the same argument could be made for arch/powerpc/boot but that's been
> settled.
>=20
> We already have dtc kept externally to the kernel source.  Why not
> keep a single site where all things necessary to powerpc linux are
kept?
> It could house dtc, the dt attach tool, and all the dt source files.

We already have gcc out of the kernel source, but we need to have all
the source code in.  :)  I strongly agree to keep dts in tree, or it
will be hard to find out what the driver really does.

>=20
> I doesn't matter to me where as long as its highly available and has
> reasonable bandwidth.  jdl.com?  source.mvista.com?  penguinppc.org?
> other?
>=20
-Leo

Re: RFC: Location for Device Tree Sources?

[Kumar Gala]

On Aug 1, 2006, at 10:20 PM, Grant Likely wrote:

> On 8/1/06, Josh Boyer <jwboyer@jdub.homelinux.org> wrote:
>> On Tue, 2006-08-01 at 17:35 -0700, Mark A. Greer wrote:
>>> On Tue, Aug 01, 2006 at 04:01:33PM -0500, Matthew McClintock wrote:
>>>> On Tue, 2006-08-01 at 23:00 +0200, Guennadi Liakhovetski wrote:
>>>>>
>>>>> Mark A. Greer in his patch to port sandpoint to arch/powerpc put
>>>>> sandpoint.dts under arch/powerpc/boot/dts/sandpoint.dts
>>>>
>>>> I believe in his latest patches he removed this part. The device  
>>>> trees
>>>> were not included at all and he left this point open for  
>>>> discussion.
>>>
>>> That's correct.
>>>
>>> TBH, I think its wrong to keep them in the kernel source at all-- 
>>> yes,
>>> the same argument could be made for arch/powerpc/boot but that's  
>>> been
>>> settled.
>>
>> Sorry, I have to disagree.  We're talking about device tree _source_
>> files here.  I believe they should be included in the kernel source.
>> Where that is, I don't have a particularly strong argument but they
>> should be included.
>
> I have to second that opinion.  The device tree is absolutely integral
> with the rest of the code/drivers needed to support a board.  I say
> there are stronger arguments for keeping the dts files in the kernel
> source than there are for the boot wrapper.
>
> powerpc/boot/dts makes a lot of sense to me.

I like this location and agree that having them in tree makes sense.   
And putting them under boot isolates them from the kernel proper.

The reason I see to having them in tree is to ensure proper version  
compatibility.  This way there is no concern about which .dts version  
will work with which kernel.  In the future we can always pull them  
out when things are more stable.

- kumar

Re: RFC: Location for Device Tree Sources?

[Tom Rini]

On Wed, Aug 02, 2006 at 08:35:55AM -0500, Kumar Gala wrote:

> I like this location and agree that having them in tree makes sense.   
> And putting them under boot isolates them from the kernel proper.
> 
> The reason I see to having them in tree is to ensure proper version  
> compatibility.  This way there is no concern about which .dts version  
> will work with which kernel.  In the future we can always pull them  
> out when things are more stable.

I'd rephrase that as an arguement to keep them out of tree:

The reason I see to having them out of tree is to ensure we follow the
intent trees holding the information about where devices live and the
kernel being good and asking the trees.  This way there is no concern
about which (otherwise valid) .dts version will work with which kernel,
as breaking a valid .dts is either a bug (unintentional API change or a
'Oops, I forgot that the tree might not specify X' which potentially
preempts the custom board Y (that's like a sandpoint!) just doesn't have
X bugs) or a change that requires a dts version bump.

I'll throw in the caveat that I'm not 100% sure we're that stable yet,
but it certainly seems like it, at least for the overall portion where
you might really have incompatible trees.  More or less complete (now
every device is described!) dts should be interchangable to the kernel
for the custom board X is just a little different from ref board Y
issues (and now, in theory, the Just Like A Sandpoint board, with a
correct dts will boot the 'sandpoint' kernel).

-- 
Tom Rini

Re: RFC: Location for Device Tree Sources?

[Matthew McClintock]

On Wed, 2006-08-02 at 09:38 -0700, Tom Rini wrote:
> I'll throw in the caveat that I'm not 100% sure we're that stable yet,
> but it certainly seems like it, at least for the overall portion where
> you might really have incompatible trees.  More or less complete (now
> every device is described!) dts should be interchangable to the kernel
> for the custom board X is just a little different from ref board Y
> issues (and now, in theory, the Just Like A Sandpoint board, with a
> correct dts will boot the 'sandpoint' kernel). 

The sandpoint (as far as I know) does not have a stable DTS. So in this
case including the DTS in the kernel would reduce confusion. The same
could be said for other boards where the DTS needed to be changed for
the IRQ rework. The old DTS will no longer boot the new kernels. I'm not
sure how much longer we will run into this problem though.

-Matthew

Re: RFC: Location for Device Tree Sources?

[Vitaly Bordug]

On Wed, 02 Aug 2006 13:09:21 -0500
Matthew McClintock wrote:

> On Wed, 2006-08-02 at 09:38 -0700, Tom Rini wrote:
> > I'll throw in the caveat that I'm not 100% sure we're that stable
> > yet, but it certainly seems like it, at least for the overall
> > portion where you might really have incompatible trees.  More or
> > less complete (now every device is described!) dts should be
> > interchangable to the kernel for the custom board X is just a
> > little different from ref board Y issues (and now, in theory, the
> > Just Like A Sandpoint board, with a correct dts will boot the
> > 'sandpoint' kernel). 
> 
> The sandpoint (as far as I know) does not have a stable DTS. So in
> this case including the DTS in the kernel would reduce confusion. The
> same could be said for other boards where the DTS needed to be
> changed for the IRQ rework. The old DTS will no longer boot the new
> kernels. I'm not sure how much longer we will run into this problem
> though.
> 
I am right about to submit dts+code working fine w/ recent IRQ stuff for 8540 and 8560,
and will make sure dts coming along.

But, I guess we finally should end up with a place in kernel tree where such a stuff should reside
further.

Re: RFC: Location for Device Tree Sources?

[Grant Likely]

On 8/2/06, Mark A. Greer <mgreer@mvista.com> wrote:
> On Tue, Aug 01, 2006 at 09:20:52PM -0600, Grant Likely wrote:
> > I have to second that opinion.  The device tree is absolutely integral
> > with the rest of the code/drivers needed to support a board.  I say
> > there are stronger arguments for keeping the dts files in the kernel
> > source than there are for the boot wrapper.
>
> Well, the dts is no good to you without dtc so do we put dtc in the
> kernel source tree too?

I don't know; should we include gcc also?

:p


-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

Re: RFC: Location for Device Tree Sources?

[Tom Rini]

On Wed, Aug 02, 2006 at 01:09:21PM -0500, Matthew McClintock wrote:
> On Wed, 2006-08-02 at 09:38 -0700, Tom Rini wrote:
> > I'll throw in the caveat that I'm not 100% sure we're that stable yet,
> > but it certainly seems like it, at least for the overall portion where
> > you might really have incompatible trees.  More or less complete (now
> > every device is described!) dts should be interchangable to the kernel
> > for the custom board X is just a little different from ref board Y
> > issues (and now, in theory, the Just Like A Sandpoint board, with a
> > correct dts will boot the 'sandpoint' kernel). 
> 
> The sandpoint (as far as I know) does not have a stable DTS. So in this
> case including the DTS in the kernel would reduce confusion. The same
> could be said for other boards where the DTS needed to be changed for
> the IRQ rework. The old DTS will no longer boot the new kernels. I'm not
> sure how much longer we will run into this problem though.

Yes, as I said, I'm not totally sure we're at the stable point right
now, but I think that we are.  I'll add that maybe we need to think
about API changes and DTS format versions.  To quote from my post..

> > X bugs) or a change that requires a dts version bump.

Now it sounds like the IRQ thing was an "Oops, we should have changed
the dts version" and bailed, noting what is wrong with the dts.

-- 
Tom Rini

Re: RFC: Location for Device Tree Sources?

[Mark A. Greer]

On Tue, Aug 01, 2006 at 08:12:29PM -0500, Josh Boyer wrote:
> On Tue, 2006-08-01 at 17:35 -0700, Mark A. Greer wrote:
> > On Tue, Aug 01, 2006 at 04:01:33PM -0500, Matthew McClintock wrote:
> > > On Tue, 2006-08-01 at 23:00 +0200, Guennadi Liakhovetski wrote:
> > > > 
> > > > Mark A. Greer in his patch to port sandpoint to arch/powerpc put 
> > > > sandpoint.dts under arch/powerpc/boot/dts/sandpoint.dts 
> > > 
> > > I believe in his latest patches he removed this part. The device trees
> > > were not included at all and he left this point open for discussion.
> > 
> > That's correct.
> > 
> > TBH, I think its wrong to keep them in the kernel source at all--yes,
> > the same argument could be made for arch/powerpc/boot but that's been
> > settled.
> 
> Sorry, I have to disagree.  We're talking about device tree _source_
> files here.  I believe they should be included in the kernel source.
> Where that is, I don't have a particularly strong argument but they
> should be included.

I would agree that its certainly _easier_ to keep them in the src tree.
The only good argument for why its _right_--that I've seen so far--is
by Kumar (i.e., so you have a dts that you know will boot on that kernel).

> > We already have dtc kept externally to the kernel source.  Why not
> > keep a single site where all things necessary to powerpc linux are kept?
> > It could house dtc, the dt attach tool, and all the dt source files.
> 
> I think hosting the dtc, the dt attach tool, and pre-built dtb files for
> each platform in one spot would be a good idea.

Well, if you're going to keep prebuilt dtb files there, why wouldn't you
want the dts that makes that dtb to be in the same place?

Mark

Re: RFC: Location for Device Tree Sources?

[Matthew McClintock]

On Wed, 2006-08-02 at 11:22 -0700, Mark A. Greer wrote:
> Well, if you're going to keep prebuilt dtb files there, why wouldn't
> you
> want the dts that makes that dtb to be in the same place?
> 

One option is the *just* include the working tested DTB files in the
kernel source. That way there is a method to boot the boards. If you end
user wants to work with a different DTB they can go download the DTS
from another source (or optionally derive the DTS from the DTB) and make
changes.

That way we do not have to include 'dtc' in the kernel, and we still
have a valid DTB for every board included in the kernel. Also, there is
no reason to include both the DTB and DTS in the kernel considering they
can be easily derived from one another using 'dtc'

-Matthew

Re: RFC: Location for Device Tree Sources?

[Jon Loeliger]

On Wed, 2006-08-02 at 13:21, Tom Rini wrote:

> Yes, as I said, I'm not totally sure we're at the stable point right
> now, but I think that we are.  I'll add that maybe we need to think
> about API changes and DTS format versions.  To quote from my post..
> 
> > > X bugs) or a change that requires a dts version bump.
> 
> Now it sounds like the IRQ thing was an "Oops, we should have changed
> the dts version" and bailed, noting what is wrong with the dts.

This confuses me.  There hasn't been a change in the DTS
format at all.  I've even updated the 8641HPCN DTS file
across the IRQ updates and all is fine.  Same (DTS) format
both before and after the IRQ changes.

What have I missed here?

And yes, I'm trying to figure out where to _put_ the
8641 DTS file now too... :-)

jdl

Re: RFC: Location for Device Tree Sources?

[Mark A. Greer]

On Tue, Aug 01, 2006 at 09:20:52PM -0600, Grant Likely wrote:
> On 8/1/06, Josh Boyer <jwboyer@jdub.homelinux.org> wrote:
> >On Tue, 2006-08-01 at 17:35 -0700, Mark A. Greer wrote:
> >> On Tue, Aug 01, 2006 at 04:01:33PM -0500, Matthew McClintock wrote:
> >> > On Tue, 2006-08-01 at 23:00 +0200, Guennadi Liakhovetski wrote:
> >> > >
> >> > > Mark A. Greer in his patch to port sandpoint to arch/powerpc put
> >> > > sandpoint.dts under arch/powerpc/boot/dts/sandpoint.dts
> >> >
> >> > I believe in his latest patches he removed this part. The device trees
> >> > were not included at all and he left this point open for discussion.
> >>
> >> That's correct.
> >>
> >> TBH, I think its wrong to keep them in the kernel source at all--yes,
> >> the same argument could be made for arch/powerpc/boot but that's been
> >> settled.
> >
> >Sorry, I have to disagree.  We're talking about device tree _source_
> >files here.  I believe they should be included in the kernel source.
> >Where that is, I don't have a particularly strong argument but they
> >should be included.
> 
> I have to second that opinion.  The device tree is absolutely integral
> with the rest of the code/drivers needed to support a board.  I say
> there are stronger arguments for keeping the dts files in the kernel
> source than there are for the boot wrapper.

Well, the dts is no good to you without dtc so do we put dtc in the
kernel source tree too?

> powerpc/boot/dts makes a lot of sense to me.

If it goes in the kernel src, I think that's the place as well.

Mark

Re: RFC: Location for Device Tree Sources?

[Mark A. Greer]

On Wed, Aug 02, 2006 at 08:35:55AM -0500, Kumar Gala wrote:
> 
> On Aug 1, 2006, at 10:20 PM, Grant Likely wrote:
> 
> > On 8/1/06, Josh Boyer <jwboyer@jdub.homelinux.org> wrote:
> >> On Tue, 2006-08-01 at 17:35 -0700, Mark A. Greer wrote:
> >>> On Tue, Aug 01, 2006 at 04:01:33PM -0500, Matthew McClintock wrote:
> >>>> On Tue, 2006-08-01 at 23:00 +0200, Guennadi Liakhovetski wrote:
> >>>>>
> >>>>> Mark A. Greer in his patch to port sandpoint to arch/powerpc put
> >>>>> sandpoint.dts under arch/powerpc/boot/dts/sandpoint.dts
> >>>>
> >>>> I believe in his latest patches he removed this part. The device  
> >>>> trees
> >>>> were not included at all and he left this point open for  
> >>>> discussion.
> >>>
> >>> That's correct.
> >>>
> >>> TBH, I think its wrong to keep them in the kernel source at all-- 
> >>> yes,
> >>> the same argument could be made for arch/powerpc/boot but that's  
> >>> been
> >>> settled.
> >>
> >> Sorry, I have to disagree.  We're talking about device tree _source_
> >> files here.  I believe they should be included in the kernel source.
> >> Where that is, I don't have a particularly strong argument but they
> >> should be included.
> >
> > I have to second that opinion.  The device tree is absolutely integral
> > with the rest of the code/drivers needed to support a board.  I say
> > there are stronger arguments for keeping the dts files in the kernel
> > source than there are for the boot wrapper.
> >
> > powerpc/boot/dts makes a lot of sense to me.
> 
> I like this location and agree that having them in tree makes sense.   
> And putting them under boot isolates them from the kernel proper.
> 
> The reason I see to having them in tree is to ensure proper version  
> compatibility.  This way there is no concern about which .dts version  
> will work with which kernel.  In the future we can always pull them  
> out when things are more stable.

Hmm, that is a good reason...

Mark

Re: RFC: Location for Device Tree Sources?

[Jon Loeliger]

On Wed, 2006-08-02 at 13:22, Mark A. Greer wrote:

> 
> Well, if you're going to keep prebuilt dtb files there, why wouldn't you
> want the dts that makes that dtb to be in the same place?

I don't think we should keep pre-compiled DTB files
around anywhere.  We don't keep a bunch of derived .o
files around, do we?

jdl

Re: RFC: Location for Device Tree Sources?

[Mark A. Greer]

On Wed, Aug 02, 2006 at 01:25:16PM -0500, Jon Loeliger wrote:
> On Wed, 2006-08-02 at 13:22, Mark A. Greer wrote:
> 
> > 
> > Well, if you're going to keep prebuilt dtb files there, why wouldn't you
> > want the dts that makes that dtb to be in the same place?
> 
> I don't think we should keep pre-compiled DTB files
> around anywhere.  We don't keep a bunch of derived .o
> files around, do we?

I agree.

Mark

Re: RFC: Location for Device Tree Sources?

[Brent Cook]

On Wednesday 02 August 2006 13:22, Mark A. Greer wrote:
>
> Well, if you're going to keep prebuilt dtb files there, why wouldn't you
> want the dts that makes that dtb to be in the same place?
>
> Mark

There is precedence for this. Look at drivers/net/ixp2000/, it includes both 
the microengine source code, and the precompiled binary blob files (in case 
you do not have the required assembler.)

 - Brent

Re: RFC: Location for Device Tree Sources?

[Mark A. Greer]

On Wed, Aug 02, 2006 at 01:22:55PM -0500, Matthew McClintock wrote:
> On Wed, 2006-08-02 at 11:22 -0700, Mark A. Greer wrote:
> > Well, if you're going to keep prebuilt dtb files there, why wouldn't
> > you
> > want the dts that makes that dtb to be in the same place?
> > 
> 
> One option is the *just* include the working tested DTB files in the
> kernel source. That way there is a method to boot the boards. If you end
> user wants to work with a different DTB they can go download the DTS
> from another source (or optionally derive the DTS from the DTB) and make
> changes.

It probably would be handier to have the dtb there but its a source
tree, so let's keep source there.

It'll just be a fact of life for a non-devtree fw platform user that
they need to find and use dtc and an attach tool to stick the dtb
onto the zImage.

> That way we do not have to include 'dtc' in the kernel, and we still

I don't think anyone was actually serious about including dtc in the kernel.

> have a valid DTB for every board included in the kernel. Also, there is
> no reason to include both the DTB and DTS in the kernel considering they
> can be easily derived from one another using 'dtc'

Mark

Re: RFC: Location for Device Tree Sources?

[Mark A. Greer]

On Wed, Aug 02, 2006 at 12:21:37PM -0600, Grant Likely wrote:
> On 8/2/06, Mark A. Greer <mgreer@mvista.com> wrote:
> >On Tue, Aug 01, 2006 at 09:20:52PM -0600, Grant Likely wrote:
> >> I have to second that opinion.  The device tree is absolutely integral
> >> with the rest of the code/drivers needed to support a board.  I say
> >> there are stronger arguments for keeping the dts files in the kernel
> >> source than there are for the boot wrapper.
> >
> >Well, the dts is no good to you without dtc so do we put dtc in the
> >kernel source tree too?
> 
> I don't know; should we include gcc also?
> 
> :p

Yep, my point.

I don't really have a problem with keeping known working dts files in
arch/powerpc/boot/dts.  Perhaps a 1-1 match with files in
arch/powerpc/configs?

It would still be nice to have the dtc source, attach tool source, and,
if useful, a more exhaustive collection of dts files in one place.

benh?  paulus?

Mark

Re: RFC: Location for Device Tree Sources?

[Mark A. Greer]

On Wed, Aug 02, 2006 at 01:41:51PM -0500, Brent Cook wrote:
> On Wednesday 02 August 2006 13:22, Mark A. Greer wrote:
> >
> > Well, if you're going to keep prebuilt dtb files there, why wouldn't you
> > want the dts that makes that dtb to be in the same place?
> >
> > Mark
> 
> There is precedence for this. Look at drivers/net/ixp2000/, it includes both 
> the microengine source code, and the precompiled binary blob files (in case 
> you do not have the required assembler.)

Interesting, but in our case everyone does have the compiler
(or at least with little effort they do).

Mark

Re: RFC: Location for Device Tree Sources?

[Tom Rini]

On Wed, Aug 02, 2006 at 01:23:08PM -0500, Jon Loeliger wrote:
> On Wed, 2006-08-02 at 13:21, Tom Rini wrote:
> 
> > Yes, as I said, I'm not totally sure we're at the stable point right
> > now, but I think that we are.  I'll add that maybe we need to think
> > about API changes and DTS format versions.  To quote from my post..
> > 
> > > > X bugs) or a change that requires a dts version bump.
> > 
> > Now it sounds like the IRQ thing was an "Oops, we should have changed
> > the dts version" and bailed, noting what is wrong with the dts.
> 
> This confuses me.  There hasn't been a change in the DTS
> format at all.  I've even updated the 8641HPCN DTS file
> across the IRQ updates and all is fine.  Same (DTS) format
> both before and after the IRQ changes.
> 
> What have I missed here?

Matthew said:
> The sandpoint (as far as I know) does not have a stable DTS. So in this
> case including the DTS in the kernel would reduce confusion. The same
> could be said for other boards where the DTS needed to be changed for
> the IRQ rework. The old DTS will no longer boot the new kernels. I'm not
> sure how much longer we will run into this problem though.

Now, if we've had to change the contents of the DTS because of a kernel
change, I'd say the DTS format changed as when I say format I mean not
only layout and naming, but what the contents are supposed to contain.

And, so it's clear, I don't know if we're at the very stable format
(names/layout/content means...), but when we are at that point, what
Matthew noted should, IMHO, be a graceful (ie explained in the panic()
or something) death.

And, so it's clear, I think (and hope!) we all agree on that last part,
once we hit stability.

-- 
Tom Rini

Re: RFC: Location for Device Tree Sources?

[Josh Boyer]

On Wed, 2006-08-02 at 11:49 -0700, Mark A. Greer wrote:
> On Wed, Aug 02, 2006 at 12:21:37PM -0600, Grant Likely wrote:
> > On 8/2/06, Mark A. Greer <mgreer@mvista.com> wrote:
> > >On Tue, Aug 01, 2006 at 09:20:52PM -0600, Grant Likely wrote:
> > >> I have to second that opinion.  The device tree is absolutely integral
> > >> with the rest of the code/drivers needed to support a board.  I say
> > >> there are stronger arguments for keeping the dts files in the kernel
> > >> source than there are for the boot wrapper.
> > >
> > >Well, the dts is no good to you without dtc so do we put dtc in the
> > >kernel source tree too?
> > 
> > I don't know; should we include gcc also?
> > 
> > :p
> 
> Yep, my point.
> 
> I don't really have a problem with keeping known working dts files in
> arch/powerpc/boot/dts.  Perhaps a 1-1 match with files in
> arch/powerpc/configs?

I like that idea very much.  Actually that's what I thought were were
talking about in the first place.

> 
> It would still be nice to have the dtc source, attach tool source, and,
> if useful, a more exhaustive collection of dts files in one place.

I also think that would be useful.

josh

Re: RFC: Location for Device Tree Sources?

[Kumar Gala]

On Aug 2, 2006, at 2:03 PM, Josh Boyer wrote:

> On Wed, 2006-08-02 at 11:49 -0700, Mark A. Greer wrote:
>> On Wed, Aug 02, 2006 at 12:21:37PM -0600, Grant Likely wrote:
>>> On 8/2/06, Mark A. Greer <mgreer@mvista.com> wrote:
>>>> On Tue, Aug 01, 2006 at 09:20:52PM -0600, Grant Likely wrote:
>>>>> I have to second that opinion.  The device tree is absolutely  
>>>>> integral
>>>>> with the rest of the code/drivers needed to support a board.  I  
>>>>> say
>>>>> there are stronger arguments for keeping the dts files in the  
>>>>> kernel
>>>>> source than there are for the boot wrapper.
>>>>
>>>> Well, the dts is no good to you without dtc so do we put dtc in the
>>>> kernel source tree too?
>>>
>>> I don't know; should we include gcc also?
>>>
>>> :p
>>
>> Yep, my point.
>>
>> I don't really have a problem with keeping known working dts files in
>> arch/powerpc/boot/dts.  Perhaps a 1-1 match with files in
>> arch/powerpc/configs?
>
> I like that idea very much.  Actually that's what I thought were were
> talking about in the first place.
>
>>
>> It would still be nice to have the dtc source, attach tool source,  
>> and,
>> if useful, a more exhaustive collection of dts files in one place.
>
> I also think that would be useful.

While useful, I doubt its likely to happen.  I forsee boards that  
aren't in the kernel tree having their dts live in their private  
worlds.  Also tools like mkimage that come from u-boot will probably  
still live with u-boot.

- kumar

Re: RFC: Location for Device Tree Sources?

[Kumar Gala]

On Aug 2, 2006, at 1:57 PM, Tom Rini wrote:

> On Wed, Aug 02, 2006 at 01:23:08PM -0500, Jon Loeliger wrote:
>> On Wed, 2006-08-02 at 13:21, Tom Rini wrote:
>>
>>> Yes, as I said, I'm not totally sure we're at the stable point right
>>> now, but I think that we are.  I'll add that maybe we need to think
>>> about API changes and DTS format versions.  To quote from my post..
>>>
>>>>> X bugs) or a change that requires a dts version bump.
>>>
>>> Now it sounds like the IRQ thing was an "Oops, we should have  
>>> changed
>>> the dts version" and bailed, noting what is wrong with the dts.
>>
>> This confuses me.  There hasn't been a change in the DTS
>> format at all.  I've even updated the 8641HPCN DTS file
>> across the IRQ updates and all is fine.  Same (DTS) format
>> both before and after the IRQ changes.
>>
>> What have I missed here?
>
> Matthew said:
>> The sandpoint (as far as I know) does not have a stable DTS. So in  
>> this
>> case including the DTS in the kernel would reduce confusion. The same
>> could be said for other boards where the DTS needed to be changed for
>> the IRQ rework. The old DTS will no longer boot the new kernels.  
>> I'm not
>> sure how much longer we will run into this problem though.
>
> Now, if we've had to change the contents of the DTS because of a  
> kernel
> change, I'd say the DTS format changed as when I say format I mean not
> only layout and naming, but what the contents are supposed to contain.
>
> And, so it's clear, I don't know if we're at the very stable format
> (names/layout/content means...), but when we are at that point, what
> Matthew noted should, IMHO, be a graceful (ie explained in the panic()
> or something) death.
>
> And, so it's clear, I think (and hope!) we all agree on that last  
> part,
> once we hit stability.

Agree about the comments related to the stability of the API, I just  
dont think we are there yet.  We should revisit the issue when we  
removed arch/ppc, until that point I would say things are up in the air.

For example, we still haven't closed on CPM descriptions and I'm sure  
we will go through several iterations before we get it right.  For  
more standard things like uart's, ethernet, pci we have the OF specs  
to model off of and are probably pretty stable.

Additionally, Ben and I have talked about making macro's in the dts's  
so we can build up a board or SOC description from standard building  
blocks so people dont get the simple things wrong.

- kumar

Re: RFC: Location for Device Tree Sources?

[Tom Rini]

On Wed, Aug 02, 2006 at 11:51:53AM -0700, Mark A. Greer wrote:
> On Wed, Aug 02, 2006 at 01:41:51PM -0500, Brent Cook wrote:
> > On Wednesday 02 August 2006 13:22, Mark A. Greer wrote:
> > >
> > > Well, if you're going to keep prebuilt dtb files there, why wouldn't you
> > > want the dts that makes that dtb to be in the same place?
> > >
> > > Mark
> > 
> > There is precedence for this. Look at drivers/net/ixp2000/, it includes both 
> > the microengine source code, and the precompiled binary blob files (in case 
> > you do not have the required assembler.)
> 
> Interesting, but in our case everyone does have the compiler
> (or at least with little effort they do).

There are a few other cases of this, with the intention that if you're
mucking with these files you can regenerate.  But we're just talking
about the blob in this part of the thread..

-- 
Tom Rini

Re: RFC: Location for Device Tree Sources?

[Milton Miller]

On Wed Aug  2 2006 01:57:28 PM CDT, Tom Rini wrote:
> On Wed, Aug 02, 2006 at 01:23:08PM -0500, Jon Loeliger wrote:
> > On Wed, 2006-08-02 at 13:21, Tom Rini wrote:
> > 
> > > Yes, as I said, I'm not totally sure we're at the stable point right
> > > now, but I think that we are.  I'll add that maybe we need to think
> > > about API changes and DTS format versions.  To quote from my post..
> > > 
> > > > > X bugs) or a change that requires a dts version bump.
> > 
> > Now it sounds like the IRQ thing was an "Oops, we should have changed
> > the dts version" and bailed, noting what is wrong with the dts.
> > 
> > This confuses me.  
...
> > Same (DTS) format
> > both before and after the IRQ changes.
> > 
> > What have I missed here?
> 
> Matthew said:
> > The sandpoint (as far as I know) does not have a stable DTS. So in this
> > case including the DTS in the kernel would reduce confusion. The same
> > could be said for other boards where the DTS needed to be changed for
> > the IRQ rework. The old DTS will no longer boot the new kernels. I'm not
> > sure how much longer we will run into this problem though.
> 
> Now, if we've had to change the contents of the DTS because of a kernel
> change, I'd say the DTS format changed as when I say format I mean not
> only layout and naming, but what the contents are supposed to contain.
> 
> And, so it's clear, I don't know if we're at the very stable format
> (names/layout/content means...), but when we are at that point, what
> Matthew noted should, IMHO, be a graceful (ie explained in the panic()
> or something) death.
> 
> And, so it's clear, I think (and hope!) we all agree on that last part,
> once we hit stability.

I don't think we need to bump the dt version every time we make a tree
content requirements change.  We need to bump when we add or
change fields in the struct header, change internal layout, or change how
we pass  information through the tree.  Certianly not because someone 
left things out of their tree.

If we bump every time we check some new property, then the tools will 
always be producing the wrong version and/or we will end up with trees 
that claim they are good for some broad range that is really  incompatable.

That being said, I haven't looked at what is now required.  If we were to
eexpect some shim or preeparsing code to fixup existing trees then that
might warrant a version number beng assigned, if such information is not
readily determined by scanning the tree.

milton

Re: RFC: Location for Device Tree Sources?

[Tom Rini]

On Thu, Aug 03, 2006 at 04:32:33AM -0500, Milton Miller wrote:

> I don't think we need to bump the dt version every time we make a tree
> content requirements change.  We need to bump when we add or
> change fields in the struct header, change internal layout, or change how
> we pass  information through the tree.  Certianly not because someone 
> left things out of their tree.

But "content requirements change" isn't the same as "left things out of
their tree".  It sounds, and I haven't seen the changes, so I'm not
certain that the meaning behind a field changed.  Something like that
should change the dt version.  New fields aren't a problem.  Changing
existing fields meaning in incompatible ways is a problem.

-- 
Tom Rini

Re: RFC: Location for Device Tree Sources?

[Li Yang]

On 8/3/06, Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Aug 2, 2006, at 1:57 PM, Tom Rini wrote:
>
> > On Wed, Aug 02, 2006 at 01:23:08PM -0500, Jon Loeliger wrote:
> >> On Wed, 2006-08-02 at 13:21, Tom Rini wrote:
> >>
> >>> Yes, as I said, I'm not totally sure we're at the stable point right
> >>> now, but I think that we are.  I'll add that maybe we need to think
> >>> about API changes and DTS format versions.  To quote from my post..
> >>>
> >>>>> X bugs) or a change that requires a dts version bump.
> >>>
> >>> Now it sounds like the IRQ thing was an "Oops, we should have
> >>> changed
> >>> the dts version" and bailed, noting what is wrong with the dts.
> >>
> >> This confuses me.  There hasn't been a change in the DTS
> >> format at all.  I've even updated the 8641HPCN DTS file
> >> across the IRQ updates and all is fine.  Same (DTS) format
> >> both before and after the IRQ changes.
> >>
> >> What have I missed here?
> >
> > Matthew said:
> >> The sandpoint (as far as I know) does not have a stable DTS. So in
> >> this
> >> case including the DTS in the kernel would reduce confusion. The same
> >> could be said for other boards where the DTS needed to be changed for
> >> the IRQ rework. The old DTS will no longer boot the new kernels.
> >> I'm not
> >> sure how much longer we will run into this problem though.
> >
> > Now, if we've had to change the contents of the DTS because of a
> > kernel
> > change, I'd say the DTS format changed as when I say format I mean not
> > only layout and naming, but what the contents are supposed to contain.
> >
> > And, so it's clear, I don't know if we're at the very stable format
> > (names/layout/content means...), but when we are at that point, what
> > Matthew noted should, IMHO, be a graceful (ie explained in the panic()
> > or something) death.
> >
> > And, so it's clear, I think (and hope!) we all agree on that last
> > part,
> > once we hit stability.
>
> Agree about the comments related to the stability of the API, I just
> dont think we are there yet.  We should revisit the issue when we
> removed arch/ppc, until that point I would say things are up in the air.
>
> For example, we still haven't closed on CPM descriptions and I'm sure
> we will go through several iterations before we get it right.  For
> more standard things like uart's, ethernet, pci we have the OF specs
> to model off of and are probably pretty stable.

I agree.  We are adding more and more device types under device tree
management.  There will be a process of evolution.
>
> Additionally, Ben and I have talked about making macro's in the dts's
> so we can build up a board or SOC description from standard building
> blocks so people dont get the simple things wrong.

What are the macros about? Like constant we used in source code?
>
> - kumar
- Leo

Re: RFC: Location for Device Tree Sources?

[Li Yang]

On 8/3/06, Tom Rini <trini@kernel.crashing.org> wrote:
> On Wed, Aug 02, 2006 at 08:35:55AM -0500, Kumar Gala wrote:
>
> > I like this location and agree that having them in tree makes sense.
> > And putting them under boot isolates them from the kernel proper.
> >
> > The reason I see to having them in tree is to ensure proper version
> > compatibility.  This way there is no concern about which .dts version
> > will work with which kernel.  In the future we can always pull them
> > out when things are more stable.
>
> I'd rephrase that as an arguement to keep them out of tree:
>
> The reason I see to having them out of tree is to ensure we follow the
> intent trees holding the information about where devices live and the
> kernel being good and asking the trees.  This way there is no concern
> about which (otherwise valid) .dts version will work with which kernel,
> as breaking a valid .dts is either a bug (unintentional API change or a
> 'Oops, I forgot that the tree might not specify X' which potentially
> preempts the custom board Y (that's like a sandpoint!) just doesn't have
> X bugs) or a change that requires a dts version bump.
>
> I'll throw in the caveat that I'm not 100% sure we're that stable yet,
> but it certainly seems like it, at least for the overall portion where
> you might really have incompatible trees.  More or less complete (now
> every device is described!) dts should be interchangable to the kernel
> for the custom board X is just a little different from ref board Y
> issues (and now, in theory, the Just Like A Sandpoint board, with a
> correct dts will boot the 'sandpoint' kernel).

I don't know why we are talking about versions here.  My argument to
including dts in tree is very simple.  dts is in many ways similiar to
kernel config file.  If we justified to put default kernel config
files in tree.  There will be no difference to make dts in tree too.
Moreover, dts can't be generated or modified easily like kernel
config.  It's even more important to make a working example handier to
get for user.

Re: RFC: Location for Device Tree Sources?

[Milton Miller]

On Aug 3, 2006, at 8:54 AM, Tom Rini wrote:
> On Thu, Aug 03, 2006 at 04:32:33AM -0500, Milton Miller wrote:
>> I don't think we need to bump the dt version every time we make a tree
>> content requirements change.  We need to bump when we add or
>> change fields in the struct header, change internal layout, or change 
>> how
>> we pass  information through the tree.  Certianly not because someone
>> left things out of their tree.
>
> But "content requirements change" isn't the same as "left things out of
> their tree".  It sounds, and I haven't seen the changes, so I'm not
> certain that the meaning behind a field changed.  Something like that
> should change the dt version.  New fields aren't a problem.  Changing
> existing fields meaning in incompatible ways is a problem.
>

Agreed.   I too haven't looked at the change, but thought it was the
former.

Re: RFC: Location for Device Tree Sources?

[Paul Mackerras]

Tom Rini writes:

> But "content requirements change" isn't the same as "left things out of
> their tree".  It sounds, and I haven't seen the changes, so I'm not
> certain that the meaning behind a field changed.  Something like that
> should change the dt version.

I disagree.  Strongly.  The dt version relates to the representation
of the tree, not its content.

If we *have* to change the meaning of a property value in a particular
node in an incompatible way, then we can do something such as adding
another property to indicate what the interpretation of the first
property value should be.  Usually it's possible to find a way around
the problem without resorting to that, though.

>  New fields aren't a problem.  Changing
> existing fields meaning in incompatible ways is a problem.

Only a minor, localized problem.  Nothing worth changing the whole dt
version number for.

Paul.

Re: RFC: Location for Device Tree Sources?

[Paul Mackerras]

Jon Loeliger writes:

> One semi-obvious place would be to co-locate them with
> their corresponding Linux arch/powerpc/platform directory.
> Another would be to have a new directory full of them
> under, say, arch/powerpc/devtrees or so.

Either of those would work.

I think we should have the dts for all of the reference boards we
support in the kernel tree.  We don't have to have every single dts in
the kernel tree, but it is useful to have at least a representative
sample there.  They're not very big and they are useful as a reference
for people who are reading drivers or platform code.

Paul.

Re: RFC: Location for Device Tree Sources?

[Tom Rini]

On Fri, Aug 04, 2006 at 02:49:00PM +1000, Paul Mackerras wrote:
> Tom Rini writes:
> 
> > But "content requirements change" isn't the same as "left things out of
> > their tree".  It sounds, and I haven't seen the changes, so I'm not
> > certain that the meaning behind a field changed.  Something like that
> > should change the dt version.
> 
> I disagree.  Strongly.  The dt version relates to the representation
> of the tree, not its content.

But doesn't the representation include meaning?

> If we *have* to change the meaning of a property value in a particular
> node in an incompatible way, then we can do something such as adding
> another property to indicate what the interpretation of the first
> property value should be.  Usually it's possible to find a way around
> the problem without resorting to that, though.

Agreed.  Kicking myself for not being explicit enough :)

> >  New fields aren't a problem.  Changing
> > existing fields meaning in incompatible ways is a problem.
> 
> Only a minor, localized problem.  Nothing worth changing the whole dt
> version number for.

I'll rephrase what I said to what I think we all agree.  Changing
existing fields meanings in incompatible ways and not somehow allowing
that to still work (like by adding a flag so new trees are interpreted
one way, old trees are fixed-up or whatever) is a problem.

-- 
Tom Rini

Re: RFC: Location for Device Tree Sources?

[Paul Mackerras]

Tom Rini writes:

> But doesn't the representation include meaning?

No, in the sense that the device-tree representation doesn't define
what meaning or interpretation is to be given to particular node and
property names or to particular property values.

> I'll rephrase what I said to what I think we all agree.  Changing
> existing fields meanings in incompatible ways and not somehow allowing
> that to still work (like by adding a flag so new trees are interpreted
> one way, old trees are fixed-up or whatever) is a problem.

Yes it's a problem.  Not one that we want to solve by changing the dt
version number, though.

Paul.

Re: RFC: Location for Device Tree Sources?

[Benjamin Herrenschmidt]

On Tue, 2006-08-01 at 15:32 -0500, Jon Loeliger wrote:
> Folks,
> 
> Where should we place the sources for the OF Flat Device
> Tree source files?  They used to be in U-Boot, but that
> isn't happening any more.

Why ? While having device-tree's in zImages is good to handle firmwares
that can't pass them, I still think that the proper thing to do is to
have the firmware provide the DT to the kernel. Did Denk decide once for
all against having DTs passed by uboot at all ? In which case, it's
probably time to consider a fork...

> One semi-obvious place would be to co-locate them with
> their corresponding Linux arch/powerpc/platform directory.
> Another would be to have a new directory full of them
> under, say, arch/powerpc/devtrees or so.
> 
> Are there other suggestions or better ideas?
> 
> Thanks,
> jdl
> 
> 
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: RFC: Location for Device Tree Sources?

[Josh Boyer]

On Wed, 2006-08-09 at 13:18 +0200, Benjamin Herrenschmidt wrote:
> On Tue, 2006-08-01 at 15:32 -0500, Jon Loeliger wrote:
> > Folks,
> > 
> > Where should we place the sources for the OF Flat Device
> > Tree source files?  They used to be in U-Boot, but that
> > isn't happening any more.
> 
> Why ? While having device-tree's in zImages is good to handle firmwares
> that can't pass them, I still think that the proper thing to do is to
> have the firmware provide the DT to the kernel. Did Denk decide once for
> all against having DTs passed by uboot at all ? In which case, it's
> probably time to consider a fork...

We're only talking about the _source_ files.  The .dts files.  Not the
binary trees themselves.

The basic summary is that having a .dts in the kernel for every
defconfig would be good.  (I think that was the summary anyway.)

josh

Re: RFC: Location for Device Tree Sources?

[Wolfgang Denk]

In message <1155122309.4040.94.camel@localhost.localdomain> you wrote:
>
> > Where should we place the sources for the OF Flat Device
> > Tree source files?  They used to be in U-Boot, but that
> > isn't happening any more.
> 
> Why ? While having device-tree's in zImages is good to handle firmwares
> that can't pass them, I still think that the proper thing to do is to
> have the firmware provide the DT to the kernel. Did Denk decide once for
> all against having DTs passed by uboot at all ? In which case, it's
> probably time to consider a fork...

Ben, you are mixing two things here.

I have nothing against U-Boot  passing  the  DT  to  the  kernel.  On
contrary,  if  DT's  are  used, than I think this is how it should be
done.

It's just that I think that the DT *sources* should not  be  part  of
the  U-Boot  soutrce  tree, and that the DT should be in fact part of
the kernel images that gets booted by U-Boot.

This has been discussed before (see archives), and the agreement  (?)
was  to  use  U-Boot's multifile image format for this purpose, where
you can combine a Linux kenrel image with a DT image  into  one  file
bootable by U-Boot.

Jon's question was where the source code of the DT should be placed.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
What is mind?  No matter.  What is matter?  Never mind.
                                      -- Thomas Hewitt Key, 1799-1875

Re: RFC: Location for Device Tree Sources?

[Benjamin Herrenschmidt]

> It's just that I think that the DT *sources* should not  be  part  of
> the  U-Boot  soutrce  tree, and that the DT should be in fact part of
> the kernel images that gets booted by U-Boot.

Fair enough, I misunderstood.

> This has been discussed before (see archives), and the agreement  (?)
> was  to  use  U-Boot's multifile image format for this purpose, where
> you can combine a Linux kenrel image with a DT image  into  one  file
> bootable by U-Boot.

Well, I would still like something else. For example, I'm vendor NetFoo
selling network appliances (ADSL modems, routers, wireless APs, ...).

A certain amount of my products are based on a very similar chipset
provided by vendor NarrowCom, same core, same ethernet cell, though my
devices have subtle differences in the various varieties of those chips
used and what other chips are put around on the board.

I want my devices to have a firmware that pass a DT to the kernel. That
DT is bolted into the firmware. In fact, it could be separate flash
blocks (especially if the flash has some small blocks) from the actual
firmware code but that does not really matter.

That way, I can distribute and maintain a single kernel image update
package as part of my software update/maintainance solution.

Now you might argue that the way to work around that is to distribute a
vmlinux + DT files and have the "installer" merge them together at flash
time. I don't disagree... that works... if the kernel is in flash. It's
a bit more annoying once you start having it on a removable support
though...

It's not _the_ only solution but it's something that I think should be
considered.

Now as far as having an official repository for the .dts files of boards
supported by the kernel, I suppose indeed that the kenrel tree is an as
good location as anything else.

Cheers,
Ben.

Re: RFC: Location for Device Tree Sources?

[Mark A. Greer]

On Wed, Aug 09, 2006 at 07:56:45AM -0500, Josh Boyer wrote:
> On Wed, 2006-08-09 at 13:18 +0200, Benjamin Herrenschmidt wrote:
> > On Tue, 2006-08-01 at 15:32 -0500, Jon Loeliger wrote:
> > > Folks,
> > > 
> > > Where should we place the sources for the OF Flat Device
> > > Tree source files?  They used to be in U-Boot, but that
> > > isn't happening any more.
> > 
> > Why ? While having device-tree's in zImages is good to handle firmwares
> > that can't pass them, I still think that the proper thing to do is to
> > have the firmware provide the DT to the kernel. Did Denk decide once for
> > all against having DTs passed by uboot at all ? In which case, it's
> > probably time to consider a fork...
> 
> We're only talking about the _source_ files.  The .dts files.  Not the
> binary trees themselves.
> 
> The basic summary is that having a .dts in the kernel for every
> defconfig would be good.  (I think that was the summary anyway.)

That's my understanding too.  A 1-1 matching of default config files
and dts files kept in the kernel src trees.  Any extra dts files would
be kept whereever dtc src is stored (i.e., jdl.com).  I haven't heard
jdl agree to this, though.  :)

Mark

Re: RFC: Location for Device Tree Sources?

[Jon Loeliger]

So, like, the other day "Mark A. Greer" mumbled:
> > We're only talking about the _source_ files.  The .dts files.  Not the
> > binary trees themselves.
> > 
> > The basic summary is that having a .dts in the kernel for every
> > defconfig would be good.  (I think that was the summary anyway.)
> 
> That's my understanding too.  A 1-1 matching of default config files
> and dts files kept in the kernel src trees.

And the keen observer who watches Paul's tree will have
noticed that the first DTS file, mpc8641_hpcn.dts, has already
been added to arch/powerpc/boot/dts!

> Any extra dts files 

... of which there are none...

> ...would be kept whereever dtc src is stored (i.e., jdl.com).
>  I haven't heard jdl agree to this, though.  :)

Sure.  No problem by me.

Though I do have a question WRT the notion of the libdt...

So, if I understand this proposal correctly, making libdt.a
would mean that we will now have to link the kernel against
this new, external dependency library.  It would also mean
that we'd have to link U-Boot against this new, external
library as well.

Did I misunderstand or is everyone hip, jiggie and down with that?

jdl

Re: RFC: Location for Device Tree Sources?

[Mark A. Greer]

On Wed, Aug 09, 2006 at 11:48:34AM -0500, Jon Loeliger wrote:
> So, like, the other day "Mark A. Greer" mumbled:
> > > We're only talking about the _source_ files.  The .dts files.  Not the
> > > binary trees themselves.
> > > 
> > > The basic summary is that having a .dts in the kernel for every
> > > defconfig would be good.  (I think that was the summary anyway.)
> > 
> > That's my understanding too.  A 1-1 matching of default config files
> > and dts files kept in the kernel src trees.
> 
> And the keen observer who watches Paul's tree will have
> noticed that the first DTS file, mpc8641_hpcn.dts, has already
> been added to arch/powerpc/boot/dts!
> 
> > Any extra dts files 
> 
> ... of which there are none...

Yet...

> > ...would be kept whereever dtc src is stored (i.e., jdl.com).
> >  I haven't heard jdl agree to this, though.  :)
> 
> Sure.  No problem by me.
> 
> Though I do have a question WRT the notion of the libdt...
> 
> So, if I understand this proposal correctly, making libdt.a
> would mean that we will now have to link the kernel against
> this new, external dependency library.  It would also mean
> that we'd have to link U-Boot against this new, external
> library as well.
> 
> Did I misunderstand or is everyone hip, jiggie and down with that?

I thought the proposal was a master copy kept by you and then the
various users would copy it over when they wanted.

>From Hollis' email
(http://ozlabs.org/pipermail/linuxppc-embedded/2006-August/023882.htm):

	"I think we should turn it into a library in the dtc source
	tree. The various projects using it could then include snapshots
	(to avoid dependencies)."

I think that means we copy.

Mark

Re: RFC: Location for Device Tree Sources?

[Andy Fleming]

On Aug 9, 2006, at 11:05, Benjamin Herrenschmidt wrote:

>> It's just that I think that the DT *sources* should not  be  part  of
>> the  U-Boot  soutrce  tree, and that the DT should be in fact part of
>> the kernel images that gets booted by U-Boot.
>
> Fair enough, I misunderstood.
>
>> This has been discussed before (see archives), and the agreement  (?)
>> was  to  use  U-Boot's multifile image format for this purpose, where
>> you can combine a Linux kenrel image with a DT image  into  one  file
>> bootable by U-Boot.
>
> Well, I would still like something else. For example, I'm vendor  
> NetFoo
> selling network appliances (ADSL modems, routers, wireless APs, ...).
>
> A certain amount of my products are based on a very similar chipset
> provided by vendor NarrowCom, same core, same ethernet cell, though my
> devices have subtle differences in the various varieties of those  
> chips
> used and what other chips are put around on the board.
>
> I want my devices to have a firmware that pass a DT to the kernel.  
> That
> DT is bolted into the firmware. In fact, it could be separate flash
> blocks (especially if the flash has some small blocks) from the actual
> firmware code but that does not really matter.
>
> That way, I can distribute and maintain a single kernel image update
> package as part of my software update/maintainance solution.


I think you'll find that the changes Matt McClintock made to u-boot  
make this quite possible.  The dtb is kept separate, and passed in by  
u-boot.  If those patches are acceptable, they provide what you  
want.  If they aren't acceptable, we'd be happy to make changes.  We  
just need to know, one way or another.

Andy

Re: RFC: Location for Device Tree Sources?

[Wolfgang Denk]

In message <1155139501.17187.76.camel@localhost.localdomain> you wrote:
>
> Well, I would still like something else. For example, I'm vendor NetFoo
> selling network appliances (ADSL modems, routers, wireless APs, ...).
...
> I want my devices to have a firmware that pass a DT to the kernel. That
> DT is bolted into the firmware. In fact, it could be separate flash
> blocks (especially if the flash has some small blocks) from the actual
> firmware code but that does not really matter.
> 
> That way, I can distribute and maintain a single kernel image update
> package as part of my software update/maintainance solution.

Understood. Why not? Such a szeario has been discussed  before,  too.
Of  course  a  split set of kernel and DT images has to be supported,
too. The proposed solution was  to  extend  the  "bootm"  command  to
accept a 3rd parameter, the DT address:

	bootm <kernel_addr> <ramdisk_addr> <dt_addr>

<dt_addr> is optional, and '-' can be used when no ramdisk  is  used.
Something like that ...

> It's not _the_ only solution but it's something that I think should be
> considered.

Of course.

> Now as far as having an official repository for the .dts files of boards
> supported by the kernel, I suppose indeed that the kenrel tree is an as
> good location as anything else.

Fine. Thanks.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Microsoft Multimedia:
You have nice graphics, sound and animations when the system crashes.