Device Tree questions WRT MIPS/Octeon SOCs.

Device Tree questions WRT MIPS/Octeon SOCs.

[David Daney]

Grant,

I have been following your MIPS device tree patches and have begun to 
experiment with them.  If you could give some feedback on my ideas, I 
would appreciate it.

Background:

The Octeon is a MIPS64 based SOC family.  The various members of the 
Octeon family have several Ethernet ports of different types, one or 
more MDIO and I2C busses and other miscellaneous devices.  People put 
the SOCs on boards that have a wide variety of PHYs, I2C devices all 
connected in different ways.

Currently we have ad hoc code throughout the drivers and platform 
initialization code that specify how everything is connected.

Plan:

I want to convert this to use the device tree and related functions.

Since none of the existing hardware has an existing device tree I plan 
on taking a two pronged approach.

Modify platform drivers to get configuration information from the device 
tree.  Then:

1) Load and use a dtb blob as specified on the kernel command line.

2) If no command line dtb specified, use a default dtb embedded in the 
kernel image and then edit or patch it using of_attach_node(), 
of_detach_node(), prom_remove_property(), and prom_add_property() based 
on some of the the same ad hoc code we currently use.

Q: As a very high level plan does this make any sense?

Would you recommend something else?

Thanks in advance,
David Daney

Re: Device Tree questions WRT MIPS/Octeon SOCs.

[Grant Likely]

Hi David.

On Thu, Oct 14, 2010 at 6:17 PM, David Daney <ddaney@caviumnetworks.com> wrote:
[...]
> I want to convert this to use the device tree and related functions.
>
> Since none of the existing hardware has an existing device tree I plan on
> taking a two pronged approach.
>
> Modify platform drivers to get configuration information from the device
> tree.  Then:
>
> 1) Load and use a dtb blob as specified on the kernel command line.
>
> 2) If no command line dtb specified, use a default dtb embedded in the
> kernel image and then edit or patch it using of_attach_node(),
> of_detach_node(), prom_remove_property(), and prom_add_property() based on
> some of the the same ad hoc code we currently use.
>
> Q: As a very high level plan does this make any sense?

Overall the plan makes sense, however I would suggest the following.
instead of 'live' modifying the tree, another option is to carry a set
of 'stock' device trees in the kernel; one per board.  Of course this
assumes that your current ad-hoc code is keying on the specific board.
 If it is interpreting data provided by the firmware, then your
suggestion of modifying a single stock tree probably makes more sense,
or possibly a combination of the too.  In general you should avoid
live modification as much as possible.

g.

Re: Device Tree questions WRT MIPS/Octeon SOCs.

[Warner Losh]

In message: <AANLkTi=UM2p26JJMqv-cNh8xACS_KPf_dCst5cgmh5VR@mail.gmail.com>
            Grant Likely <grant.likely@secretlab.ca> writes:
: Overall the plan makes sense, however I would suggest the following.
: instead of 'live' modifying the tree, another option is to carry a set
: of 'stock' device trees in the kernel; one per board.  Of course this
: assumes that your current ad-hoc code is keying on the specific board.
:  If it is interpreting data provided by the firmware, then your
: suggestion of modifying a single stock tree probably makes more sense,
: or possibly a combination of the too.  In general you should avoid
: live modification as much as possible.

The one draw back on this is that there's lots of different "stock"
boards that the Cavium Octeon SDK supports.  These will be difficult
to drag along for every kernel.  And they'd be mostly the same to,
which is why I think that David is suggesting the live modification
thing...

I know that FreeBSD will have exactly the same problem as we move to
using the FDT for FreeBSD/mips' configuration.

Warner

Re: Device Tree questions WRT MIPS/Octeon SOCs.

[Grant Likely]

