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