All APU executable layers below EL3 may indirectly communicate with the PMU via the TF-A. The TF-A receives all calls made from the lower ELs, consolidates all requests and send the requests to the PMU.
Following Arm's SMC Calling Convention, the PM communication from the non-secure world to the TF-A is organized as SiP Service Calls, using a predefined SMC function identifier and SMC sub-range ownership as specified by the calling convention.
Note that the EEMI API implementation for the APU is compliant with the SMC64 calling convention only.
EEMI API calls made from the OS or hypervisor software level pass the 32-bit API ID as the SMC Function Identifier, and up to four 32-bit arguments as well. As all PM arguments are 32-bit values, pairs of two are combined into one 64-bit value.
The TF-A returns up to five 32-bit return values:
- Return status, either success or error and reason
- Additional information from the PM controller
Checking the API Version
Before using the EEMI API to manage the slave nodes, the user must check that EEMI API version implemented in the TF-A matches the version implemented in the PMU firmware. EEMI API version is a 32-bit value separated in higher 16 bits of MAJOR and lower 16 bits of MINOR part. Both fields must be the same between the TF-A and the PMU firmware.
The EEMI version implemented in the TF-A is defined in the local EEMI_API_VERSON flag. The rich OS may invoke the PM_GET_API_VERSION function to retrieve the EEMI API version from the PMU. If the versions are different, this call will report an error.
Checking the Chip ID
Linux or other rich OS can invoke the PM_GET_CHIPID function via SMC to retrieve the chip ID information from the PMU.
The return values are:
- CSU idcode register (see TRM).
- CSU version register (see TRM).