On Thu, Oct 14, 2010 at 7:13 PM, Warner Losh <imp@bsdimp.com> wrote:
> In message: <AANLkTi=UM2p26JJMqv-cNh8xACS_KPf_dCst5cgmh5VR@mail.gmail.com>
>            Grant Likely <grant.likely@secretlab.ca> writes:
> : Overall the plan makes sense, however I would suggest the following.
> : instead of 'live' modifying the tree, another option is to carry a set
> : of 'stock' device trees in the kernel; one per board.  Of course this
> : assumes that your current ad-hoc code is keying on the specific board.
> :  If it is interpreting data provided by the firmware, then your
> : suggestion of modifying a single stock tree probably makes more sense,
> : or possibly a combination of the too.  In general you should avoid
> : live modification as much as possible.
>
> The one draw back on this is that there's lots of different "stock"
> boards that the Cavium Octeon SDK supports.  These will be difficult
> to drag along for every kernel.  And they'd be mostly the same to,
> which is why I think that David is suggesting the live modification
> thing...

Okay.  Do what makes the most sense for your platform.

g.

RE: Device Tree questions WRT MIPS/Octeon SOCs.

[David VomLehn (dvomlehn)]

If this is really a question of needing to dynamically generate the device tree, then you have no choice. It's worth mentioning, though, that the device tree compiler (dtc) does have the ability to include files, making it easier to create and maintain device trees that are static but which share devices.

> -----Original Message-----
> From: linux-mips-bounce@linux-mips.org [mailto:linux-mips-bounce@linux-
> mips.org] On Behalf Of Grant Likely
> Sent: Thursday, October 14, 2010 6:29 PM
> To: Warner Losh
> Cc: ddaney@caviumnetworks.com; prasun.kapoor@caviumnetworks.com; linux-
> mips@linux-mips.org; devicetree-discuss@lists.ozlabs.org
> Subject: Re: Device Tree questions WRT MIPS/Octeon SOCs.
> 
> On Thu, Oct 14, 2010 at 7:13 PM, Warner Losh <imp@bsdimp.com> wrote:
> > In message: <AANLkTi=UM2p26JJMqv-
> cNh8xACS_KPf_dCst5cgmh5VR@mail.gmail.com>
> >            Grant Likely <grant.likely@secretlab.ca> writes:
> > : Overall the plan makes sense, however I would suggest the
> following.
> > : instead of 'live' modifying the tree, another option is to carry a
> set
> > : of 'stock' device trees in the kernel; one per board.  Of course
> this
> > : assumes that your current ad-hoc code is keying on the specific
> board.
> > :  If it is interpreting data provided by the firmware, then your
> > : suggestion of modifying a single stock tree probably makes more
> sense,
> > : or possibly a combination of the too.  In general you should avoid
> > : live modification as much as possible.
> >
> > The one draw back on this is that there's lots of different "stock"
> > boards that the Cavium Octeon SDK supports.  These will be difficult
> > to drag along for every kernel.  And they'd be mostly the same to,
> > which is why I think that David is suggesting the live modification
> > thing...
> 
> Okay.  Do what makes the most sense for your platform.
> 
> g.

RE: Device Tree questions WRT MIPS/Octeon SOCs.

[David VomLehn (dvomlehn)]

If this is really a question of needing to dynamically generate the device tree, then you have no choice. It's worth mentioning, though, that the device tree compiler (dtc) does have the ability to include files, making it easier to create and maintain device trees that are static but which share devices.

> -----Original Message-----
> From: linux-mips-bounce@linux-mips.org [mailto:linux-mips-bounce@linux-
> mips.org] On Behalf Of Grant Likely
> Sent: Thursday, October 14, 2010 6:29 PM
> To: Warner Losh
> Cc: ddaney@caviumnetworks.com; prasun.kapoor@caviumnetworks.com; linux-
> mips@linux-mips.org; devicetree-discuss@lists.ozlabs.org
> Subject: Re: Device Tree questions WRT MIPS/Octeon SOCs.
> 
> On Thu, Oct 14, 2010 at 7:13 PM, Warner Losh <imp@bsdimp.com> wrote:
> > In message: <AANLkTi=UM2p26JJMqv-
> cNh8xACS_KPf_dCst5cgmh5VR@mail.gmail.com>
> >            Grant Likely <grant.likely@secretlab.ca> writes:
> > : Overall the plan makes sense, however I would suggest the
> following.
> > : instead of 'live' modifying the tree, another option is to carry a
> set
> > : of 'stock' device trees in the kernel; one per board.  Of course
> this
> > : assumes that your current ad-hoc code is keying on the specific
> board.
> > :  If it is interpreting data provided by the firmware, then your
> > : suggestion of modifying a single stock tree probably makes more
> sense,
> > : or possibly a combination of the too.  In general you should avoid
> > : live modification as much as possible.
> >
> > The one draw back on this is that there's lots of different "stock"
> > boards that the Cavium Octeon SDK supports.  These will be difficult
> > to drag along for every kernel.  And they'd be mostly the same to,
> > which is why I think that David is suggesting the live modification
> > thing...
> 
> Okay.  Do what makes the most sense for your platform.
> 
> g.

