On Wed, 12 Feb 2020, Francois Ozog wrote:

...

System Device Tree Concepts

System Device Trees extends traditional Device Trees to handle heterogeneous SoCs with multiple CPUs and Execution Domains. An Execution Domain can be seen as an address space that is running a software image, whether an operating system, a hypervisor or firmware that has a set of cpus, memory and devices attached to it. I.e. Each individual CPU/core that is not part of an SMP cluster is a separate Execution Domain as is the different Execution Levels on an ARMv8-A architecture. Trusted and not trusted environment can also be viewed as separate Execution Domains.

[...]

...

Execution Domains

An execution domain is a collection of software, firmware, and board configurations that enable an operating system or an application to run a cpus cluster. With multiple cpus clusters in a system it is natural to have multiple execution domains, at least one per cpus cluster. There can be more than one execution domain for each cluster, with virtualization or non-lockstep execution (for cpus clusters that support it). Execution domains are configured and added at a later stage by a software architect.

Execution domains are expressed by a new node "openamp,domain" compatible. Being a configuration rather than a description, their natural place is under /chosen or under a similar new top-level node. In this example, I used /domains:

    domains {
            openamp_r5 {
                    compatible = "openamp,domain-v1";
                    cpus = <&cpus_r5 0x2 0x80000000>;
                    memory = <0x0 0x0 0x0 0x8000000>;
                    access = <&can@ff060000>;
            };
    };

An openamp,domain node contains information about:

• cpus: physical cpus on which the software is running on
• memory: memory assigned to the domain
• access: any devices configured to be only accessible by a domain

The access list is an array of links to devices that are configured to be only accessible by an execution domain, using bus firewalls or similar technologies.

The memory range assigned to an execution domain is expressed by the memory property. It needs to be a subset of the physical memory in the system. The memory property can also be used to express memory sharing between domains:

    domains {
            openamp_r5 {
                    compatible = "openamp,domain-v1";
                    memory = <0x0 0x0 0x0 0x8000000 0x8 0x0 0x0 0x10000>;
            };
            openamp_a72 {
                    compatible = "openamp,domain-v1";
                    memory = <0x0 0x8000000 0x0 0x80000000 0x8 0x0 0x0 0x10000>;
            };
    };

Are those domains also define a "reset domain"? I mean, you may want to selectively reset a domain (within a particular clock domain). Or shall reset-domains be defined and then domains would be defined on subsets of those?

Clock, reset, and power domains have their own hierarchies and they are somewhat independent from execution domains. The hierarchy of clocks is represented via the usual clock references and clock controllers in device tree. Similarly, reset and power have their own topologies. They could be entirely within an execution domain, or spanning multiple execution domains. Naturally, if two execution domains are part of the same power domain there are consequences, such as that one cannot be powered down without the other. The spec should allow us to describe all these cases, although some of them are more "useful" than others.