Resource Groups

• Introduced as a convenient way to group resources together
  • to avoid needless repetitions
  • to explicitly group together resources shared between multiple domains

                resource_group0: resource_group@0 {
                    compatible = "openamp,resource-group-v1";

                    access = <&ethernet0 &serial0>;
                };

                linux1: domain@3 {
                    compatible = "openamp,domain-v1";

                    access = <&mmc0>;
                    include = <&resource_group0>;
                };

                linux2: domain@4 {
                    compatible = "openamp,domain-v1";

                    include = <&resource_group0>;
                };

The problem with Resource Groups

• Access flags are domain specific and they declare access-related properties
  • It is important that each domain can specify different access flags because they could be using different protection mechanisms
    • E.g. the parent domain uses a system-mmu, the child domain uses an iommu

• Resource Groups end up increasing complexity when access flags are in use

• Where to specify the domain-specific access flags for resource groups?

• The solution: hierarchical domain flags, redefined at each level

    domains {
        #address-cells = <0x2>;
        #size-cells = <0x2>;
        
        resource_group_1: resource_group_1 {
            compatible = "openamp,group-v1";

            access = <&ethernet0, &serial0>;
            access-flags-names = "dev1", "dev2";
        };

        subsystem1: domain@1 {
            compatible = "xilinx,subsystem-v1", "openamp,domain-v1";

            #flags-cells = <1>;
            flags = <0x1 0x2>;
            flags-names = "dev1", "dev2";

            access = <&mmc0>;
            access-flags-names = "dev1";

            xen: domain@2 {
                compatible = "openamp,domain-v1";

                linux1: domain@3 {
                    compatible = "openamp,domain-v1";

                    access = <&mmc0>;
                };

                linux2: domain@4 {
                    compatible = "openamp,domain-v1";

                    #flags-cells = <1>;
                    flags = <0x8>;
                    flags-names = "dev1";

                    include = <&resource_group_1>;
                };
            };
        };

        subsystem2: domain@5 {
            compatible = "xilinx,subsystem-v1", "openamp,domain-v1";

            #flags-cells = <1>;
            flags = <0x4>;
            flags-names = "dev1";

            access = <&can0>;
            access-flags-names = "dev1";

            include = <&resource_group_1>;
        };
    };

The removal of Resource Groups

• Hierarchical domain flags, redefined at each level
  • complex
  • difficult to explain and difficult to understand
• Removing Resource Groups:
  • every domain at every level specifies the full access list with any access flags as needed
  • Pros:
    • very simple
    • much easier to understand
  • Cons:
    • causes repetitions
    • no grouping of shared resources

    domains {
        #address-cells = <0x2>;
        #size-cells = <0x2>;

        subsystem1: domain@1 {
            compatible = "xilinx,subsystem-v1", "openamp,domain-v1";

            #access-flags-cells = <0x1>;
            access = <&mmc0 0x1 &ethernet0 0x1 &serial0 0x0>;

            xen: domain@2 {
                compatible = "openamp,domain-v1";

                #access-flags-cells = <0x0>;
                access = <&mmc0 &ethernet0 &serial0>;

                linux1: domain@3 {
                    compatible = "openamp,domain-v1";

                    #access-flags-cells = <0x0>;
                    access = <&mmc0>;
                };

                linux2: domain@4 {
                    compatible = "openamp,domain-v1";

                    #access-flags-cells = <0x1>;
                    access = <&ethernet0 0x8 &serial0 0x0>;
                };
            };
        };

        subsystem2: domain@5 {
            compatible = "xilinx,subsystem-v1", "openamp,domain-v1";

            #access-flags-cells = <0x1>;
            access = <&can0 0x4 &ethernet0 0x4 &serial0 0x0>;
        };
    };

The best of both: extended YAML anchors

We can express domains in YAML, in addition to DTS

domains:
    subsystem1:
        compatible:
            - xilinx,subsystem-v1
            - openamp,domain-v1

        access:
            - dev: ethernet0
              flags: { flag1: true }
            - dev: mmc0
              flags: { flag2: true }
            - dev: serial0

        domains:
            xen:
                compatible:
                    - openamp,domain-v1

                access:
                    - dev: ethernet0
                    - dev: mmc0
                    - dev: serial0

                domains:
                    linux1:
                        compatible:
                            - openamp,domain-v1
                        access:
                            - dev: mmc0

                    linux2:
                        compatible:
                            - openamp,domain-v1
                        access:
                            - dev: ethernet0
                              flags: { smmu-prop-1: true }
                            - dev: serial0

    subsystem2:
        compatible:
            - xilinx,subsystem-v1
            - openamp,domain-v1

        access:
            - dev: can0
              flags: { p1: 0x1 }
            - dev: ethernet0
              flags: { p2: 0x2 }
            - dev: serial0