Re: Device Tree questions WRT MIPS/Octeon SOCs.

[David Daney]

On 10/15/2010 10:30 AM, David VomLehn (dvomlehn) wrote:

> If this is really a question of needing to dynamically generate the
> device tree, then you have no choice. It's worth mentioning, though,
> that the device tree compiler (dtc) does have the ability to include
> files, making it easier to create and maintain device trees that are
> static but which share devices.

Some experimentation will be necessary.  We will have to patch in some
properties like the Ethernet MAC address as that is stored in a
separate eeprom.  Also some boards have pluggable I/O modules, so we
may not know at dtb generation time what is there.

David Daney


>> -----Original Message-----
>> From: linux-mips-bounce@linux-mips.org [mailto:linux-mips-bounce@linux-
>> mips.org] On Behalf Of Grant Likely
>> Sent: Thursday, October 14, 2010 6:29 PM
>> To: Warner Losh
>> Cc: ddaney@caviumnetworks.com; prasun.kapoor@caviumnetworks.com; linux-
>> mips@linux-mips.org; devicetree-discuss@lists.ozlabs.org
>> Subject: Re: Device Tree questions WRT MIPS/Octeon SOCs.
>>
>> On Thu, Oct 14, 2010 at 7:13 PM, Warner Losh<imp@bsdimp.com>  wrote:
>>> In message:<AANLkTi=UM2p26JJMqv-
>> cNh8xACS_KPf_dCst5cgmh5VR@mail.gmail.com>
>>>             Grant Likely<grant.likely@secretlab.ca>  writes:
>>> : Overall the plan makes sense, however I would suggest the
>> following.
>>> : instead of 'live' modifying the tree, another option is to carry a
>> set
>>> : of 'stock' device trees in the kernel; one per board.  Of course
>> this
>>> : assumes that your current ad-hoc code is keying on the specific
>> board.
>>> :  If it is interpreting data provided by the firmware, then your
>>> : suggestion of modifying a single stock tree probably makes more
>> sense,
>>> : or possibly a combination of the too.  In general you should avoid
>>> : live modification as much as possible.
>>>
>>> The one draw back on this is that there's lots of different "stock"
>>> boards that the Cavium Octeon SDK supports.  These will be difficult
>>> to drag along for every kernel.  And they'd be mostly the same to,
>>> which is why I think that David is suggesting the live modification
>>> thing...
>>
>> Okay.  Do what makes the most sense for your platform.
>>
>> g.
>
>

RE: Device Tree questions WRT MIPS/Octeon SOCs.

[David VomLehn (dvomlehn)]

We're in much the same situation. Almost all of the device tree is
static, but we add on/overwrite little bits. I'm not the device tree
expert, but if I understand correctly, you can even have dtc emit labels
that you can reference to make the fix-up simpler.

