Device Tree questions WRT MIPS/Octeon SOCs.
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
A message that is not in the archive (sent off-list or not yet received): 4CB79D93.6090500-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org
Hi David.
On Thu, Oct 14, 2010 at 6:17 PM, David Daney <[email protected]> wrote:
[...]
Quoted 8 lines
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:
Quoted 8 lines
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(), andprom_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.
A message that is not in the archive (sent off-list or not yet received): AANLkTi=UM2p26JJMqv-cNh8xACS_KPf_dCst5cgmh5VR-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
In message: <AANLkTi=UM2p26JJMqv-cNh8xACS_KPf_dCst5cgmh5VR-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Grant Likely <grant.likely-s3s/[email protected]> 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
A message that is not in the archive (sent off-list or not yet received): 20101014.191309.515504596.imp-uzTCJ5RojNnQT0dZR+AlfA@public.gmane.org
Quoted 11 lines · Warner Losh
In message: <AANLkTi=UM2p26JJMqv-cNh8xACS_KPf_dCst5cgmh5VR-JsoAwUIsXounXO2b/[email protected]> Grant Likely <grant.likely-s3s/[email protected]> 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.
Quoted 5 lines
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.
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.
Quoted 36 lines
-----Original Message-----
From: [email protected] [mailto:linux-mips-bounce@linux- mips.org] On Behalf Of Grant Likely
Sent: Thursday, October 14, 2010 6:29 PM
To: Warner Losh
Cc: [email protected]; [email protected]; linux- [email protected]; [email protected]
Subject: Re: Device Tree questions WRT MIPS/Octeon SOCs.Quoted 1 line · Warner Losh
In message: <AANLkTi=UM2p26JJMqv-
Quoted 2 lines
Grant Likely <[email protected]> writes:
: Overall the plan makes sense, however I would suggest thefollowing.
Quoted 1 line
: instead of 'live' modifying the tree, another option is to carry a
set
Quoted 1 line
: of 'stock' device trees in the kernel; one per board. Of course
this
Quoted 1 line
: assumes that your current ad-hoc code is keying on the specific
board.
Quoted 2 lines
: If it is interpreting data provided by the firmware, then your : suggestion of modifying a single stock tree probably makes more
sense,
Quoted 8 lines
: 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.
A message that is not in the archive (sent off-list or not yet received): 7A9214B0DEB2074FBCA688B30B04400D01B50901-2KNrN6/[email protected]
Quoted 5 lines · 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.
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
Quoted 38 lines
Quoted 36 lines
-----Original Message-----
From: linux-mips-bounce-6z/[email protected] [mailto:linux-mips-bounce@linux-
mips.org] On Behalf Of Grant Likely
Sent: Thursday, October 14, 2010 6:29 PM
To: Warner Losh
Cc: [email protected]; [email protected]; linux- mips-6z/[email protected]; devicetree-discuss-uLR06cmDAlY/[email protected]
Subject: Re: Device Tree questions WRT MIPS/Octeon SOCs.Quoted 1 line · Warner Losh
In message:<AANLkTi=UM2p26JJMqv-
cNh8xACS_KPf_dCst5cgmh5VR-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Quoted 2 lines
Grant Likely<grant.likely-s3s/[email protected]> writes:
: Overall the plan makes sense, however I would suggest thefollowing.
Quoted 1 line
: instead of 'live' modifying the tree, another option is to carry a
set
Quoted 1 line
: of 'stock' device trees in the kernel; one per board. Of course
this
Quoted 1 line
: assumes that your current ad-hoc code is keying on the specific
board.
Quoted 2 lines
: If it is interpreting data provided by the firmware, then your : suggestion of modifying a single stock tree probably makes more
sense,
Quoted 8 lines
: 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.
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.
Quoted 5 lines
-----Original Message-----
From: David Daney [mailto:[email protected]]
Sent: Friday, October 15, 2010 10:42 AM
To: David VomLehn (dvomlehn)
Cc: Grant Likely; Warner Losh; [email protected];
linux-
Quoted 31 lines
[email protected]; [email protected]
Subject: Re: Device Tree questions WRT MIPS/Octeon SOCs.Quoted 5 lines · 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.
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
Quoted 2 lines
Quoted 2 lines
-----Original Message-----
From: [email protected] [mailto:linux-mips-bounce@linux-
Quoted 4 lines
Quoted 4 lines
mips.org] On Behalf Of Grant Likely
Sent: Thursday, October 14, 2010 6:29 PM
To: Warner Losh
Cc: [email protected]; [email protected];linux-
Quoted 4 lines
Quoted 4 lines
[email protected]; [email protected]
Subject: Re: Device Tree questions WRT MIPS/Octeon SOCs.On Thu, Oct 14, 2010 at 7:13 PM, Warner Losh<[email protected]>
Quoted 9 lines · wrote:
Quoted 6 lines
Quoted 6 lines
Quoted 1 line
In message:<AANLkTi=UM2p26JJMqv-
Quoted 2 lines
Grant Likely<[email protected]> writes:
: Overall the plan makes sense, however I would suggest thefollowing.
Quoted 1 line
: instead of 'live' modifying the tree, another option is to carry
a
Quoted 2 lines
Quoted 2 lines
set
Quoted 1 line
: of 'stock' device trees in the kernel; one per board. Of course
Quoted 11 lines
Quoted 7 lines
Quoted 7 lines
this
Quoted 1 line
: assumes that your current ad-hoc code is keying on the specific
board.
Quoted 2 lines
: If it is interpreting data provided by the firmware, then your : suggestion of modifying a single stock tree probably makes more
sense,
Quoted 1 line
: or possibly a combination of the too. In general you should
avoid
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
: live modification as much as possible.
The one draw back on this is that there's lots of different
"stock"
Quoted 4 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
boards that the Cavium Octeon SDK supports. These will be
difficult
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
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
Quoted 7 lines
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
thing...
Okay. Do what makes the most sense for your platform.
g.
A message that is not in the archive (sent off-list or not yet received): 7A9214B0DEB2074FBCA688B30B04400D01B50924-2KNrN6/[email protected]
[reorganized quoting]
Quoted 10 lines · David VomLehn (dvomlehn)
Quoted 8 lines · David Daney
Quoted 5 lines · 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.
Quoted 4 lines
Quoted 4 lines
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.
Quoted 4 lines
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.
A message that is not in the archive (sent off-list or not yet received): 20101016034548.GB21170-MrY2KI0G/OVr83L8+7iqerDks+cytr/[email protected]
Quoted 26 lines · Grant Likely
[reorganized quoting]
Quoted 10 lines · David VomLehn (dvomlehn)
Quoted 8 lines · David Daney
Quoted 5 lines · 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.
Quoted 4 lines
Quoted 4 lines
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.
Quoted 4 lines
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.
Quoted 5 lines
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.
Signature · 4 lines
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
A message that is not in the archive (sent off-list or not yet received): 4CB89275.8020502-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org
Quoted 8 lines · David Daney
Quoted 5 lines · 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.
Quoted 4 lines
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.
Signature · 4 lines
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
Quoted 5 lines · 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.
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.
Quoted 38 lines
Quoted 37 lines
-----Original Message-----
From: linux-mips-bounce-6z/[email protected] [mailto:linux-mips-bounce@linux-
mips.org] On Behalf Of Grant Likely
Sent: Thursday, October 14, 2010 6:29 PM
To: Warner Losh
Cc: [email protected]; [email protected]; linux- mips-6z/[email protected]; devicetree-discuss-uLR06cmDAlY/[email protected]
Subject: Re: Device Tree questions WRT MIPS/Octeon SOCs.Quoted 1 line · Warner Losh
In message: <AANLkTi=UM2p26JJMqv-
cNh8xACS_KPf_dCst5cgmh5VR-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Quoted 2 lines
Grant Likely <grant.likely-s3s/[email protected]> writes:
: Overall the plan makes sense, however I would suggest thefollowing.
Quoted 1 line
: instead of 'live' modifying the tree, another option is to carry a
set
Quoted 1 line
: of 'stock' device trees in the kernel; one per board. Of course
this
Quoted 1 line
: assumes that your current ad-hoc code is keying on the specific
board.
Quoted 2 lines
: If it is interpreting data provided by the firmware, then your : suggestion of modifying a single stock tree probably makes more
sense,
Quoted 8 lines
: 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.