linux-mips
[Top] [All Lists]

Re: Device Tree questions WRT MIPS/Octeon SOCs.

To: "David VomLehn (dvomlehn)" <dvomlehn@cisco.com>
Subject: Re: Device Tree questions WRT MIPS/Octeon SOCs.
From: David Daney <ddaney@caviumnetworks.com>
Date: Fri, 15 Oct 2010 10:42:13 -0700
Cc: Grant Likely <grant.likely@secretlab.ca>, Warner Losh <imp@bsdimp.com>, prasun.kapoor@caviumnetworks.com, linux-mips@linux-mips.org, devicetree-discuss@lists.ozlabs.org
In-reply-to: <7A9214B0DEB2074FBCA688B30B04400D01B50901@XMB-RCD-208.cisco.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <4CB79D93.6090500@caviumnetworks.com> <AANLkTi=UM2p26JJMqv-cNh8xACS_KPf_dCst5cgmh5VR@mail.gmail.com> <20101014.191309.515504596.imp@bsdimp.com> <AANLkTi=dqMHa04=-+RjnxuPGL3ZsqNCiaxUPT0VpV6kC@mail.gmail.com> <7A9214B0DEB2074FBCA688B30B04400D01B50901@XMB-RCD-208.cisco.com>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100907 Fedora/3.0.7-1.fc12 Thunderbird/3.0.7
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.




<Prev in Thread] Current Thread [Next in Thread>