> -----Original Message-----
> From: David Daney [mailto:ddaney@caviumnetworks.com]
> Sent: Friday, October 15, 2010 10:42 AM
> To: David VomLehn (dvomlehn)
> Cc: Grant Likely; Warner Losh; prasun.kapoor@caviumnetworks.com;
linux-
> mips@linux-mips.org; devicetree-discuss@lists.ozlabs.org
> Subject: Re: Device Tree questions WRT MIPS/Octeon SOCs.
> 
> On 10/15/2010 10:30 AM, David VomLehn (dvomlehn) wrote:
> 
> > If this is really a question of needing to dynamically generate the
> > device tree, then you have no choice. It's worth mentioning, though,
> > that the device tree compiler (dtc) does have the ability to include
> > files, making it easier to create and maintain device trees that are
> > static but which share devices.
> 
> Some experimentation will be necessary.  We will have to patch in some
> properties like the Ethernet MAC address as that is stored in a
> separate eeprom.  Also some boards have pluggable I/O modules, so we
> may not know at dtb generation time what is there.
> 
> David Daney
> 
> 
> >> -----Original Message-----
> >> From: linux-mips-bounce@linux-mips.org [mailto:linux-mips-
> bounce@linux-
> >> mips.org] On Behalf Of Grant Likely
> >> Sent: Thursday, October 14, 2010 6:29 PM
> >> To: Warner Losh
> >> Cc: ddaney@caviumnetworks.com; prasun.kapoor@caviumnetworks.com;
> linux-
> >> mips@linux-mips.org; devicetree-discuss@lists.ozlabs.org
> >> Subject: Re: Device Tree questions WRT MIPS/Octeon SOCs.
> >>
> >> On Thu, Oct 14, 2010 at 7:13 PM, Warner Losh<imp@bsdimp.com>
wrote:
> >>> In message:<AANLkTi=UM2p26JJMqv-
> >> cNh8xACS_KPf_dCst5cgmh5VR@mail.gmail.com>
> >>>             Grant Likely<grant.likely@secretlab.ca>  writes:
> >>> : Overall the plan makes sense, however I would suggest the
> >> following.
> >>> : instead of 'live' modifying the tree, another option is to carry
> a
> >> set
> >>> : of 'stock' device trees in the kernel; one per board.  Of course
> >> this
> >>> : assumes that your current ad-hoc code is keying on the specific
> >> board.
> >>> :  If it is interpreting data provided by the firmware, then your
> >>> : suggestion of modifying a single stock tree probably makes more
> >> sense,
> >>> : or possibly a combination of the too.  In general you should
> avoid
> >>> : live modification as much as possible.
> >>>
> >>> The one draw back on this is that there's lots of different
"stock"
> >>> boards that the Cavium Octeon SDK supports.  These will be
> difficult
> >>> to drag along for every kernel.  And they'd be mostly the same to,
> >>> which is why I think that David is suggesting the live
modification
> >>> thing...
> >>
> >> Okay.  Do what makes the most sense for your platform.
> >>
> >> g.
> >
> >

RE: Device Tree questions WRT MIPS/Octeon SOCs.

[David VomLehn (dvomlehn)]

We're in much the same situation. Almost all of the device tree is
static, but we add on/overwrite little bits. I'm not the device tree
expert, but if I understand correctly, you can even have dtc emit labels
that you can reference to make the fix-up simpler.

> -----Original Message-----
> From: David Daney [mailto:ddaney@caviumnetworks.com]
> Sent: Friday, October 15, 2010 10:42 AM
> To: David VomLehn (dvomlehn)
> Cc: Grant Likely; Warner Losh; prasun.kapoor@caviumnetworks.com;
linux-
> mips@linux-mips.org; devicetree-discuss@lists.ozlabs.org
> Subject: Re: Device Tree questions WRT MIPS/Octeon SOCs.
> 
> On 10/15/2010 10:30 AM, David VomLehn (dvomlehn) wrote:
> 
> > If this is really a question of needing to dynamically generate the
> > device tree, then you have no choice. It's worth mentioning, though,
> > that the device tree compiler (dtc) does have the ability to include
> > files, making it easier to create and maintain device trees that are
> > static but which share devices.
> 
> Some experimentation will be necessary.  We will have to patch in some
> properties like the Ethernet MAC address as that is stored in a
> separate eeprom.  Also some boards have pluggable I/O modules, so we
> may not know at dtb generation time what is there.
> 
> David Daney
> 
> 
> >> -----Original Message-----
> >> From: linux-mips-bounce@linux-mips.org [mailto:linux-mips-
> bounce@linux-
> >> mips.org] On Behalf Of Grant Likely
> >> Sent: Thursday, October 14, 2010 6:29 PM
> >> To: Warner Losh
> >> Cc: ddaney@caviumnetworks.com; prasun.kapoor@caviumnetworks.com;
> linux-
> >> mips@linux-mips.org; devicetree-discuss@lists.ozlabs.org
> >> Subject: Re: Device Tree questions WRT MIPS/Octeon SOCs.
> >>
> >> On Thu, Oct 14, 2010 at 7:13 PM, Warner Losh<imp@bsdimp.com>
wrote:
> >>> In message:<AANLkTi=UM2p26JJMqv-
> >> cNh8xACS_KPf_dCst5cgmh5VR@mail.gmail.com>
> >>>             Grant Likely<grant.likely@secretlab.ca>  writes:
> >>> : Overall the plan makes sense, however I would suggest the
> >> following.
> >>> : instead of 'live' modifying the tree, another option is to carry
> a
> >> set
> >>> : of 'stock' device trees in the kernel; one per board.  Of course
> >> this
> >>> : assumes that your current ad-hoc code is keying on the specific
> >> board.
> >>> :  If it is interpreting data provided by the firmware, then your
> >>> : suggestion of modifying a single stock tree probably makes more
> >> sense,
> >>> : or possibly a combination of the too.  In general you should
> avoid
> >>> : live modification as much as possible.
> >>>
> >>> The one draw back on this is that there's lots of different
"stock"
> >>> boards that the Cavium Octeon SDK supports.  These will be
> difficult
> >>> to drag along for every kernel.  And they'd be mostly the same to,
> >>> which is why I think that David is suggesting the live
modification
> >>> thing...
> >>
> >> Okay.  Do what makes the most sense for your platform.
> >>
> >> g.
> >
> >

