topic Re: SCFW Resource Management Confusion in i.MX Processors

SCFW Resource Management Confusion

paul_katarzis — Mon, 11 Feb 2019 19:16:28 GMT

I am very confused about how SCFW resource management works. The SCFW API Reference (B0 Dec 3 2018 version) gives a rough idea of how this works in section 7.5.1, but it is lacking many details. I have looked at the System Controller Firmware 101 Guide and the SCFW Porting Guide, but they have not provided much help. In particular there seems to be an implied distinction between the parent/child relationship of partitions and "owners" or "masters" of partitions without any clear definition. I have the following questions:

How does a partition become associated with an owner?
Who are all the possible owners in the SoC?
Does a partition have to have an owner?
What is a "master" within a partition?
Can a resource belong to more than one partition?
What exactly are the resources SC_R_M4_0_PID0 to SC_R_M4_0_PID4?
With respect to the sc_rm_set_subsys_rsrc_movable function, where can I find a list of all subsystems and all resource identifiers that belong to those subsystems? It seems the API call allows one to pass any resource belonging to a subsystem in order to make all related sources (whatever they are) movable.
What does it mean for a partition to be "secure" with respect to the sc_rm_partition_alloc function?
If "grant" is set to false in sc_rm_partition_alloc, does this mean the owner of the parent partition can no longer access resources in the child partition?

Re: SCFW Resource Management Confusion

paul_katarzis — Tue, 12 Feb 2019 23:36:26 GMT

I reread the System Controller Firmware 101 - Resource Management Service guide and reviewed the SCFW API Reference and I think I may be able to answer some of my own questions about parents, children, owners, and masters. The following is what I extrapolated, so please correct me if I am wrong.

There are no owners of partitions. There are only masters and parent/child relationships between partitions. A master is a resource that has the ability to create child partitions. Partitions own resources.

When the system boots, there is one single partition and every resource is a member of it. The SCU M4, General Purpose M4, A35 cluster, and SECO M0+ are resources within this partitions but also masters. The SCU M4 takes the liberty of "holding" onto itself and the resources it will use and pushing the rest into a child partition. The original partition, now considered the SCFW partition, contains just the SCU M4 and the resources it will use. The child of this original partition, now considered the Boot partition, contains the General Purpose M4, A35 Cluster, and SECO M0+ masters along with the rest of the system resources.

The SCU M4 is a master and a member of the SCFW partition which is the parent of the Boot partition. Therefore the SCU M4 has the ability to create child partitions using resources from the SCFW partition or the Boot partition (assuming the Boot partition was created to allow the parent to access its resources). The General Purpose M4 is a master and a member of the Boot partition, but can only create child partitions using resources from the Boot partition. Any partition the General Purpose M4 makes will be a child of the Boot partition by default, but it can assign such a partition to be a child of some other partition.

I'm still not sure if a resource can belong to more than one partition. By the general definition of a partition, it should not, but slide 31 in the document AMF-AUT-T3360.pdf shows what looks like resources belonging to more than one partition (they are labeled as domains in the image, though). The return errors for sc_rm_assign_resource and sc_rm_move_all don't seem to indicate the possibility of failing to assign a resource to two different child partitions.

The following questions are also still not clear:

What exactly are the resources SC_R_M4_0_PID0 to SC_R_M4_0_PID4?
With respect to the sc_rm_set_subsys_rsrc_movable function, where can I find a list of all subsystems and all resource identifiers that belong to those subsystems? It seems the API call allows one to pass any resource belonging to a subsystem in order to make all related sources (whatever they are) movable.
What does it mean for a partition to be "secure" with respect to the sc_rm_partition_alloc function?

Re: SCFW Resource Management Confusion

CarlosCasillas — Wed, 13 Feb 2019 16:11:47 GMT

Hi Paul,

Could you please specify which processor are you using?

Best regards!

/Carlos

Re: SCFW Resource Management Confusion

paul_katarzis — Wed, 13 Feb 2019 16:23:09 GMT

Hello Carlos,

I am working with an imx8qxp (PIMX8QX6AVLFZAA).

Re: SCFW Resource Management Confusion

CarlosCasillas — Mon, 18 Feb 2019 20:35:18 GMT

Hi Paul,

I’m internally checking this. In the meantime, could you please specify if you are working with a Sales person or FAE? Because the i.MX8X is still on preproduction stage.

Best regards!

/Carlos

Re: SCFW Resource Management Confusion

CarlosCasillas — Fri, 01 Mar 2019 23:48:32 GMT

I have internally received reply to your questions, please check below:

How does a partition become associated with an owner?
A partition has a parent. A resource has an owner. A partition's parent is the partition that created it by calling sc_rm_partition_alloc().
Who are all the possible owners in the SoC?
Initially the SCU owns all the resources in the SoC. When partitions are created, resources can be assigned by the parent to the partitions.
Does a partition have to have an owner?
A partition doesn't have an owner, it has a parent. The parent's access to the partition's resources/peripherals is configurable. A parent can also completely orphan a child with by using the sc_rm_set_parent() API.
What is a "master" within a partition?
"Master" refers to a bus master in the SoC, something that can initiate a bus transaction.
Can a resource belong to more than one partition?
No, a resource only has one owning partition. Resources can be shared by the owning partition with other partitions by adjusting access rights.
What exactly are the resources SC_R_M4_0_PID0 to SC_R_M4_0_PID4?
These are process IDs for the M4 0 physical core. A process ID can be assigned to a partition, for instance a partition running Linux. This allows the Linux partition to make use of the M4 to generate transactions on behave of Linux partition. This type of configuration is made available for implementing a virtualization system. If you are not doing virtualization assign all the PIDs to the same partition as PID0.
With respect to the sc_rm_set_subsys_rsrc_movable function, where can I find a list of all subsystems and all resource identifiers that belong to those subsystems? It seems the API call allows one to pass any resource belonging to a subsystem in order to make all related sources (whatever they are) movable.
A subsystem is a physical grouping within the chip of related resources, this is chip specific. You will find the subsystems and the subsystems resources in the 'Resource List' chapter of the chip specific SC Firmware API reference guides. The API managing subsystem are supplied to optimize moving resource for these groupings, for instance, an M4 core and its associated resources.

What does it mean for a partition to be "secure" with respect to the sc_rm_partition_alloc function?
The "secure" configuration, indicates the default access privileges for a partition and its owned resources with respect to ARM Trustzone. A 'secure' partition would carry the 'Secure World' access privileges. A 'secure' partition can only be created by another 'secure' partition.
If "grant" is set to false in sc_rm_partition_alloc, does this mean the owner of the parent partition can no longer access resources in the child partition?
A false flag (the normal case for most instances) prevents a parent from having direct access to the peripherals owned by a child.
A true flag allows the parent to have total access the peripherals.

Re: SCFW Resource Management Confusion

paul_katarzis — Mon, 04 Mar 2019 03:22:46 GMT

Hello Carlos,

This has cleared up many things for me. Thank you very much!