The best of both: extended YAML anchors

• In YAML we can use anchors to avoid repetitions in a way similar to how we used resource groups

• We can define group of properties under ���definitions��� then refer to them in multiple places

The best of both: extended YAML anchors

• In reality, YAML anchors are not flexible enough

• Introducing a new syntax supported by Lopper: <<+
  • similar to YAML anchors but more flexible
  • supports multiple inheritance and list unrolling
• best of both
  • it enables us to avoid repetitions and group things together
  • it doesn���t cause any semantic issues because it works at a textual level

definitions:
    OpenAMP:
 
        openamp-channel-0-access-srams: &openamp-channel0-access-srams # used for access in each domain
            - dev: psu_r5_0_atcm_global
            - dev: psu_r5_0_btcm_global
 
        rproc1: &rproc_reserved1
            compatible: xilinx,openamp-ipc-1.0
            no-map: 1
            reg:
                - start: 0x3ed00000
                  size: 0x40000
 
        rproc0: &rproc_reserved0
            compatible: xilinx,openamp-ipc-1.0
            no-map: 1
            reg:
                - start: 0x3ed00000
                  size: 0x40000
 
        rpu0vdev0vring: &rpu0vdev0vring0
            compatible: xilinx,openamp-ipc-1.0
            no-map: 1
            reg:
                - start: 0x3ed40000
                  size: 0x4000
 
        rpu0vdev0vring1: &rpu0vdev0vring1
            compatible: xilinx,openamp-ipc-1.0
            no-map: 1
            reg:
                - start: 0x3ed44000
                  size: 0x4000
 
        rpu0vdev0buffer: &rpu0vdev0buffer
            compatible: xilinx,openamp-ipc-1.0
            no-map: 1
            reg:
                - start: 0x3ed48000
                  size: 0x100000
 
 
domains:
    openamp_a72_0_cluster: # host in channel from a72-0 to r5-1 over channel 0
        compatible: openamp,domain-v1
        cpus:
            - cluster: cpus_a72
              cpumask: 0x1
              mode:
                 secure: false
                 el: 0x1
        access:
            # if we want to have a list merge, it should be in a list
            - dev: ipi0  # used for Open AMP RPMsg IPC
            - <<+: [ *openamp-channel0-access-srams, *openamp-channel1-access-srams ]
            - <<+: *openamp-channel1-access-srams # TCM banks used for elf load
 
        reserved-memory:
            ranges: true
            # if we want an object / node merge, it should be like this (a map)
            - <<+: [*rpu0vdev0vring0, *rpu0vdev0vring1, *rpu0vdev0buffer, *rproc_reserved0 ]
 
        domain-to-domain:
            compatible: openamp,domain-to-domain-v1
 
            remoteproc0:
                compatible: openamp,remoteproc-v1
                remote: openamp_r5_0_cluster
                elfload:
                     - rproc_reserved0
                     - openamp-channel-0-access-srams
 
            rpmsg0:
                compatible: openamp,rpmsg-v1
                remote:  openamp_r5_0_cluster
                mbox: ipi0
                carveouts:
                   - rpu1vdev0vring0
                   - rpu1vdev0vring1
                   - rpu0vdev0buffer
 
 
    openamp_r5_0_cluster:
        compatible: openamp,domain-v1
        cpus:
            - cluster: cpus_r5
              cpumask: 0x1
              mode:
              secure: true
        access:
            - dev: ipi2
            - <<+: *openamp-channel0-access-srams # TCM banks used for firmware memory
        reserved-memory:
            ranges: true
            <<+: [ *rpu0vdev0vring0, *rpu0vdev0vring0, *rpu0vdev0buffer, *rproc_reserved0 ]
        domain-to-domain:
             compatible: openamp,domain-to-domain-v1
             relation0:
                 compatible: openamp,rpmsg-v1
                 host: openamp_a72_0_cluster
                 mbox: ipi2
                 carveouts:
                    - rpu1vdev0vring0
                    - rpu1vdev0vring1
                    - rpu0vdev0buffer