Re: Device Tree questions WRT MIPS/Octeon SOCs.

[Grant Likely]

[reorganized quoting]
On Fri, Oct 15, 2010 at 12:48:55PM -0500, David VomLehn (dvomlehn) wrote:
> 
> David Daney wrote:
> > On 10/15/2010 10:30 AM, David VomLehn (dvomlehn) wrote:
> > 
> > > If this is really a question of needing to dynamically generate the
> > > device tree, then you have no choice. It's worth mentioning, though,
> > > that the device tree compiler (dtc) does have the ability to include
> > > files, making it easier to create and maintain device trees that are
> > > static but which share devices.
> > 
> > Some experimentation will be necessary.  We will have to patch in some
> > properties like the Ethernet MAC address as that is stored in a
> > separate eeprom.  Also some boards have pluggable I/O modules, so we
> > may not know at dtb generation time what is there.

If it touches firmware, then you'll need to be careful about getting
painted into a corner with an over-complex boot firmware design, but
yet this sounds like an appropriate approach.

> We're in much the same situation. Almost all of the device tree is
> static, but we add on/overwrite little bits. I'm not the device tree
> expert, but if I understand correctly, you can even have dtc emit labels
> that you can reference to make the fix-up simpler.

The labels are not available at runtime, but properties in the
'aliases' node can (and should) be used to avoid having to depend on
the full path to a device node.  It has been on my to-do list for a
while to add automatic parsing of aliases when finding a node by full
path.

g.

Re: Device Tree questions WRT MIPS/Octeon SOCs.

[David Gibson]

On Fri, Oct 15, 2010 at 09:45:48PM -0600, Grant Likely wrote:
> [reorganized quoting]
> On Fri, Oct 15, 2010 at 12:48:55PM -0500, David VomLehn (dvomlehn) wrote:
> > 
> > David Daney wrote:
> > > On 10/15/2010 10:30 AM, David VomLehn (dvomlehn) wrote:
> > > 
> > > > If this is really a question of needing to dynamically generate the
> > > > device tree, then you have no choice. It's worth mentioning, though,
> > > > that the device tree compiler (dtc) does have the ability to include
> > > > files, making it easier to create and maintain device trees that are
> > > > static but which share devices.
> > > 
> > > Some experimentation will be necessary.  We will have to patch in some
> > > properties like the Ethernet MAC address as that is stored in a
> > > separate eeprom.  Also some boards have pluggable I/O modules, so we
> > > may not know at dtb generation time what is there.
> 
> If it touches firmware, then you'll need to be careful about getting
> painted into a corner with an over-complex boot firmware design, but
> yet this sounds like an appropriate approach.
> 
> > We're in much the same situation. Almost all of the device tree is
> > static, but we add on/overwrite little bits. I'm not the device tree
> > expert, but if I understand correctly, you can even have dtc emit labels
> > that you can reference to make the fix-up simpler.
> 
> The labels are not available at runtime, but properties in the
> 'aliases' node can (and should) be used to avoid having to depend on
> the full path to a device node.  It has been on my to-do list for a
> while to add automatic parsing of aliases when finding a node by full
> path.

