On 11/7/19 11:15 PM, Stefano Stabellini via System-dt wrote:
Signed-off-by: Stefano Stabellini stefano.stabellini@xilinx.com
source/devicenodes.rst | 88 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 88 insertions(+)
diff --git a/source/devicenodes.rst b/source/devicenodes.rst index 8825ad9..bcf6163 100644 --- a/source/devicenodes.rst +++ b/source/devicenodes.rst @@ -737,3 +737,91 @@ each with their own on-chip L2 and a shared L3. }; }; +.. _sect-cpus-cluster:
+CPUs Cluster Node Properties +----------------------------
+Similarly to ``/cpus``, CPUs cluster nodes do not represent real devices +in the system, but act as containers for children cpu nodes. They group +together a set of CPUs that share the same view of the system, the same +``address-map`` (see section :ref:`sect-address-map`). CPUs clusters are +optional, there can be multiple in a single system, and are represented +by nodes compatible with ``cpus,cluster``.
Hi Stefano,
Earlier this year I have proposed a concept of domain-ctrl [1]. I think it is close to your idea of CPUs clusters since it aim to describe group of hardware blocks that share the same access rights in the system. I was targeting the bus firewalls that we can find on many SoC.
Do you think we can mix these two concepts ? It would, at least, means extend your CPUs cluster concept to be able to describe CPU when they are running in TrustZone.
Regards,
Benjamin
[1] https://lwn.net/ml/linux-kernel/20190227121232.24873-1-benjamin.gaignard@st....
+A child ``cpu`` node represents a system CPU. All ``cpus`` nodes under +the same cluster share key properties (i.e. instruction set) so that a +SMP operating system could run on all of the CPUs in the cluster if +configured to do so.
+.. tabularcolumns:: | p{4cm} p{0.75cm} p{4cm} p{6.5cm} | +.. table:: ``CPUs cluster`` Node Properties
- ======================= ===== ===================== ===============================================
- Property Name Usage Value Type Definition
- ======================= ===== ===================== ===============================================
- ``compatible`` R ``<string list>`` Value shall include "cpus,cluster".
- ``#address-cells`` R ``<u32>`` The value specifies how many cells each
element of the ``reg`` property array takes inchildren of this node.- ``#size-cells`` R ``<u32>`` Value shall be 0. Specifies that no size is
required in the ``reg`` property in children ofthis node.- ``address-map`` SD ``<array>`` If present, it specifies an address mapping
translation between the root node and theaddress space of the CPUs cluster. address-mapis fully described in section:ref:`sect-address-map`.- Usage legend: R=Required, O=Optional, OR=Optional but Recommended, SD=See Definition
- ===================================================================================================
+The CPUs cluster node may contain properties that are common across CPU +nodes.
+Example:
+.. code-block:: dts
- cpus_a53 {
#size-cells = <0x0>;#address-cells = <0x1>;compatible = "cpus,cluster";cpu@0 {reg = <0x0>;compatible = "arm,cortex-a53";device_type = "cpu";};cpu@1 {reg = <0x1>;compatible = "arm,cortex-a53";device_type = "cpu";};cpu@2 {reg = <0x2>;compatible = "arm,cortex-a53";device_type = "cpu";};cpu@3 {reg = <0x3>;compatible = "arm,cortex-a53";device_type = "cpu";};- };
- cpus_r5 {
#size-cells = <0x0>;#address-cells = <0x1>;compatible = "cpus,cluster";cpu@0 {reg = <0x0>;compatible = "arm,cortex-r5";device_type = "cpu";};cpu@1 {reg = <0x1>;compatible = "arm,cortex-r5";device_type = "cpu";};- };
On Mon, 18 Nov 2019, Benjamin GAIGNARD wrote:
On 11/7/19 11:15 PM, Stefano Stabellini via System-dt wrote:
Signed-off-by: Stefano Stabellini stefano.stabellini@xilinx.com
source/devicenodes.rst | 88 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 88 insertions(+)
diff --git a/source/devicenodes.rst b/source/devicenodes.rst index 8825ad9..bcf6163 100644 --- a/source/devicenodes.rst +++ b/source/devicenodes.rst @@ -737,3 +737,91 @@ each with their own on-chip L2 and a shared L3. }; }; +.. _sect-cpus-cluster:
+CPUs Cluster Node Properties +----------------------------
+Similarly to ``/cpus``, CPUs cluster nodes do not represent real devices +in the system, but act as containers for children cpu nodes. They group +together a set of CPUs that share the same view of the system, the same +``address-map`` (see section :ref:`sect-address-map`). CPUs clusters are +optional, there can be multiple in a single system, and are represented +by nodes compatible with ``cpus,cluster``.
Hi Stefano,
Earlier this year I have proposed a concept of domain-ctrl [1]. I think it is close to your idea of CPUs clusters since it aim to describe group of hardware blocks that share the same access rights in the system. I was targeting the bus firewalls that we can find on many SoC.
Do you think we can mix these two concepts ? It would, at least, means extend your CPUs cluster concept to be able to describe CPU when they are running in TrustZone.
Hi Benjamin,
Yes, we should be able to describe CPUs that are running in TrustZone. This is something that we have already discussed in the context of CPUs clusters, and, for instance, it could be handled by introducing an appropriate property. I would be happy to discuss such an extension in details.
However, please be aware that one of the main design principles we have been following is to distinguish between hardware description and software/firmware configurations. There are multiple reasons for that. For starters, device tree already keeps hardware description and configuration separate (the configuration is under /chosen and few other similar nodes). Another reason is that the hardware description information and the configuration information come at different stages, and are typically produced by different personas. Our presentation at the last Linaro Connect could be of help (especially the part starting at 7:20):
https://connect.linaro.org/resources/san19/san19-115/
I wrote that because if your main goal is to target bus firewalls, those are typically configurable. They are best covered by separate bindings that have not been submitted to the list yet, but for which we have examples. They have been presented as "openamp,domain-v1" compatible nodes under /chosen in the presentation at Linaro Connect. The purpose of "openamp,domain-v1" nodes is to provide information in regards to a software/firmware configurations of a set of CPUs in the system. In fact, their main goal is to configure bus firewalls appropriately.
Cheers,
Stefano
On 11/20/19 8:57 PM, Stefano Stabellini wrote:
On Mon, 18 Nov 2019, Benjamin GAIGNARD wrote:
On 11/7/19 11:15 PM, Stefano Stabellini via System-dt wrote:
Signed-off-by: Stefano Stabellini stefano.stabellini@xilinx.com
source/devicenodes.rst | 88 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 88 insertions(+)
diff --git a/source/devicenodes.rst b/source/devicenodes.rst index 8825ad9..bcf6163 100644 --- a/source/devicenodes.rst +++ b/source/devicenodes.rst @@ -737,3 +737,91 @@ each with their own on-chip L2 and a shared L3. }; }; +.. _sect-cpus-cluster:
+CPUs Cluster Node Properties +----------------------------
+Similarly to ``/cpus``, CPUs cluster nodes do not represent real devices +in the system, but act as containers for children cpu nodes. They group +together a set of CPUs that share the same view of the system, the same +``address-map`` (see section :ref:`sect-address-map`). CPUs clusters are +optional, there can be multiple in a single system, and are represented +by nodes compatible with ``cpus,cluster``.
Hi Stefano,
Earlier this year I have proposed a concept of domain-ctrl [1]. I think it is close to your idea of CPUs clusters since it aim to describe group of hardware blocks that share the same access rights in the system. I was targeting the bus firewalls that we can find on many SoC.
Do you think we can mix these two concepts ? It would, at least, means extend your CPUs cluster concept to be able to describe CPU when they are running in TrustZone.
Hi Benjamin,
Yes, we should be able to describe CPUs that are running in TrustZone. This is something that we have already discussed in the context of CPUs clusters, and, for instance, it could be handled by introducing an appropriate property. I would be happy to discuss such an extension in details.
However, please be aware that one of the main design principles we have been following is to distinguish between hardware description and software/firmware configurations. There are multiple reasons for that. For starters, device tree already keeps hardware description and configuration separate (the configuration is under /chosen and few other similar nodes). Another reason is that the hardware description information and the configuration information come at different stages, and are typically produced by different personas. Our presentation at the last Linaro Connect could be of help (especially the part starting at 7:20):
https://connect.linaro.org/resources/san19/san19-115/
I wrote that because if your main goal is to target bus firewalls, those are typically configurable. They are best covered by separate bindings that have not been submitted to the list yet, but for which we have examples. They have been presented as "openamp,domain-v1" compatible nodes under /chosen in the presentation at Linaro Connect. The purpose of "openamp,domain-v1" nodes is to provide information in regards to a software/firmware configurations of a set of CPUs in the system. In fact, their main goal is to configure bus firewalls appropriately.
Could you share theses patches ?
/chosen nodes look static for me, do you have investigate a dynamic way for changing the configuration ?
I have in mind that hardware block configurations (firewalls, pins muxing, etc) could be change dynamically if we assign them from
another cluster. Could we imaging to apply configurations per cluster name ?
For example it would means add a pintrcl-names "openamp,domain-v1" to select pin mux configuration.
Benjamin
Cheers,
Stefano
On Wed, 27 Nov 2019, Benjamin GAIGNARD wrote:
On 11/20/19 8:57 PM, Stefano Stabellini wrote:
On Mon, 18 Nov 2019, Benjamin GAIGNARD wrote:
On 11/7/19 11:15 PM, Stefano Stabellini via System-dt wrote:
Signed-off-by: Stefano Stabellini stefano.stabellini@xilinx.com
source/devicenodes.rst | 88 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 88 insertions(+)
diff --git a/source/devicenodes.rst b/source/devicenodes.rst index 8825ad9..bcf6163 100644 --- a/source/devicenodes.rst +++ b/source/devicenodes.rst @@ -737,3 +737,91 @@ each with their own on-chip L2 and a shared L3. }; }; +.. _sect-cpus-cluster:
+CPUs Cluster Node Properties +----------------------------
+Similarly to ``/cpus``, CPUs cluster nodes do not represent real devices +in the system, but act as containers for children cpu nodes. They group +together a set of CPUs that share the same view of the system, the same +``address-map`` (see section :ref:`sect-address-map`). CPUs clusters are +optional, there can be multiple in a single system, and are represented +by nodes compatible with ``cpus,cluster``.
Hi Stefano,
Earlier this year I have proposed a concept of domain-ctrl [1]. I think it is close to your idea of CPUs clusters since it aim to describe group of hardware blocks that share the same access rights in the system. I was targeting the bus firewalls that we can find on many SoC.
Do you think we can mix these two concepts ? It would, at least, means extend your CPUs cluster concept to be able to describe CPU when they are running in TrustZone.
Hi Benjamin,
Yes, we should be able to describe CPUs that are running in TrustZone. This is something that we have already discussed in the context of CPUs clusters, and, for instance, it could be handled by introducing an appropriate property. I would be happy to discuss such an extension in details.
However, please be aware that one of the main design principles we have been following is to distinguish between hardware description and software/firmware configurations. There are multiple reasons for that. For starters, device tree already keeps hardware description and configuration separate (the configuration is under /chosen and few other similar nodes). Another reason is that the hardware description information and the configuration information come at different stages, and are typically produced by different personas. Our presentation at the last Linaro Connect could be of help (especially the part starting at 7:20):
https://connect.linaro.org/resources/san19/san19-115/
I wrote that because if your main goal is to target bus firewalls, those are typically configurable. They are best covered by separate bindings that have not been submitted to the list yet, but for which we have examples. They have been presented as "openamp,domain-v1" compatible nodes under /chosen in the presentation at Linaro Connect. The purpose of "openamp,domain-v1" nodes is to provide information in regards to a software/firmware configurations of a set of CPUs in the system. In fact, their main goal is to configure bus firewalls appropriately.
Could you share theses patches ?
I don't have patches to the specification for that yet, but I do have an example, see attached.
/chosen nodes look static for me, do you have investigate a dynamic way for changing the configuration ?
I have in mind that hardware block configurations (firewalls, pins muxing, etc) could be change dynamically if we assign them from
another cluster.
If you are referring to dynamically changing the "firewall" configuration at runtime, yes that is a goal for us too. However, it is still TBD.
When I wrote "configurable", I meant at system build/configuration time, as opposed to the fully static information that it is fixed, based on the unchangeable hardware description. The idea is that the basic hardware description is provided first, it shouldn't change, then the system software experts add additional information under /chosen regarding domain configurations.
Could we imaging to apply configurations per cluster name ?
For example it would means add a pintrcl-names "openamp,domain-v1" to select pin mux configuration.
Yes, the idea is exactly to apply configurations to specific clusters. In the example attached, there is one "openamp,domain-v1" node that refers to one of the R5 cpus (in this example they are not run in lockstep, but of course they could, and the domain could include both R5 cpus). The "access" property is the one with the information to program the firewall. In this example, "access" specifies the memory range and two devices (tcm, ethernet0) assigned to the R5 domain.
On 11/28/19 2:07 AM, Stefano Stabellini wrote:
On Wed, 27 Nov 2019, Benjamin GAIGNARD wrote:
On 11/20/19 8:57 PM, Stefano Stabellini wrote:
On Mon, 18 Nov 2019, Benjamin GAIGNARD wrote:
On 11/7/19 11:15 PM, Stefano Stabellini via System-dt wrote:
Signed-off-by: Stefano Stabellini stefano.stabellini@xilinx.com
source/devicenodes.rst | 88 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 88 insertions(+)diff --git a/source/devicenodes.rst b/source/devicenodes.rst index 8825ad9..bcf6163 100644 --- a/source/devicenodes.rst +++ b/source/devicenodes.rst @@ -737,3 +737,91 @@ each with their own on-chip L2 and a shared L3. }; }; +.. _sect-cpus-cluster:
+CPUs Cluster Node Properties +----------------------------
+Similarly to ``/cpus``, CPUs cluster nodes do not represent real devices +in the system, but act as containers for children cpu nodes. They group +together a set of CPUs that share the same view of the system, the same +``address-map`` (see section :ref:`sect-address-map`). CPUs clusters are +optional, there can be multiple in a single system, and are represented +by nodes compatible with ``cpus,cluster``.
Hi Stefano,
Earlier this year I have proposed a concept of domain-ctrl [1]. I think it is close to your idea of CPUs clusters since it aim to describe group of hardware blocks that share the same access rights in the system. I was targeting the bus firewalls that we can find on many SoC.
Do you think we can mix these two concepts ? It would, at least, means extend your CPUs cluster concept to be able to describe CPU when they are running in TrustZone.
Hi Benjamin,
Yes, we should be able to describe CPUs that are running in TrustZone. This is something that we have already discussed in the context of CPUs clusters, and, for instance, it could be handled by introducing an appropriate property. I would be happy to discuss such an extension in details.
However, please be aware that one of the main design principles we have been following is to distinguish between hardware description and software/firmware configurations. There are multiple reasons for that. For starters, device tree already keeps hardware description and configuration separate (the configuration is under /chosen and few other similar nodes). Another reason is that the hardware description information and the configuration information come at different stages, and are typically produced by different personas. Our presentation at the last Linaro Connect could be of help (especially the part starting at 7:20):
https://connect.linaro.org/resources/san19/san19-115/
I wrote that because if your main goal is to target bus firewalls, those are typically configurable. They are best covered by separate bindings that have not been submitted to the list yet, but for which we have examples. They have been presented as "openamp,domain-v1" compatible nodes under /chosen in the presentation at Linaro Connect. The purpose of "openamp,domain-v1" nodes is to provide information in regards to a software/firmware configurations of a set of CPUs in the system. In fact, their main goal is to configure bus firewalls appropriately.
Could you share theses patches ?
I don't have patches to the specification for that yet, but I do have an example, see attached.
/chosen nodes look static for me, do you have investigate a dynamic way for changing the configuration ?
I have in mind that hardware block configurations (firewalls, pins muxing, etc) could be change dynamically if we assign them from
another cluster.
If you are referring to dynamically changing the "firewall" configuration at runtime, yes that is a goal for us too. However, it is still TBD.
I think that must be anticipated to avoid creating bindings that will not make this possible after. My patches aim to propose this kind of interface, could these be a starting point for this activity ?
When I wrote "configurable", I meant at system build/configuration time, as opposed to the fully static information that it is fixed, based on the unchangeable hardware description. The idea is that the basic hardware description is provided first, it shouldn't change, then the system software experts add additional information under /chosen regarding domain configurations.
I don't know exactly how /chosen works but it sound like providing boot args to the kernel, right ?
Could we imaging to apply configurations per cluster name ?
For example it would means add a pintrcl-names "openamp,domain-v1" to select pin mux configuration.
Yes, the idea is exactly to apply configurations to specific clusters. In the example attached, there is one "openamp,domain-v1" node that refers to one of the R5 cpus (in this example they are not run in lockstep, but of course they could, and the domain could include both R5 cpus). The "access" property is the one with the information to program the firewall. In this example, "access" specifies the memory range and two devices (tcm, ethernet0) assigned to the R5 domain.
That exclude the possibility to change firewall configuration at runtime. Would like to get something that describe the hardware configurations like pinctrl framework does (i.e. with a list of states) so each device could provide it configuration for each domain.
With your proposal, will it be possible to change/overwrite any configuration of any node ?
Benjamin
system-dt@lists.openampproject.org
-
Benjamin GAIGNARD -
Stefano Stabellini