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 at linux-mips.org [mailto:linux-mips-bounce at linux-
>> mips.org] On Behalf Of Grant Likely
>> Sent: Thursday, October 14, 2010 6:29 PM
>> To: Warner Losh
>> Cc: ddaney at caviumnetworks.com; prasun.kapoor at caviumnetworks.com; linux-
>> mips at linux-mips.org; devicetree-discuss at lists.ozlabs.org
>> Subject: Re: Device Tree questions WRT MIPS/Octeon SOCs.
>>
>> On Thu, Oct 14, 2010 at 7:13 PM, Warner Losh<imp at bsdimp.com>  wrote:
>>> In message:<AANLkTi=UM2p26JJMqv-
>> cNh8xACS_KPf_dCst5cgmh5VR at mail.gmail.com>
>>>             Grant Likely<grant.likely at 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.
>
>