Well.. the labels can be available at runtime, but only if you use
dtc's "asm" output mode and link the resulting asm code into your
kernel.  There are situations where this is a good approach, but I
suspect yours is not one of them.

libfdt already automatically expands aliases when locating a node by
full path.

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

Re: Device Tree questions WRT MIPS/Octeon SOCs.

[David Gibson]

On Fri, Oct 15, 2010 at 10:42:13AM -0700, David Daney wrote:
> On 10/15/2010 10:30 AM, David VomLehn (dvomlehn) wrote:
> 
> >If this is really a question of needing to dynamically generate the
> >device tree, then you have no choice. It's worth mentioning, though,
> >that the device tree compiler (dtc) does have the ability to include
> >files, making it easier to create and maintain device trees that are
> >static but which share devices.
> 
> Some experimentation will be necessary.  We will have to patch in some
> properties like the Ethernet MAC address as that is stored in a
> separate eeprom.  Also some boards have pluggable I/O modules, so we
> may not know at dtb generation time what is there.

For pluggable modules, rather than patching them in, I'd suggest
including them all and pruning out the ones that aren't present.
That's simpler in the boot up code doing the manipulation.

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

Re: Device Tree questions WRT MIPS/Octeon SOCs.

[Grant Likely]

On Fri, Oct 15, 2010 at 12:30:48PM -0500, David VomLehn (dvomlehn) wrote:
> If this is really a question of needing to dynamically generate the
> device tree, then you have no choice. It's worth mentioning, though,
> that the device tree compiler (dtc) does have the ability to include
> files, making it easier to create and maintain device trees that are
> static but which share devices.

Yes.  In fact, John Bonesio is working right now of polishing the last
details of this to allow for example a board-level .dts file to
include an SoC level .dts and add/remove/modify nodes as needed.
Should be sorted out in a week or two.  Once that is done then we'll
update the copy of dtc in the kernel (probably looking at the 2.6.38
timeframe realistically).

g.

> 
> > -----Original Message-----
> > From: linux-mips-bounce@linux-mips.org [mailto:linux-mips-bounce@linux-
> > mips.org] On Behalf Of Grant Likely
> > Sent: Thursday, October 14, 2010 6:29 PM
> > To: Warner Losh
> > Cc: ddaney@caviumnetworks.com; prasun.kapoor@caviumnetworks.com; linux-
> > mips@linux-mips.org; devicetree-discuss@lists.ozlabs.org
> > Subject: Re: Device Tree questions WRT MIPS/Octeon SOCs.
> > 
> > On Thu, Oct 14, 2010 at 7:13 PM, Warner Losh <imp@bsdimp.com> wrote:
> > > In message: <AANLkTi=UM2p26JJMqv-
> > cNh8xACS_KPf_dCst5cgmh5VR@mail.gmail.com>
> > >            Grant Likely <grant.likely@secretlab.ca> writes:
> > > : Overall the plan makes sense, however I would suggest the
> > following.
> > > : instead of 'live' modifying the tree, another option is to carry a
> > set
> > > : of 'stock' device trees in the kernel; one per board.  Of course
> > this
> > > : assumes that your current ad-hoc code is keying on the specific
> > board.
> > > :  If it is interpreting data provided by the firmware, then your
> > > : suggestion of modifying a single stock tree probably makes more
> > sense,
> > > : or possibly a combination of the too.  In general you should avoid
> > > : live modification as much as possible.
> > >
> > > The one draw back on this is that there's lots of different "stock"
> > > boards that the Cavium Octeon SDK supports.  These will be difficult
> > > to drag along for every kernel.  And they'd be mostly the same to,
> > > which is why I think that David is suggesting the live modification
> > > thing...
> > 
> > Okay.  Do what makes the most sense for your platform.
> > 
> > g.
>