4 Service Groups

An RPMI service group is a collection of RPMI services that are logically grouped based on functionality. For example, all the voltage related services are grouped into a voltage service group. The functionality implemented by certain RPMI service groups may impact the architectural state of application processors due to this each RPMI service group specifies the RISC-V privilege levels of the application processor which can be access it. For example, the clock service groups can be accessed from M-mode and S-mode but the HSM service group can be only accessed from M-mode.

All RPMI service groups except the BASE service group are optional. If the BASE_PROBE_SERVICE_GROUP service indicates that a service group is implemented then the RPMI service group version must conform to the RPMI specification version returned by the BASE_GET_SPEC_VERSION service. All implemented RPMI service groups must satisfy the following requirements:

1. The RPMI service group must be accessible from the RISC-V privilege level associated with the RPMI context which includes it.
2. All RPMI services of the RPMI service groups must be supported except the dedicated notification service (SERVICE_ID = 0x00) which is reserved for RPMI notification messages. A RPMI service group may implement its RPMI services partially only if it also defines a mechanism to discover supported RPMI services.
3. The RPMI service group must implement a dedicated RPMI service with SERVICE_ID = 0x01 to subscribe for event notifications.

note

The RPMI services listed within each RPMI service group do not have a specific order. Additionally, the sequence in which services are defined in the specification does not necessarily reflect the order in which they should be invoked.

This specification defines standard RPMI service groups and RPMI services with the provision to add more service groups as required in the future. The RPMI specification also provides experimental service group IDs space for development of service group until a standard service group ID is allocated. The platform vendors can provide implementation specific RPMI service groups. The Table 7 table below lists all standard RPMI service groups defined by this specification.

Table 7. RPMI Service Groups

Service Group ID	RPMI Version (Major:Minor)	Service Group Name	Allowed RISC-V Privilege Levels on Application Processors
0x0001	1.0	BASE	M-mode, S-mode
0x0002	1.0	SYSTEM_MSI	M-mode, S-mode
0x0003	1.0	SYSTEM_RESET	M-mode
0x0004	1.0	SYSTEM_SUSPEND	M-mode
0x0005	1.0	HART_STATE_MANAGEMENT	M-mode
0x0006	1.0	CPPC	M-mode, S-mode
0x0007	1.0	VOLTAGE	M-mode, S-mode
0x0008	1.0	CLOCK	M-mode, S-mode
0x0009	1.0	DEVICE_POWER	M-mode, S-mode
0x000A	1.0	PERFORMANCE	M-mode, S-mode
0x000B	1.0	MANAGEMENT_MODE	M-mode, S-mode
0x000C	1.0	RAS_AGENT	M-mode, S-mode
0x000D	1.0	REQUEST_FORWARD	M-mode, S-mode
0x000E	2.0	LOGGING	M-mode, S-mode
0x000F	2.0	SYSTEM_IRQ	M-mode, S-mode
0x0010	2.0	TEE	M-mode, S-mode
0x0011 - 0x7BFF		Reserved for Future Use
0x7C00 - 0x7FFF		Experimental Service Groups
0x8000 - 0xFFFF		Implementation Specific Service Groups

Common Data for Enable Notification Service (Service ID = 0x01)

The mandatory RPMI service for each service group to subscribe to event notifications has a common Request and Response data structure. Each service group may refer to the Request and Response data table defined below, rather than defining the same tables in their respective sections.

Table 8. Request Data

Word	Name	Type	Description
0	EVENT_ID	uint32	The event to be subscribed for notification.
1	REQ_STATE	uint32	Change or query the current state of EVENT_ID notification. 0: Disable. 1: Enable. 2: Return current state. Any other values of REQ_STATE field other than the defined ones are reserved for future use.

Table 9. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Event is subscribed successfully. | | RPMI_ERR_INVALID_PARAM | EVENT_ID or REQ_STATE is invalid. | | RPMI_ERR_NOT_SUPPORTED | Notification for the EVENT_ID is not supported. | - Other errors Table 6.
1	CURRENT_STATE	uint32	Current EVENT_ID notification state. 0: Notification is disabled. 1: Notification is enabled. In case of REQ_STATE = 0 or 1, the CURRENT_STATE will return the requested In case of an error, the value of CURRENT_STATE is unspecified.

4.1 Service Group: BASE (SERVICEGROUP_ID: 0x0001)

The BASE service group is mandatory and provides the following services:

• Initial handshaking between the application processor and the platform microcontroller.
• Discovering the RPMI implementation version information.
• Discovering the implementation of a service group.
• Discovering platform specific information.

The following table lists the services in the BASE service group:

Table 10. BASE Services

Service ID	Service Name	Request Type	RPMI Version
0x01	BASE_ENABLE_NOTIFICATION	NORMAL_REQUEST	1.0
0x02	BASE_GET_IMPLEMENTATION_VERSION	NORMAL_REQUEST	1.0
0x03	BASE_GET_IMPLEMENTATION_ID	NORMAL_REQUEST	1.0
0x04	BASE_GET_SPEC_VERSION	NORMAL_REQUEST	1.0
0x05	BASE_GET_PLATFORM_INFO	NORMAL_REQUEST	1.0
0x06	BASE_PROBE_SERVICE_GROUP	NORMAL_REQUEST	1.0
0x07	BASE_GET_ATTRIBUTES	NORMAL_REQUEST	1.0

4.1.1 RPMI Implementation IDs

The RPMI specification defines space for standard implementation IDs and for experimental implementation IDs. The experimental implementation IDs can be used by the implementations until a standard implementation ID is assigned to it.

The RPMI implementations that have been assigned a standard implementation ID are listed in the table below.

Table 11. RPMI Implementation IDs

Implementation ID	Name
0x00000000	libRPMI [2]
0x00000001 - 0x7FFFFFFF	Reserved for Future Use
0x80000000 - 0xFFFFFFFF	Experimental Implementation IDs

4.1.2 Notifications

This service is used by the platform microcontroller to send the asynchronous message of type notification to the application processor. The message transfers the events defined by this service group. The events defined are listed in the below table.

Table 12. BASE Service Group Events

Event ID	Event Name	Event Data	Description
0x01	REQUEST_HANDLE_ERROR	NA	This event indicates that the platform microcontroller is unable to serve the message requests and acknowledgements are not guaranteed.

4.1.3 Service: BASE_ENABLE_NOTIFICATION (SERVICE_ID: 0x01)

This service allows the application processor to subscribe to BASE service group notifications. The platform may optionally support notifications for events that may occur. The platform microcontroller can send these notification messages to the application processor if they are implemented and the application processor has subscribed to them. The supported events are described in Section 4.1.2.

Refer to Table 8 for Request Data and Table 9 for Response Data.

4.1.4 Service: BASE_GET_IMPLEMENTATION_VERSION (SERVICE_ID: 0x02)

This service is used to get the RPMI implementation version of the platform microcontroller. The version returned is a 32-bit composite number containing the MAJOR and MINOR version numbers.

Table 13. Request Data

NA

Table 14. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | RPMI implementation version returned successfully. | - Other errors Table 6.
1	IMPL_VERSION	uint32	Implementation version. | Bits | Description | | --- | --- | | [31:16] | MAJOR number. | | [15:0] | MINOR number. |

4.1.5 Service: BASE_GET_IMPLEMENTATION_ID (SERVICE_ID: 0x03)

This service is used to get a 32-bit RPMI implementation ID assigned to the software that implements the RPMI specification. Every implementation ID is unique and listed in the Table 11.

Table 15. Request Data

NA

Table 16. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | RPMI implementation ID returned successfully. | - Other errors Table 6.
1	IMPL_ID	uint32	Implementation ID.

4.1.6 Service: BASE_GET_SPEC_VERSION (SERVICE_ID: 0x04)

This service is used to get the implemented RPMI specification version. The version returned is a 32-bit composite number containing the MAJOR and MINOR version numbers.

Table 17. Request Data

NA

Table 18. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | RPMI specification version returned successfully. | - Other errors Table 6
1	SPEC_VERSION	uint32	RPMI specification version. | Bits | Description | | --- | --- | | [31:16] | MAJOR number. | | [15:0] | MINOR number. |

4.1.7 Service: BASE_GET_PLATFORM_INFO (SERVICE_ID: 0x05)

This service is used to get additional platform information if available.

Table 19. Request Data

NA

Table 20. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Platform information returned successfully. | - Other errors Table 6.
1	PLATFORM_ID_LEN	uint32	Platform Identifier field length in bytes.
2	PLATFORM_ID	uint8[PLATFORM_ID_LEN]	Up to PLATFORM_ID_LEN bytes NULL terminated ASCII string. The use and interpretation of this field is implementation-defined. It can be used to convey details such as the vendor ID, vendor name, specific product model, revision, or configuration of the hardware.

4.1.8 Service: BASE_PROBE_SERVICE_GROUP (SERVICE_ID: 0x06)

This service is used to probe the implementation of a service group and to obtain the implemented service group version. The service group version is a 32-bit composite number containing the MAJOR and MINOR numbers.

If the service group is successfully probed then the implemented service group version is returned in the SERVICE_GROUP_VERSION field. Otherwise it returns 0.

Table 21. Request Data

Word	Name	Type	Description
0	SERVICEGROUP_ID	uint32	Service group ID.

Table 22. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service probed successfully. | - Other errors Table 6
1	SERVICE_GROUP_VERSION	uint32	Service group version. | Bits | Description | | --- | --- | | [31:16] | MAJOR number. | | [15:0] | MINOR number. |

4.1.9 Service: BASE_GET_ATTRIBUTES (SERVICE_ID: 0x07)

This service is used to discover additional features supported by the BASE service group.

Table 23. Request Data

NA

Table 24. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Attributes returned successfully. | - Other errors Table 6.
1	FLAGS0	uint32	| Bits | Description | | --- | --- | | [31:2] | Reserved and must be 0. | | [1] | RPMI context privilege level. 0b1: M-mode. 0b0: S-mode. | | [0] | 0b1: Supported. 0b0: Not supported. |
2	FLAGS1	uint32	Reserved and must be 0.
3	FLAGS2	uint32	Reserved and must be 0.
4	FLAGS3	uint32	Reserved and must be 0.

4.2 Service Group - SYSTEM_MSI (SERVICEGROUP_ID: 0x0002)

The SYSTEM_MSI service group defines services to allow application processors to receive MSIs upon system events such as P2A doorbell, graceful shutdown/reboot request, CPU hotplug event, memory hotplug event, etc.

The number of system MSIs supported by this service group is fixed and referred to as SYS_NUM_MSI. Each system MSI is associated with a unique index which is also referred to as SYS_MSI_INDEX where 0 \<&#8203;= SYS_MSI_INDEX \< SYS_NUM_MSI.

The association between system events and system MSI index (aka SYS_MSI_INDEX) is platform specific and must be discovered using hardware description mechanisms such as device tree or ACPI.

The system MSI state is 32-bit word also referred to as SYS_MSI_STATE which includes whether the system MSI is enabled/disabled and whether system MSI is currently pending at the platform microcontroller. The Table 25 below shows the encoding of SYS_MSI_STATE.

note

A system MSI can be pending for several reasons. For example, if the MSI target address and data are not configured, or if the configured MSI target address is not valid.

Table 25. System MSI State

Bits	Permission	Description
[31:2]	NA	Reserved and must be 0.
[1]	Read-Only	0b0: MSI is not pending.
[0]	Read-Write	0b0: MSI disabled.

The platform microcontroller can only send a pending system MSI if it is enabled and the configured with a valid MSI target address. The system MSI can be enabled/disabled using the SYSMSI_SET_MSI_STATE service whereas the system MSI target configuration can be done using the SYSMSI_SET_MSI_TARGET service.

note

If the system MSI target address is IMSIC, then the application processors will directly receive the system MSI whereas if the system MSI target address is setipnum register of a APLIC domain then the application processors receive it as wired interrupt.

The Table 26 below lists the services in the SYSTEM_MSI service group:

Table 26. SYSTEM_MSI Services

Service ID	Service Name	Request Type	RPMI Version
0x01	SYSMSI_ENABLE_NOTIFICATION	NORMAL_REQUEST	1.0
0x02	SYSMSI_GET_ATTRIBUTES	NORMAL_REQUEST	1.0
0x03	SYSMSI_GET_MSI_ATTRIBUTES	NORMAL_REQUEST	1.0
0x04	SYSMSI_SET_MSI_STATE	NORMAL_REQUEST	1.0
0x05	SYSMSI_GET_MSI_STATE	NORMAL_REQUEST	1.0
0x06	SYSMSI_SET_MSI_TARGET	NORMAL_REQUEST	1.0
0x07	SYSMSI_GET_MSI_TARGET	NORMAL_REQUEST	1.0

4.2.1 Notifications

This service group does not support any events for notification.

4.2.2 Service: SYSMSI_ENABLE_NOTIFICATION (SERVICE_ID: 0x01)

This service allows the application processor to subscribe to SYSTEM_MSI service group notifications. The platform may optionally support notifications for events that may occur. The platform microcontroller can send these notification messages to the application processor if they are implemented and the application processor has subscribed to them. The supported events are described in Section 4.2.1.

Refer to Table 8 for Request Data and Table 9 for Response Data.

4.2.3 Service: SYSMSI_GET_ATTRIBUTES (SERVICE_ID: 0x02)

This service is used to discover attributes of the system MSI service group.

Table 27. Request Data

NA

Table 28. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully. | - Other errors Table 6.
1	SYS_NUM_MSI	uint32	Number of system MSIs.
2	FLAGS0	uint32	Reserved and must be 0.
3	FLAGS1	uint32	Reserved and must be 0.

4.2.4 Service: SYSMSI_GET_MSI_ATTRIBUTES (SERVICE_ID: 0x03)

This service is used to discover attributes of a particular system MSI.

Table 29. Request Data

Word	Name	Type	Description
0	SYS_MSI_INDEX	uint32	Index of the system MSI.

Table 30. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully. | | RPMI_ERR_INVALID_PARAM | SYS_MSI_INDEX value is greater than SYS_NUM_MSI. | - Other errors Table 6.
1	FLAGS0	uint32	| Bits | Description | | --- | --- | | [31:1] | Reserved and must be 0. | | [0] | 0b1: M-mode. 0b0: M-mode or S-mode. |
2	FLAGS1	uint32	Reserved and must be 0.
3:6	SYS_MSI_NAME	uint8[16]	System MSI name, a NULL-terminated ASCII string up to 16-bytes.

4.2.5 Service: SYSMSI_SET_MSI_STATE (SERVICE_ID: 0x04)

This service is used to update the state of a system MSI. Specifically, it allows application processors to enable or disable a system MSI. The read-only bits of the system MSI state are not updated by this service.

Table 31. Request Data

Word	Name	Type	Description
0	SYS_MSI_INDEX	uint32	Index of the system MSI.
1	SYS_MSI_STATE	uint32	System MSI state as defined in Table 25.

Table 32. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | MSI is enabled or disabled successfully. | | RPMI_ERR_INVALID_PARAM | SYS_MSI_INDEX value is greater than SYS_NUM_MSI or SYS_MSI_STATE value is reserved or invalid. | - Other errors Table 6.

4.2.6 Service: SYSMSI_GET_MSI_STATE (SERVICE_ID: 0x05)

This service is used to get the current state of a system MSI.

Table 33. Request Data

Word	Name	Type	Description
0	SYS_MSI_INDEX	uint32	Index of the system MSI.

Table 34. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | MSI state is returned successfully. | | RPMI_ERR_INVALID_PARAM | SYS_MSI_INDEX value is greater than SYS_NUM_MSI. | - Other errors Table 6.
1	SYS_MSI_STATE	uint32	System MSI state as defined in Table 25.

4.2.7 Service: SYSMSI_SET_MSI_TARGET (SERVICE_ID: 0x06)

This service is used to configure the target address and data of a system MSI.

Table 35. Request Data

Word	Name	Type	Description
0	SYS_MSI_INDEX	uint32	Index of the system MSI.
1	SYS_MSI_ADDRESS_LOW	uint32	Lower 32-bit of the MSI address.
2	SYS_MSI_ADDRESS_HIGH	uint32	Upper 32-bit of the MSI address.
3	SYS_MSI_DATA	uint32	32-bit MSI data.

Table 36. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | MSI address and data are configured successfully. | | RPMI_ERR_INVALID_PARAM | SYS_MSI_INDEX value is greater than SYS_NUM_MSI. | | RPMI_ERR_INVALID_ADDR | MSI target address is invalid or it is not 4-byte aligned. | - Other errors Table 6.

4.2.8 Service: SYSMSI_GET_MSI_TARGET (SERVICE_ID: 0x07)

This service is used to get the current target address and data of a system MSI.

Table 37. Request Data

Word	Name	Type	Description
0	SYS_MSI_INDEX	uint32	Index of the system MSI.

Table 38. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | MSI target details returned successfully. | | RPMI_ERR_INVALID_PARAM | SYS_MSI_INDEX value is greater than SYS_NUM_MSI. | - Other errors Table 6.
1	SYS_MSI_ADDRESS_LOW	uint32	Lower 32-bit of the MSI address.
2	SYS_MSI_ADDRESS_HIGH	uint32	Upper 32-bit of the MSI address.
3	SYS_MSI_DATA	uint32	32-bit MSI data.

4.3 Service Group - SYSTEM_RESET (SERVICEGROUP_ID: 0x0003)

This service group defines services for system-level reset or shutdown.

The architectural reset types that are supported by default are System Cold Reset and System Shutdown.

System Cold Reset, also known as power-on-reset, involves power cycling the entire system. Upon a successful system cold reset, all devices undergo power cycling in an implementation-defined sequence similar to the initial power-on sequence of the system.

System Shutdown results in all components/devices in the system losing power. Currently, the application processor is the only entity that can request the system shutdown, which means that for the platform microcontroller, it is not necessary to categorize it as a graceful or forceful shutdown. In the case of a shutdown request, it is implicit for the platform microcontroller that the application processor has prepared itself for a successful shutdown.

The following table lists the services in the SYSTEM_RESET service group:

Table 39. SYSTEM_RESET Services

Service ID	Service Name	Request Type	RPMI Version
0x01	SYSRST_ENABLE_NOTIFICATION	NORMAL_REQUEST	1.0
0x02	SYSRST_GET_ATTRIBUTES	NORMAL_REQUEST	1.0
0x03	SYSRST_RESET	POSTED_REQUEST	1.0

4.3.1 Reset Types

RPMI supports reset types and their values as defined by SBI specification. Refer to SRST System Reset Types in the RISC-V SBI Specification [1] for the RESET_TYPE.

4.3.2 Notifications

This service group does not support any events for notification.

4.3.3 Service: SYSRST_ENABLE_NOTIFICATION (SERVICE_ID: 0x01)

This service allows the application processor to subscribe to SYSTEM_RESET service group notifications. The platform may optionally support notifications for events that may occur. The platform microcontroller can send these notification messages to the application processor if they are implemented and the application processor has subscribed to them. The supported events are described in Section 4.3.2.

Refer to Table 8 for Request Data and Table 9 for Response Data.

4.3.4 Service: SYSRST_GET_ATTRIBUTES (SERVICE_ID: 0x02)

This service is used to discover the attributes of a reset type. The attribute flags indicates if a RESET_TYPE is supported or not apart from the System Shutdown and System Cold Reset which are mandatory and supported by default. System Warm Reset support can be discovered with this service.

Table 40. Request Data

Word	Name	Type	Description
0	RESET_TYPE	uint32	Refer Section 4.3.1 for more details.

Table 41. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Attributes returned successfully. | - Other errors Table 6.
1	FLAGS	uint32	Reset type attributes. | Bits | Description | | --- | --- | | [31:1] | Reserved and must be 0. | | [0] | Reset type support. 0b1: Supported. 0b0: Not supported. |

4.3.5 Service: SYSRST_RESET (SERVICE_ID: 0x03)

This service is used to initiate the system reset or system shutdown. The application processor must only request supported reset types, discovered using the SYSRST_GET_ATTRIBUTES service except for System Shutdown and System Cold Reset which are supported by default. This service does not return a response. If an invalid reset type is provided, the reset request is ignored. If the system reset fails, the resulting system state is unspecified.

Table 42. Request Data

Word	Name	Type	Description
0	RESET_TYPE	uint32	Refer Section 4.3.1 for more details.

Table 43. Response Data

NA

4.4 Service Group - SYSTEM_SUSPEND (SERVICEGROUP_ID: 0x0004)

This service group defines services used to request platform microcontroller to transition the system into a suspend state, also called a sleep state. The suspend state SUSPEND_TO_RAM is supported by default by the platform and if the application processor requests for SUSPEND_TO_RAM, it’s implicit for the platform microcontroller that all the application processors except the one requesting are in STOPPED state and necessary state saving in the RAM has been complete.

The following table lists the services in the SYSTEM_SUSPEND service group:

Table 44. SYSTEM_SUSPEND Services

Service ID	Service Name	Request Type	RPMI Version
0x01	SYSSUSP_ENABLE_NOTIFICATION	NORMAL_REQUEST	1.0
0x02	SYSSUSP_GET_ATTRIBUTES	NORMAL_REQUEST	1.0
0x03	SYSSUSP_SUSPEND	NORMAL_REQUEST	1.0

4.4.1 Suspend Types

RPMI supports suspend types and their values as defined by SBI specification. Refer to SBI System Sleep Types in the RISC-V SBI Specification [1] for the SUSPEND_TYPE definition.

4.4.2 Notifications

This service group does not support any events for notification.

4.4.3 Service: SYSSUSP_ENABLE_NOTIFICATION (SERVICE_ID: 0x01)

This service allows the application processor to subscribe to SYSTEM_SUSPEND service group notifications. The platform may optionally support notifications for events that may occur. The platform microcontroller can send these notification messages to the application processor if they are implemented and the application processor has subscribed to them. The supported events are described in Section 4.4.2.

Refer to Table 8 for Request Data and Table 9 for Response Data.

4.4.4 Service: SYSSUSP_GET_ATTRIBUTES (SERVICE_ID: 0x02)

This service is used to discover the attributes of a suspend type. The attribute flags for a suspend type indicate whether a SUSPEND_TYPE is supported. Additionally, the flags specify whether a SUSPEND_TYPE supports a resume address.

Table 45. Request Data

Word	Name	Type	Description
0	SUSPEND_TYPE	uint32	Refer Section 4.4.1 for more details.

Table 46. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Attributes returned successfully. | - Other errors Table 6.
1	FLAGS	uint32	Suspend type attributes. | Bits | Description | | --- | --- | | [31:2] | Reserved and must be 0. | | [1] | If a SUSPEND_TYPE supports custom resume address which platform must configure for the resuming application processor. 0b1: Supported. 0b0: Not supported. | | [0] | Suspend type Support. 0b1: Supported. 0b0: Not supported. |

4.4.5 Service: SYSSUSP_SUSPEND (SERVICE_ID: 0x03)

This service is used to request the platform microcontroller to transition the system in a suspend state. This service returns successfully when the platform microcontroller accepts the system suspend request. The application processor which called this service must then enter into a quiesced state such as WFI. The platform microcontroller will transition the system to the requested SUSPEND_TYPE upon the successful transition of the application processor into the supported quiesced state. The mechanism for detecting the quiesced state of the application processor is platform specific.

The application processor must only request supported suspend types, discovered using the SYSSUSP_GET_ATTRIBUTES service.

If a suspend type does not support the custom resume address that the application processor can discover through the SYSSUSP_GET_ATTRIBUTES service then the RESUME_ADDR_LOW and RESUME_ADDR_HIGH will be ignored and the application processor will resume from the pc (program counter) after the instruction that put the application processor in the quiesced state, such as the WFI instruction.

Table 47. Request Data

Word	Name	Type	Description
0	HART_ID	uint32	Hart ID of the calling hart.
1	SUSPEND_TYPE	uint32	Refer Section 4.4.1 for more details.
2	RESUME_ADDR_LOW	uint32	Lower 32-bit address.
3	RESUME_ADDR_HIGH	uint32	Upper 32-bit address.

Table 48. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully. Suspend request has been accepted. | | RPMI_ERR_INVALID_PARAM | HART_ID or SUSPEND_TYPE is invalid. | | RPMI_ERR_INVALID_ADDR | Resume address is invalid. | - Other errors Table 6.

4.5 Service Group - HART_STATE_MANAGEMENT (SERVICEGROUP_ID: 0x0005)

This service group defines services to control and manage the application processor (hart) power states. Hart power states include power on, power off, suspend modes, etc. A hart is identified by a 32-bit identifier called HART_ID.

In a platform, depending on the sharing of power controls and common resources, the harts can be grouped in a hierarchical topology to form cores, clusters, nodes, etc. In such cases the power state change for a hart can affect the entire hierarchical group in which the hart is located, requiring coordination for the power state change. RPMI supports the coordination mechanisms and hart power states defined by the RISC-V SBI Specification [1].

The following table lists the services in the HART_STATE_MANAGEMENT service group:

Table 49. HART_STATE_MANAGEMENT Services

Service ID	Service Name	Request Type	RPMI Version
0x01	HSM_ENABLE_NOTIFICATION	NORMAL_REQUEST	1.0
0x02	HSM_GET_HART_STATUS	NORMAL_REQUEST	1.0
0x03	HSM_GET_HART_LIST	NORMAL_REQUEST	1.0
0x04	HSM_GET_SUSPEND_TYPES	NORMAL_REQUEST	1.0
0x05	HSM_GET_SUSPEND_INFO	NORMAL_REQUEST	1.0
0x06	HSM_HART_START	NORMAL_REQUEST	1.0
0x07	HSM_HART_STOP	NORMAL_REQUEST	1.0
0x08	HSM_HART_SUSPEND	NORMAL_REQUEST	1.0

4.5.1 Hart States

Hart HSM states and the HSM state machine supported by the RPMI are defined in the RISC-V SBI Specification [1]. Refer to HSM States.

From a hart perspective a start state means hart has started execution of instructions and stop state means that hart is not executing the instructions. The platform can implement the stop state either by powering down the hart or just putting the hart in a platform supported low-power state.

4.5.2 Hart Suspend Types

The RPMI supports the hart suspend types encoding as defined in RISC-V SBI Specification [1]. Refer to HSM Suspend Types. The values for the platform supported suspend types are discovered through a service defined in this service group.

4.5.3 Notifications

This service group does not support any events for notification.

4.5.4 Service: HSM_ENABLE_NOTIFICATION (SERVICE_ID: 0x01)

This service allows the application processor to subscribe to HART_STATE_MANAGEMENT service group notifications. The platform may optionally support notifications for events that may occur. The platform microcontroller can send these notification messages to the application processor if they are implemented and the application processor has subscribed to them. The supported events are described in Section 4.5.3.

Refer to Table 8 for Request Data and Table 9 for Response Data.

4.5.5 Service: HSM_GET_HART_STATUS (SERVICE_ID: 0x02)

This service returns the current HSM state of a hart. If a hart is in an invalid state that is not a defined HSM state, an error code will be set in the STATUS field.

Table 50. Request Data

Word	Name	Type	Description
0	HART_ID	uint32	Hart ID.

Table 51. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully. | | RPMI_ERR_INVALID_PARAM | HART_ID is invalid. | | RPMI_ERR_INVALID_STATE | Hart is in invalid state. | - Other errors Table 6.
1	HART_STATE	uint32	Refer Section 4.5.1 for more details.

4.5.6 Service: HSM_GET_HART_LIST (SERVICE_ID: 0x03)

This service retrieves the list of Hart IDs managed by this service group.

If the number of words required for all available Hart IDs exceeds the number of words that can be returned in one acknowledgement message then the platform microcontroller will set the REMAINING and RETURNED fields accordingly and only return the Hart IDs which can be accommodated. The application processor may need to call this service again with the appropriate START_INDEX until the REMAINING field returns 0.

Table 52. Request Data

Word	Name	Type	Description
0	START_INDEX	uint32	Start index of the Hart ID.

Table 53. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully. | | RPMI_ERR_INVALID_PARAM | START_INDEX is invalid. | - Other errors Table 6.
1	REMAINING	uint32	Remaining number of Hart IDs to be returned.
2	RETURNED	uint32	Number of Hart IDs returned in this request.
3	HART_ID[N]	uint32	Hart IDs list.

4.5.7 Service: HSM_GET_SUSPEND_TYPES (SERVICE_ID: 0x04)

This service gets the list of all supported suspend types for a hart. The suspend types in the list must be ordered based on increasing power savings.

If the number of words required for all available suspend types exceeds the number of words that can be returned in one acknowledgement message then the platform microcontroller will set the REMAINING and RETURNED fields accordingly and only return the suspend types which can be accommodated. The application processor may need to call this service again with the appropriate START_INDEX until the REMAINING field returns 0.

The attributes and details of each suspend type can be discovered using the HSM_GET_SUSPEND_INFO service.

Table 54. Request Data

Word	Name	Type	Description
0	START_INDEX	uint32	0 for the first call, subsequent calls will use the next index of the remaining items.

Table 55. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully. | | RPMI_ERR_INVALID_PARAM | START_INDEX is invalid. | - Other errors Table 6.
1	REMAINING	uint32	Remaining number of suspend types to be returned.
2	RETURNED	uint32	Number of suspend types returned in this request.
3	SUSPEND_TYPE[N]	uint32	Refer Section 4.5.2 for more details.

4.5.8 Service: HSM_GET_SUSPEND_INFO (SERVICE_ID: 0x05)

This service is used to get the attributes of a suspend type. The attributes of a suspend type include various associated latencies. The entry latency for a suspend type is the maximum amount of time that the hart requires to transition from the execution state to the low-power suspend state when the hart invokes an quiesced state entry mechanism such as WFI. The exit latency is the time required by the hart to transition from the suspend state to execution state after the wakeup event.

For each suspend state there is a point of no return after which the suspend state transition cannot be reversed. The wakeup latency is the maximum time required by the hart to transition from the point of no return to the execution state. If the platform returns 0 in WAKEUP_LATENCY then the application processor can use the (ENTRY_LATENCY + EXIT_LATENCY) as the wakeup latency.

The minimum residency of a suspend state is the minimum time the application processor must remain in that suspend state to become energy efficient compared to the shallower suspend state.

note

The energy is also consumed while entering and exiting a suspend state. The application processor must spend time equal to or more than minimum residency to justify the energy cost of entering and exiting that suspend state.

note

The application processor entering into a deeper suspend state with a high minimum residency will incur a longer wakeup latency due to more time required to exit that suspend state. If the predicted idle time by the application processor is less than the minimum residency of a suspend state, it should select the shallower suspend state to minimize the wakeup latency to achieve energy savings.

Table 56. Request Data

Word	Name	Type	Description
0	SUSPEND_TYPE	uint32	Refer Section 4.5.2 for more details.

Table 57. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully. | | RPMI_ERR_INVALID_PARAM | SUSPEND_TYPE is invalid. | - Other errors Table 6.
1	FLAGS	uint32	| Bits | Description | | --- | --- | | [31: 1] | Reserved and must be 0. | | [0] | Local timer running status. 0b1: Local timer stops when the hart is suspended. 0b0: Local timer does not stop when hart is suspended. |
2	ENTRY_LATENCY	uint32	Entry latency in microseconds.
3	EXIT_LATENCY	uint32	Exit latency in microseconds.
4	WAKEUP_LATENCY	uint32	Wakeup latency in microseconds.
5	MIN_RESIDENCY	uint32	Minimum residency time in microseconds.

4.5.9 Service: HSM_HART_START (SERVICE_ID: 0x06)

This service is used to start the execution on a hart identified by HART_ID. This service requires a start address which is the physical address from which the target hart will start execution. Successful completion of this service means that the hart has started execution from the specified start address.

Table 58. Request Data

Word	Name	Type	Description
0	HART_ID	uint32	Hart ID of the target hart to be started.
1	START_ADDR_LOW	uint32	Lower 32-bit of the start address.
2	START_ADDR_HIGH	uint32	Upper 32-bit of the start address.

Table 59. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully and hart has started. | | RPMI_ERR_INVALID_PARAM | HART_ID or start address is invalid. | | RPMI_ERR_ALREADY | Hart is already in transition to start state or has already started. | | RPMI_ERR_DENIED | Hart is not in stopped state. | | RPMI_ERR_HW_FAULT | Failed due to hardware fault. | - Other errors Table 6.

4.5.10 Service: HSM_HART_STOP (SERVICE_ID: 0x07)

This service stops the execution on the calling hart. The mechanism for stopping the hart is platform specific. The hart can be powered down, if supported, or put into the deepest available sleep state.

This service returns successful if the platform microcontroller has successfully acknowledged that the target hart can be stopped. The hart upon successful acknowledgement can perform the final context saving if required and must enter into a quiesced state such as WFI which can be detected and allow the platform microcontroller to proceed to stop the hart. The mechanism to detect the hart quiesced state by the platform microcontroller is platform specific.

Once the hart is stopped, it can only be restarted by explicitly invoking the HSM_HART_START service call explicitly by any other hart.

Table 60. Request Data

Word	Name	Type	Description
0	HART_ID	uint32	Hart ID of the calling hart.

Table 61. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully and hart is stopped. | | RPMI_ERR_ALREADY | Hart is already in transition to stop state or has already stopped. | | RPMI_ERR_DENIED | Hart is not in start state. | | RPMI_ERR_HW_FAULT | Failed due to hardware failure. | - Other errors Table 6.

4.5.11 Service: HSM_HART_SUSPEND (SERVICE_ID: 0x08)

This service is used to put a hart in a low-power suspend state supported by the platform. Each suspend type is a 32-bit value which is discovered through the HSM_GET_SUSPEND_TYPES service.

This service returns successful if the platform microcontroller has successfully acknowledged that the target hart can be put into the requested SUSPEND_TYPE state. The target hart after the successful acknowledgement must enter into a quiesced state such as WFI which can be detected and allow the platform microcontroller complete the suspend state transition. The mechanism to detect the hart quiesced state by the platform microcontroller is platform specific.

For non-retentive suspend state the hart will resume its execution from the provided resume address.

Table 62. Request Data

Word	Name	Type	Description
0	HART_ID	uint32	Hart ID of the calling hart.
1	SUSPEND_TYPE	uint32	Refer Section 4.5.2 for more details.
2	RESUME_ADDR_LOW	uint32	Only used for non-retentive suspend types.
3	RESUME_ADDR_HIGH	uint32	Only used for non-retentive suspend types.

Table 63. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully. | | RPMI_ERR_INVALID_PARAM | HART_ID or SUSPEND_TYPE is invalid. | - Other errors Table 6.

4.6 Service Group - CPPC (SERVICEGROUP_ID: 0x0006)

This service group defines the services to control application processor performance by managing a set of registers per application processor that are used for performance management and control. The ACPI CPPC (Collaborative Processor Performance Control) is an abstract and flexible mechanism that allows application processor to collaborate with the platform microcontroller to control the performance.

The CPPC extension defined in the RISC-V SBI specification [1] defines the register IDs for the standard CPPC registers, along with additional registers also required by the application processor.

The ACPI CPPC specification [3] provides the details of the CPPC registers and also provides details on the performance control mechanism through CPPC.

This service group works with the abstract performance scale defined by the ACPI CPPC and is managed by the platform which is responsible for the conversion between the abstract performance level and the internal performance operating point.

The platform may have multiple application processors that share the actual performance controls like clock, voltage regulator and others depending on the platform. In such cases a performance level change for one application processor will affect the entire the group sharing the controls. Its the responsibility of the power and performance management software running on the application processor and the platform to coordinate and manage the group level performance changes.

The following table lists the services in the CPPC service group:

Table 64. CPPC Services

Service ID	Service Name	Request Type	RPMI Version
0x01	CPPC_ENABLE_NOTIFICATION	NORMAL_REQUEST	1.0
0x02	CPPC_PROBE_REG	NORMAL_REQUEST	1.0
0x03	CPPC_READ_REG	NORMAL_REQUEST	1.0
0x04	CPPC_WRITE_REG	NORMAL_REQUEST	1.0
0x05	CPPC_GET_FAST_CHANNEL_REGION	NORMAL_REQUEST	1.0
0x06	CPPC_GET_FAST_CHANNEL_OFFSET	NORMAL_REQUEST	1.0
0x07	CPPC_GET_HART_LIST	NORMAL_REQUEST	1.0

4.6.1 CPPC Fast-channel

The CPPC service group defines the fast-channels to be used by the application processor to request performance changes and to obtain performance change feedback for an application processor from the platform microcontroller.

A fast-channel shared memory layout is specific to the CPPC service group. The data written in a fast-channel do not follow the conventional RPMI message format. The simple data format supported by the fast-channel allows faster processing of the performance change requests made through a fast-channel and faster read of the performance feedback values supported over the fast-channel.

The CPPC service group defines two types of fast-channel for each application processor. If fast-channels are supported then each application processor must be assigned both types fast-channel.

4.6.1.1 Performance Request Fast-channel

In this fast-channel the application processor will either write the desired performance level in case of normal mode or the minimum and maximum performance level in case of Autonomous (CPPC2) mode in the fast-channel. Otherwise the application processor can call the service CPPC_WRITE_REG for the DesiredPerformanceRegister or MinimumPerformanceRegister and MaximumPerformanceRegister.

The supported values in this fast-channel which depends on the CPPC mode, either normal or autonomous mode is discoverable through CPPC_GET_FAST_CHANNEL_REGION service.

The size of this fast-channel type is 8 bytes.

Table 65. CPPC Performance Request Fast-channel Layout

CPPC Mode	Layout
Normal Mode	| Offset | Value (32-bit) | | --- | --- | | 0x0 | Desired performance level. | | 0x4 | Reserved and must be 0. |
Autonomous (CPPC2) mode	| Offset | Value (32-bit) | | --- | --- | | 0x0 | Minimum performance level. | | 0x4 | Maximum performance level. |

4.6.1.2 Performance Feedback Fast-channel

In this fast-channel the application processor will read the supported value for estimating the delivered performance as performance feedback for an application processor. The application processor current frequency (Hz) is used for performance feedback in this fast-channel. The platform microcontroller must write the frequency of an application processor in the fast-channel whenever it changes.

The size of this fast-channel type is 8 bytes.

Table 66. CPPC Performance Feedback Fast-channel Layout

Offset	Value (32-bit)
0x0	Current frequency low 32-bit (Hz).
0x4	Current frequency high 32-bit (Hz).

4.6.1.3 CPPC Fast-channel Shared Memory Region

The size of the shared memory region containing all the fast-channels for all the managed application processors must be a power-of-2. The base-address and size (bytes) of this shared memory region can be discovered using the service CPPC_GET_FAST_CHANNEL_REGION. The base-address of the shared memory region must be aligned to 8 bytes which is maximum size of a fast-channel in both the types.

The offsets of fast-channels of both types for an application processor are aligned to 8 bytes. The offset of both fast-channel types in the shared memory region can be discovered through service CPPC_GET_FAST_CHANNEL_OFFSET. The offsets discovered can be added to the base-address of the shared memory region to form the address of Performance Request fast-channel and Performance Feedback fast-channel for an application processor.

4.6.1.4 Performance Request Fast-channel Doorbell

A doorbell can also be supported for this fast-channel type which is shared between all the application processors. The doorbell, if supported must be a memory mapped register with write access. The doorbell details and attributes such as doorbell register address, doorbell write value can be discovered by the application processor through the CPPC_GET_FAST_CHANNEL_REGION service.

The doorbell register address is the physical address of the register. The doorbell write value is the value which must be written in the doorbell register to trigger the doorbell interrupt.

The width of the doorbell write value must be equal to the doorbell register width.

note

The write value may also contains other set bits which must persist on every write to the doorbell register.

4.6.2 Notifications

This service group does not support any events for notification.

4.6.3 Service: CPPC_ENABLE_NOTIFICATION (SERVICE_ID: 0x01)

This service allows the application processor to subscribe to CPPC service group notifications. The platform may optionally support notifications for events that may occur. The platform microcontroller can send these notification messages to the application processor if they are implemented and the application processor has subscribed to them. The supported events are described in Section 4.6.2.

Refer to Table 8 for Request Data and Table 9 for Response Data.

4.6.4 Service: CPPC_PROBE_REG (SERVICE_ID: 0x02)

This service is used to probe a CPPC register implementation status for a application processor. If the CPPC register reg_id is implemented then the length in bits is returned in REG_LENGTH field. If the register is not supported or invalid then the REG_LENGTH will be 0.

Table 67. Request Data

Word	Name	Type	Description
0	REG_ID	uint32	CPPC register ID.
1	HART_ID	uint32	Hart ID.

Table 68. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | CPPC register probed successfully. | | RPMI_ERR_INVALID_PARAM | HART_ID or REG_ID is invalid. | | RPMI_ERR_NOT_SUPPORTED | REG_ID is not supported. | - Other errors Table 6.
1	REG_LENGTH	uint32	Register length (bits).

4.6.5 Service: CPPC_READ_REG (SERVICE_ID: 0x03)

This service is used to read a CPPC register. If the fast-channels are supported, a read of the DesiredPerformanceRegister or MinimumPerformanceRegister and MaximumPerformanceRegister through this service will return the current desired performance level or minimum and maximum performance level limit depending on the CPPC mode from the fast-channel of a application processor.

Table 69. Request Data

Word	Name	Type	Description
0	REG_ID	uint32	CPPC register ID.
1	HART_ID	uint32	Hart ID.

Table 70. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully. | | RPMI_ERR_INVALID_PARAM | HART_ID or REG_ID is invalid. | | RPMI_ERR_NOT_SUPPORTED | REG_ID is not supported. | - Other errors Table 6.
1	DATA_LOW	uint32	Lower 32-bit of the data.
2	DATA_HIGH	uint32	Upper 32-bit of data. This will be 0 if the register is of 32-bit length.

4.6.6 Service: CPPC_WRITE_REG (SERVICE_ID: 0x04)

This service is used to write a CPPC register.

If the fast-channels are supported the application processor must only write desired performance level in the fast-channel instead of writing into the DesiredPerformanceRegister through this service. Similarly, in case of the autonomous mode the application processor must write minimum and maximum limit levels into the fast-channel instead of calling this service for MinimumPerformanceRegister and MaximumPerformanceRegister. Otherwise the writes to these registers may be ignored.

Table 71. Request Data

Word	Name	Type	Description
0	REG_ID	uint32	CPPC register ID.
1	HART_ID	uint32	Hart ID.
2	DATA_LOW	uint32	Lower 32-bit of data.
3	DATA_HIGH	uint32	Upper 32-bit of data. This is ignored if the register is of 32-bit length.

Table 72. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully. | | RPMI_ERR_INVALID_PARAM | HART_ID or REG_ID is invalid. | | RPMI_ERR_NOT_SUPPORTED | REG_ID is not supported. | | RPMI_ERR_DENIED | REG_ID is read only. | - Other errors Table 6.

4.6.7 Service: CPPC_GET_FAST_CHANNEL_REGION (SERVICE_ID: 0x05)

This service is used to get the details of the shared memory region containing all the fast-channels, attributes of the fast-channel and the details of the doorbell if supported.

The doorbell details are unspecified and considered invalid if the Performance Request fast-channel doorbell (FLAGS[0] = 0) is not supported and must not be used.

Table 73. Request Data

NA

Table 74. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully. | | RPMI_ERR_NOT_SUPPORTED | Fast-channels not supported. | - Other errors Table 6.
1	FLAGS	uint32	| Bits | Description | | --- | --- | | [31:5] | Reserved and must be 0. | | [4:3] | CPPC mode. 0b00: Normal mode. Desired performance level for performance change. 0b01: Autonomous mode. Performance limit change. Platform can choose the level in the requested limit. 0b10 - 0b11: Reserved. | | [2:1] | Performance Request fast-channel doorbell register width. 0b00: 8-bit. 0b01: 16-bit. 0b10: 32-bit. 0b11: Reserved. | | [0] | Performance Request fast-channel doorbell support. 0b1: Supported. 0b0: Not supported. |
2	REGION_ADDR_LOW	uint32	Lower 32-bit of the fast-channels shared memory region physical address.
3	REGION_ADDR_HIGH	uint32	Upper 32-bit of the fast-channels shared memory region physical address.
4	REGION_SIZE_LOW	uint32	Lower 32-bit of the fast-channels shared memory region size.
5	REGION_SIZE_HIGH	uint32	Upper 32-bit of the fast-channels shared memory region size.
6	DB_ADDR_LOW	uint32	Lower 32-bit of doorbell register address for Performance Request fast-channel.
7	DB_ADDR_HIGH	uint32	Upper 32-bit of doorbell register address for Performance Request fast-channel.
8	DB_WRITE_VALUE	uint32	If the doorbell register width is less than 32-bit, the lower bits in this field equal to the doorbell register width must be used as write value.

4.6.8 Service: CPPC_GET_FAST_CHANNEL_OFFSET (SERVICE_ID: 0x06)

This service is used to get the offsets of Performance Request fast-channel and Performance Feedback fast-channel for an application processor in the shared memory region containing all the fast-channels.

Table 75. Request Data

Word	Name	Type	Description
0	HART_ID	uint32	Hart ID.

Table 76. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully. | | RPMI_ERR_INVALID_PARAM | HART_ID is invalid. | | RPMI_ERR_NOT_SUPPORTED | Fast-channels not supported. | - Other errors Table 6.
1	PERF_REQUEST_OFFSET_LOW	uint32	Lower 32-bit of a Performance Request fast-channel offset.
2	PERF_REQUEST_OFFSET_HIGH	uint32	Upper 32-bit of a Performance Request fast-channel offset.
3	PERF_FEEDBACK_OFFSET_LOW	uint32	Lower 32-bit of a Performance Feedback fast-channel offset.
4	PERF_FEEDBACK_OFFSET_HIGH	uint32	Upper 32-bit of a Performance Feedback fast-channel offset.

4.6.9 Service: CPPC_GET_HART_LIST (SERVICE_ID: 0x07)

This service retrieves the list of Hart IDs managed by this service group for performance control.

If the number of words required for all available Hart IDs exceeds the number of words that can be returned in one acknowledgement message then the platform microcontroller will set the REMAINING and RETURNED fields accordingly and only return the Hart IDs which can be accommodated. The application processor may need to call this service again with the appropriate START_INDEX until the REMAINING field returns 0.

Table 77. Request Data

Word	Name	Type	Description
0	START_INDEX	uint32	Starting index of Hart ID.

Table 78. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully. | | RPMI_ERR_INVALID_PARAM | START_INDEX is invalid. | - Other errors Table 6.
1	REMAINING	uint32	Remaining number of Hart IDs to be returned.
2	RETURNED	uint32	Number of Hart IDs returned in this request.
3	HART_ID[N]	uint32	Hart IDs.

4.7 Service Group - VOLTAGE (SERVICEGROUP_ID: 0x0007)

This service group is used to control the voltage level of the voltage domains. A voltage domain is the logical grouping of one or more devices powered by a single controllable voltage source. A system may have multiple voltage domains and the services defined in this service group are used to manage and control the voltage levels of these voltage domains. Each voltage domain is identified by DOMAIN_ID which is a 32-bit integer starting from 0.

The following table lists the services in the VOLTAGE service group:

Table 79. VOLTAGE Services

Service ID	Service Name	Request Type	RPMI Version
0x01	VOLT_ENABLE_NOTIFICATION	NORMAL_REQUEST	1.0
0x02	VOLT_GET_NUM_DOMAINS	NORMAL_REQUEST	1.0
0x03	VOLT_GET_ATTRIBUTES	NORMAL_REQUEST	1.0
0x04	VOLT_GET_SUPPORTED_LEVELS	NORMAL_REQUEST	1.0
0x05	VOLT_SET_CONFIG	NORMAL_REQUEST	1.0
0x06	VOLT_GET_CONFIG	NORMAL_REQUEST	1.0
0x07	VOLT_SET_LEVEL	NORMAL_REQUEST	1.0
0x08	VOLT_GET_LEVEL	NORMAL_REQUEST	1.0

4.7.1 Voltage Level Format

There are two types of voltage level formats supported in the VOLTAGE service group. The voltage levels are represented as a group.

4.7.1.1 Discrete Format

A set of discrete voltage levels arranged in a sequence, starting from the lowest value at the lowest index and increasing sequentially to higher levels. The following table shows the structure of the discrete format.

[voltage0, voltage1, voltage2, ... , voltage(N-1)]

where:
voltage0 \< voltage1 \< voltage2 \< ... \< voltage(N-1)

Word	Name	Description
0	VOLTAGE	Discrete voltage level in microvolts (uV).

4.7.1.2 Linear Range Format

A linear range of voltage levels with a constant step size. The following table shows the structure of the linear range voltage format.

[voltage_min, voltage_max, voltage_step]

Multi-linear range format can be supported by having multiple linear range tuple arranged in an continuous array format.

[voltage_min0, voltage_max0, voltage_step0],
[voltage_min1, voltage_max1, voltage_step1],
...
[voltage_min(N-1), voltage_max(N-1), voltage_step(N-1)],

The format must be packed sequentially such that voltage_max0 \< voltage_min1, voltage_max1 \< voltage_min2 and so on.

Each linear range is considered as a single voltage level.

Word	Name	Description
0	VOLTAGE_MIN	Lower boundary of voltage level in microvolts (uV).
1	VOLTAGE_MAX	Upper boundary of voltage level in microvolts (uV).
2	STEP	Step size in microvolts (uV).

4.7.2 Notifications

This service group does not support any events for notification.

4.7.3 Service: VOLT_ENABLE_NOTIFICATION (SERVICE_ID: 0x01)

This service allows the application processor to subscribe to VOLTAGE service group notifications. The platform may optionally support notifications for events that may occur. The platform microcontroller can send these notification messages to the application processor if they are implemented and the application processor has subscribed to them. The supported events are described in Section 4.7.2.

Refer to Table 8 for Request Data and Table 9 for Response Data.

4.7.4 Service: VOLT_GET_NUM_DOMAINS (SERVICE_ID: 0x02)

This service is used to query the number of voltage domains available in the system.

Table 80. Request Data

NA

Table 81. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully. | - Other errors Table 6.
1	NUM_DOMAINS	uint32	Number of voltage domains.

4.7.5 Service: VOLT_GET_ATTRIBUTES (SERVICE_ID: 0x03)

Each domain may support multiple voltage levels, which are permitted by the domain for operation. The number of levels indicates the total count of voltage levels supported within a voltage domain. Transition latency denotes the maximum time required for the voltage to stabilize upon a change in the regulator. The FLAGS field encodes the voltage format supported by the hardware, including discrete and linear range formats." The NUM_LEVELS field returns the number of discrete voltage in case discrete format and number of linear range tuple in linear range voltage format. Each domain can support only one voltage level format. Additional voltage formats can be accommodated in the future if required.

Table 82. Request Data

Word	Name	Type	Description
0	DOMAIN_ID	uint32	Voltage domain ID.

Table 83. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully. | | RPMI_ERR_INVALID_PARAM | DOMAIN_ID is invalid. | - Other errors Table 6.
1	FLAGS	uint32	| Bits | Description | | --- | --- | | [31:4] | Reserved and must be 0. | | [3:1] | Refer to Section 4.7.1 for more details. 0b000: Discrete format. 0b001: Linear range format. 0b010 - 0b111: Reserved. | | [0] | Voltage domain control support. 0b0: Voltage domain can be enabled/disabled. 0b1: Voltage domain is always-on, voltage value can be changed in the supported voltage range. |
2	NUM_LEVELS	uint32	The number of voltage levels (number of arrays) supported by the domain. If the voltage level format is a linear range, then each linear range is considered a single voltage level.
3	TRANS_LATENCY	uint32	Transition latency, in microsecond (us).
4:7	DOMAIN_NAME	uint8[16]	Voltage domain name, a NULL-terminated ASCII string up to 16-bytes.

4.7.6 Service: VOLT_GET_SUPPORTED_LEVELS (SERVICE_ID: 0x04)

Each domain may support multiple voltage levels which are allowed by the domain to operate. The number of voltage levels returned depends on the format of the voltage level.

The total number of words required to represent the voltage levels in one message cannot exceed the total words available in one message DATA field. If the number of levels exceeds this limit, the platform microcontroller will return the maximum number of levels that can be accommodated in one message and adjust the REMAINING field accordingly. When the REMAINING field is not zero, the application processor must make subsequent service calls with the appropriate VOLTAGE_LEVEL_INDEX set to retrieve the remaining voltage levels. It is possible that multiple service calls may be necessary to retrieve all the voltage levels.

Table 84. Request Data

Word	Name	Type	Description
0	DOMAIN_ID	uint32	Voltage domain ID.
1	VOLTAGE_LEVEL_INDEX	uint32	The index of discrete voltage if the format is discrete, or index of linear range tuple if the format is linear range.

Table 85. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully and voltage levels returned. | | RPMI_ERR_INVALID_PARAM | Voltage DOMAIN_ID is invalid. | | RPMI_ERR_INVALID_PARAM | VOLTAGE_LEVEL_INDEX is invalid. | - Other errors Table 6.
1	FLAGS	uint32	Reserved and must be 0.
2	REMAINING	uint32	The remaining number of discrete voltage if the format is discrete type, or number of linear range tuple if the format is linear range.
3	RETURNED	uint32	The number of discrete voltage levels returned if the format is discrete type, or the number of linear range tuple if the format is linear range.
4	VOLTAGE_LEVEL[]	uint32[]	The voltage format data structure and its packing is according to the supported format. Refer to Section 4.7.1 for more details.

4.7.7 Service: VOLT_SET_CONFIG (SERVICE_ID: 0x05)

This service is used to configure a voltage domain.

Table 86. Request Data

Word	Name	Type	Description
0	DOMAIN_ID	uint32	Voltage domain ID.
1	CONFIG	uint32	Voltage domain config. | Bits | Description | | --- | --- | | [31:1] | Reserved and must be 0. | | [0] | Voltage supply control. 0b1: Enable voltage supply. 0b0: Disable voltage supply. |

Table 87. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully. | | RPMI_ERR_INVALID_PARAM | Voltage DOMAIN_ID or CONFIG is invalid. | - Other errors Table 6.

4.7.8 Service: VOLT_GET_CONFIG (SERVICE_ID: 0x06)

This service is used to get the configuration of a voltage domain.

Table 88. Request Data

Word	Name	Type	Description
0	DOMAIN_ID	uint32	Voltage domain ID.

Table 89. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully. | | RPMI_ERR_INVALID_PARAM | Voltage DOMAIN_ID not found. | - Other errors Table 6.
1	CONFIG	uint32	Voltage domain config. | Bits | Description | | --- | --- | | [31:1] | Reserved and must be 0. | | [0] | Voltage supply state. 0b1: Voltage supply is enabled. 0b0: Voltage supply is disabled. |

4.7.9 Service: VOLT_SET_LEVEL (SERVICE_ID: 0x07)

This service is used to set the voltage level in microvolts of a voltage domain.

Table 90. Request Data

Word	Name	Type	Description
0	DOMAIN_ID	uint32	Voltage domain ID.
1	VOLTAGE_LEVEL	int32	Voltage level, in microvolts.

Table 91. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully. | | RPMI_ERR_INVALID_PARAM | Voltage DOMAIN_ID or VOLTAGE_LEVEL is invalid. | - Other errors Table 6.

4.7.10 Service: VOLT_GET_LEVEL (SERVICE_ID: 0x08)

This service is used to get the current voltage level in microvolts of a voltage domain.

Table 92. Request Data

Word	Name	Type	Description
0	DOMAIN_ID	uint32	Voltage domain ID.

Table 93. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully. | | RPMI_ERR_INVALID_PARAM | Voltage DOMAIN_ID not found. | - Other errors Table 6.
1	VOLTAGE_LEVEL	int32	Voltage level, in microvolts.

4.8 Service Group - CLOCK (SERVICEGROUP_ID: 0x0008)

This service group is used to manage system clocks. Services defined in this group are used to enable or disable clocks, set or get clock rates, etc.

Each clock in the system is identified by a clock ID, which is a 32-bit integer identifier assigned to each clock. The mapping of CLOCK_ID to clock is known to both the application processor and the platform microcontroller. Clock IDs are sequential and start from 0.

A device or a group of devices sharing the same clock source form a single clock domain identified by the CLOCK_ID. Any change to the clock source affects the entire domain, which may include multiple devices.

The topology of the devices and the clock source depends on the system design and is implementation specific. The operating system can discover this topology through supported hardware description mechanisms.

The following table lists the services in the CLOCK service group:

Table 94. CLOCK Services

Service ID	Service Name	Request Type	RPMI Version
0x01	CLK_ENABLE_NOTIFICATION	NORMAL_REQUEST	1.0
0x02	CLK_GET_NUM_CLOCKS	NORMAL_REQUEST	1.0
0x03	CLK_GET_ATTRIBUTES	NORMAL_REQUEST	1.0
0x04	CLK_GET_SUPPORTED_RATES	NORMAL_REQUEST	1.0
0x05	CLK_SET_CONFIG	NORMAL_REQUEST	1.0
0x06	CLK_GET_CONFIG	NORMAL_REQUEST	1.0
0x07	CLK_SET_RATE	NORMAL_REQUEST	1.0
0x08	CLK_GET_RATE	NORMAL_REQUEST	1.0

4.8.1 Clock Rate Format

Each clock rate is a array of two 32-bit values (uint32, uint32) represented as (clock_rate_low, clock_rate_high) and packed in the same order where clock_rate_low is at the lower index than the clock_rate_high.

4.8.1.1 Discrete Format

A set of discrete clock rates arranged in a sequence, starting from the lowest value at the lowest index and increasing sequentially to higher clock rate. The following table shows the structure of the discrete clock rate format.

[clock_rate0, clock_rate1, clock_rate2, ... , clock_rate(N-1)]

where:
clock_rate0 \< clock_rate1 \< clock_rate2 \< ... \< clock_rate(N-1)

Table 95. Discrete Clock Format Structure

Word	Name	Description
0	CLOCK_RATE_LOW	Lower 32-bit clock rate in Hz.
1	CLOCK_RATE_HIGH	Upper 32-bit clock rate in Hz.

4.8.1.2 Linear Range Format

A linear range of clock rates represented by minimum and maximum clock rate and a constant step size. The following table shows the fixed structure of the linear range format for clock rates.

[clock_rate_min, clock_rate_max, clock_step]

Table 96. Linear Range Format Structure

Word	Name	Description
0	CLOCK_MIN_RATE_LOW	Lower 32-bit of the lowest clock rate in Hz.
1	CLOCK_MIN_RATE_HIGH	Upper 32-bit of the lowest clock rate in Hz.
2	CLOCK_MAX_RATE_LOW	Lower 32-bit of the highest clock rate in Hz.
3	CLOCK_MAX_RATE_HIGH	Upper 32-bit of the highest clock rate in Hz.
4	CLOCK_STEP_LOW	Lower 32-bit of the step between two successive rates in Hz.
5	CLOCK_STEP_HIGH	Upper 32-bit of the step between two successive rates in Hz.

A clock may also support clock rates which can be represented by multiple linear ranges. For example,

[clock_rate_min0, clock_rate_max0, clock_rate_step0],
[clock_rate_min1, clock_rate_max1, clock_rate_step1],
 ...,
[clock_rate_min(N-1), clock_rate_max(N-1), clock_rate_step(N-1)]

The linear ranges must be packed sequentially such that clock_rate_max0 \< clock_rate_min1, clock_rate_max1 \< clock_rate_min2 and so on.

4.8.2 Notifications

This service group does not support any events for notification.

4.8.3 Service: CLK_ENABLE_NOTIFICATION (SERVICE_ID: 0x01)

This service allows the application processor to subscribe to CLOCK service group notifications. The platform may optionally support notifications for events that may occur. The platform microcontroller can send these notification messages to the application processor if they are implemented and the application processor has subscribed to them. The supported events are described in Section 4.8.2.

Refer to Table 8 for Request Data and Table 9 for Response Data.

4.8.4 Service: CLK_GET_NUM_CLOCKS (SERVICE_ID: 0x02)

This service is used to query the number of clocks available in the system. All supported clocks in the system are designated by an integer identifier called CLOCK_ID.

Table 97. Request Data

NA

Table 98. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully. | - Other errors Table 6.
1	NUM_CLOCKS	uint32	Number of clocks.

4.8.5 Service: CLK_GET_ATTRIBUTES (SERVICE_ID: 0x03)

This service provides detailed attributes of a clock, including its name, represented as a 16-byte array of ASCII strings. It also specifies the transition latency, which denotes the maximum time for the clock to stabilize after a configuration change. The FLAGS field encodes the clock formats supported by the clock. When the format is of the discrete type, the NUM_RATES field returns the number of discrete clock rates supported by the clock. In the case of linear range format the NUM_RATES will return the number of linear ranges supported.

Table 99. Request Data

Word	Name	Type	Description
0	CLOCK_ID	uint32	Clock ID.

Table 100. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully. | | RPMI_ERR_INVALID_PARAM | CLOCK_ID is invalid. | - Other errors Table 6.
1	FLAGS	uint32	| Bits | Description | | --- | --- | | [31:2] | Reserved and must be 0. | | [1:0] | Clock format. Refer to Section 4.8.1 for more details. 0b00: Discrete format. 0b01: Linear range format. 0b10 - 0b11: Reserved. |
2	NUM_RATES	uint32	The number of discrete clock rates if the format is of discrete type, or the number of linear ranges if the format is linear range.
3	TRANSITION_LATENCY	uint32	Transition latency, in microseconds (us).
4:7	CLOCK_NAME	uint8[16]	Clock name, a NULL-terminated ASCII string up to 16-bytes.

4.8.6 Service: CLK_GET_SUPPORTED_RATES (SERVICE_ID: 0x04)

This service is used to get the supported clock rates. The clock rate data returned by this service depends on the format supported by the clock.

If the format is discrete, the message can pass the CLOCK_RATE_INDEX which is the index to the first rate value to be described in the returned rate array. If all supported rate values are required then this index value can be 0. Similarly, if the format is linear range, then the CLOCK_RATE_INDEX is the index of the first linear range to be described in the returned clock rate linear ranges. If all the supported linear ranges are needed then this index value can be 0.

The total number of words required for the number of discrete clock rates or linear ranges according to the format in one message must not exceed the total words available in a message DATA field. If the format is linear range and a clock supports multiple linear ranges, then only complete linear ranges must be returned as per the data format of the linear range described in Section 4.8.1.2.

If the total number of words required to store all supported discrete clock rates or the linear ranges exceed the available words in message DATA field then REMAINING and RETURNED must be set accordingly. In such condition, if the format is discrete, the platform microcontroller will return the discrete clock rates which can be accommodated in one message and set the RETURNED field to number of discrete clock rates returned and REMAINING field is set to the remaining number of discrete clock rates. Similarly if the format is linear, the linear ranges which can be accommodated in one message are returned with RETURNED field set to the number of linear ranges returned and REMAINING field is set to the remaining number of linear ranges.

The application processor, when REMAINING field is not 0 must call this service again with appropriate CLOCK_RATE_INDEX set to get the remaining discrete clock rates or linear ranges.

Table 101. Request Data

Word	Name	Type	Description
0	CLOCK_ID	uint32	Clock ID.
1	CLOCK_RATE_INDEX	uint32	Clock rate index.

Table 102. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully. | | RPMI_ERR_INVALID_PARAM | CLOCK_ID or CLOCK_RATE_INDEX is invalid. | - Other errors Table 6.
1	FLAGS	uint32	Reserved and must be 0.
2	REMAINING	uint32	The remaining number of discrete clock rates if the format is discrete type, or the remaining number of linear ranges if the format is linear range.
3	RETURNED	uint32	The number of discrete clock rates returned if the format is discrete type, or the number of linear ranges returned if the format is linear range.
4	CLOCK_RATE[ ]	uint32[2]	The clock rate data structure and its packing is according to the supported format. Refer to Section 4.8.1 for more details.

4.8.7 Service: CLK_SET_CONFIG (SERVICE_ID: 0x05)

This service is used to configure a clock domain.

Table 103. Request Data

Word	Name	Type	Description
0	CLOCK_ID	uint32	Clock ID.
1	CONFIG	uint32	Clock config. | Bits | Description | | --- | --- | | [31:1] | Reserved and must be 0. | | [0] | Clock control. 0b0: Disable clock. 0b1: Enable clock. |

Table 104. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully. | | RPMI_ERR_INVALID_PARAM | CLOCK_ID or CONFIG is invalid. | - Other errors Table 6.

4.8.8 Service: CLK_GET_CONFIG (SERVICE_ID: 0x06)

This service is used to get the configuration of a clock domain.

Table 105. Request Data

Word	Name	Type	Description
0	CLOCK_ID	uint32	Clock ID.

Table 106. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully. | | RPMI_ERR_INVALID_PARAM | CLOCK_ID is invalid. | - Other errors Table 6
1	CONFIG	uint32	Clock config. | Bits | Description | | --- | --- | | [31:1] | Reserved and must be 0. | | [0] | Clock state. 0b0: Clock is disabled. 0b1: Clock is enabled. |

4.8.9 Service: CLK_SET_RATE (SERVICE_ID: 0x07)

This service is used to set the clock rate of a specific clock.

Table 107. Request Data

Word	Name	Type	Description
0	CLOCK_ID	uint32	Clock ID.
1	FLAGS	uint32	| Bits | Description | | --- | --- | | [31:2] | Reserved and must be 0. | | [1:0] | Clock rate rounding mode. 0b00: Round down. 0b01: Round up. 0b10: Auto. 0b11: Reserved. In Auto mode the platform can autonomously chooses a supported rate closest to the requested rate. |
2	CLOCK_RATE_LOW	uint32	Lower 32-bit of the clock rate in Hertz.
3	CLOCK_RATE_HIGH	uint32	Upper 32-bit of the clock rate in Hertz.

Table 108. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully. | | RPMI_ERR_INVALID_PARAM | CLOCK_ID or clock rate is invalid or the flags passed are invalid or reserved. | - Other errors Table 6.

4.8.10 Service: CLK_GET_RATE (SERVICE_ID: 0x08)

This service is used to get the current clock rate.

Table 109. Request Data

Word	Name	Type	Description
0	CLOCK_ID	uint32	Clock ID.

Table 110. Request Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully. | | RPMI_ERR_INVALID_PARAM | CLOCK_ID is invalid. | - Other errors Table 6.
1	CLOCK_RATE_LOW	uint32	Lower 32-bit of the clock rate in Hertz.
2	CLOCK_RATE_HIGH	uint32	Upper 32-bit of the clock rate in Hertz.

4.9 Service Group - DEVICE_POWER (SERVICEGROUP_ID: 0x0009)

This DEVICE_POWER service group provides messages to manage the power states of a device power domain. This service group is used only for device power management since system and CPU power management is handled by already defined service groups such as SYSTEM_RESET, SYSTEM_SUSPEND and HART_STATE_MANAGEMENT.

A domain can consist of one device if its power states can be controlled independently or it may also have multiple devices if they all share the same power control lines and power states can only be changed collectively. Each domain must support ON and OFF states along with custom power states which are discoverable. Domains may also have power states which may preserve the context. The level of context preserved will depends on the level of power state.

Power states for domains will be discovered via supported hardware description mechanisms where the values for ON and OFF are already fixed and known. The power state encodes both the power state value and the context preserved or lost information corresponding to that state.

The DEVICE_POWER services take a 32-bit integer identifier known as DOMAIN_ID to specify the device power domain. These DOMAIN_ID identifiers are sequential and start from 0.

The following table lists the services in the DEVICE_POWER service group:

Table 111. DEVICE_POWER Services

Service ID	Service Name	Request Type	RPMI Version
0x01	DPWR_ENABLE_NOTIFICATION	NORMAL_REQUEST	1.0
0x02	DPWR_GET_NUM_DOMAINS	NORMAL_REQUEST	1.0
0x03	DPWR_GET_ATTRIBUTES	NORMAL_REQUEST	1.0
0x04	DPWR_SET_STATE	NORMAL_REQUEST	1.0
0x05	DPWR_GET_STATE	NORMAL_REQUEST	1.0

4.9.1 Power State Format

The power state is represented as a 32-bit value. The following table shows the encoding for the power state.

Table 112. Power State Encoding

Bit	Name	Description
[31:17]	RESERVED	Reserved and must be 0.
[16]	CONTEXT	0b1: Context is lost. 0b0: Context is preserved.
[15:0]	VALUE	| Value | Description | | --- | --- | | 0x0000 | On. | | 0x0001 | Reserved and must be 0. | | 0x0002 | Reserved and must be 0. | | 0x0003 | Off. | | 0x0004 - 0x0FFF | Reserved and must be 0. | | 0x1000 - 0xFFFF | Vendor specific states. |

4.9.2 Notifications

This service group does not support any events for notification.

4.9.3 Service: DPWR_ENABLE_NOTIFICATION (SERVICE_ID: 0x01)

This service allows the application processor to subscribe to DEVICE_POWER service group notifications. The platform may optionally support notifications for events that may occur. The platform microcontroller can send these notification messages to the application processor if they are implemented and the application processor has subscribed to them. The supported events are described in Section 4.9.2.

Refer to Table 8 for Request Data and Table 9 for Response Data.

4.9.4 Service: DPWR_GET_NUM_DOMAINS (SERVICE_ID: 0x02)

This service is used to query the number of device power domains available which can be controlled by the client. The number of domains returned may be less than the actual number of domains present on the platform.

Table 113. Request Data

NA

Table 114. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully. | - Other errors Table 6.
1	NUM_DOMAINS	uint32	Number of device power domains.

4.9.5 Service: DPWR_GET_ATTRIBUTES (SERVICE_ID: 0x03)

This service is used to query the attributes of a device power domain.

Table 115. Request Data

Word	Name	Type	Description
0	DOMAIN_ID	uint32	Device power domain ID.

Table 116. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully. | | RPMI_ERR_INVALID_PARAM | DOMAIN_ID is invalid. | - Other errors Table 6.
1	FLAGS	uint32	Reserved and must be 0.
2	TRANSITION_LATENCY	uint32	Worst case transition latency of domain from one power state to another, in microseconds (us).
3:6	DOMAIN_NAME	uint8[16]	Device power domain name, a NULL-terminated ASCII string up to 16-bytes.

4.9.6 Service: DPWR_SET_STATE (SERVICE_ID: 0x04)

This service is used to change the power state of a device power domain.

Table 117. Request Data

Word	Name	Type	Description
0	DOMAIN_ID	uint32	Device power domain ID.
1	POWER_STATE	uint32	This field indicates the power state to which the power domain should transition. The specific power states and their meanings may vary depending on the implementation, but generally, they include values such as "ON", "OFF" and vendor specific power state. Refer Section 4.9.1 for more details.

Table 118. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully. | | RPMI_ERR_INVALID_PARAM | DOMAIN_ID or POWER_STATE is invalid. | | RPMI_ERR_DENIED | Denied due to no permission. | | RPMI_ERR_HW_FAULT | Failed due to hardware error. | - Other errors Table 6.

4.9.7 Service: DPWR_GET_STATE (SERVICE_ID: 0x05)

This service is used to get the current power state of a device power domain.

Table 119. Request Data

Word	Name	Type	Description
0	DOMAIN_ID	uint32	Device power domain ID.

Table 120. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully. | | RPMI_ERR_INVALID_PARAM | DOMAIN_ID is invalid. | - Other errors Table 6.
1	POWER_STATE	uint32	This field indicates the current power state of the specified domain. The power state can be one of several predefined values, such as ON, OFF, or vendor specific implementation. Refer Section 4.9.1 for more details.

4.10 Service Group - PERFORMANCE (SERVICEGROUP_ID: 0x000A)

This PERFORMANCE service group is used to manage the performance of a group of devices or application processors that operate in the same performance domain. Unlike traditional performance control mechanisms, where the OS is responsible for directly controlling voltages and clocks, this mechanism instead operates on an metric less integer performance scale. Each integer value on this scale represents a performance operating point. What this scale represents and the metric is entirely platform-dependent. Values on this scale are represented with performance level index, and the platform has complete control over mapping these performance operating points to performance states, which are eventually converted into hardware parameters such as voltage and frequency. The level index does not need to be contiguous or to be on a linear scale. For example, the mapping between levels index and frequencies can be as straightforward as using a multiplication factor of 1000 or ascending index number starting from 0.

The CPPC service group is designed for performance control, but it is only intended for application processors. This service group is primarily meant for devices such as GPUs and accelerators, though it can also be used for application processors.

It is important to distinguish between performance domains and power domains. A performance domain refers to a set of devices that must always operate at the same performance level, whereas a power domain refers to a set of devices that can be turned on or off together for power management purposes.

The following table lists the services in the PERFORMANCE service group:

Table 121. PERFORMANCE Services

Service ID	Service Name	Request Type	RPMI Version
0x01	PERF_ENABLE_NOTIFICATION	NORMAL_REQUEST	1.0
0x02	PERF_GET_NUM_DOMAINS	NORMAL_REQUEST	1.0
0x03	PERF_GET_ATTRIBUTES	NORMAL_REQUEST	1.0
0x04	PERF_GET_SUPPORTED_LEVELS	NORMAL_REQUEST	1.0
0x05	PERF_GET_LEVEL	NORMAL_REQUEST	1.0
0x06	PERF_SET_LEVEL	NORMAL_REQUEST	1.0
0x07	PERF_GET_LIMIT	NORMAL_REQUEST	1.0
0x08	PERF_SET_LIMIT	NORMAL_REQUEST	1.0
0x09	PERF_GET_FAST_CHANNEL_REGION	NORMAL_REQUEST	1.0
0x0A	PERF_GET_FAST_CHANNEL_ATTRIBUTES	NORMAL_REQUEST	1.0

4.10.1 Performance Level Attribute

The following table shows the structure of a single performance level and its' attribute.

Table 122. Performance Level Attributes Structure

Word	Name	Description
0	INDEX	Performance Level Index
1	CLOCK_FREQ	Clock frequency (kHz).
2	POWER_COST	Power cost (uW).
3	TRANSITION_LATENCY	Transition latency (us).

4.10.2 Performance Fast-channel

This section provides an overview of the properties associated with the fast-channel for PERFORMANCE service group.

Supported Services The fast-channel currently supports only the following PERFORMANCE services:

Platform Dependency

Performance Fast-channel Shared Memory Region

Discovering Fast-channel

Doorbell Support

Payload Requirements

4.10.3 Notifications

When a client registers for performance change notifications, the platform will send notification to the client whenever there is a change in the performance level, performance limit or the performance power of a specific performance domain. This notification is typically sent by the platform microcontroller to inform clients in the system about changes in the performance domain.

Table 123. Performance Notification Events

Event ID	Name	Event Data	Description
0x01	PERF_POWER_CHANGE	| Word | Type | Description | | --- | --- | --- | | 0 | uint32 | Performance domain ID for which the power has changed. | | 1 | uint32 | New power value (uW). |	Performance power changed notification.
0x02	PERF_LIMIT_CHANGE	| Word | Type | Description | | --- | --- | --- | | 0 | uint32 | Performance domain ID for which the performance limit has changed. | | 1 | uint32 | New maximum performance level. | | 2 | uint32 | New minimum performance level. |	Performance limit changed notification.
0x03	PERF_LEVEL_CHANGE	| Word | Type | Description | | --- | --- | --- | | 0 | uint32 | Performance domain ID for which the performance level has changed. | | 1 | uint32 | New performance level. |	Performance level changed notification.

4.10.4 Service: PERF_ENABLE_NOTIFICATION (SERVICE_ID: 0x01)

This service allows the application processor to subscribe to PERFORMANCE service group notifications. The platform may optionally support notifications for events that may occur. The platform microcontroller can send these notification messages to the application processor if they are implemented and the application processor has subscribed to them. The supported events are described in Section 4.10.3.

Refer to Table 8 for Request Data and Table 9 for Response Data.

4.10.5 Service: PERF_GET_NUM_DOMAINS (SERVICE_ID: 0x02)

This service returns the number of performance domains supported by the system. The number of performance domains may vary depending on the hardware platform and its implementation. In general, performance domains are used to group related hardware components, such as CPUs, GPUs, memory, and peripherals, into separate domains that can be independently controlled and managed. This allows for more fine-grained control over the performance of specific components, which can be important for optimizing system performance and power consumption.

Table 124. Request Data

NA

Table 125. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully. | - Other errors Table 6.
1	NUM_DOMAINS	uint32	Number of performance domains.

4.10.6 Service: PERF_GET_ATTRIBUTES (SERVICE_ID: 0x03)

This service is used to retrieve the attributes of a specific performance domain. These attributes provide information about the performance capabilities and constraints of the domain, such as the performance limit and performance level.

Table 126. Request Data

Word	Name	Type	Description
0	DOMAIN_ID	uint32	Performance domain ID.

Table 127. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully. | | RPMI_ERR_INVALID_PARAM | DOMAIN_ID is invalid. | - Other errors Table 6.
1	FLAGS	uint32	| Bits | Description | | --- | --- | | [31:3] | Reserved and must be 0. | | [2] | Performance limit change support. This attribute indicates whether the platform allows software to set the performance limit for a specific performance domain. 0b0: Performance limit change is not allowed. 0b1: Performance limit change is allowed. | | [1] | Performance level change support. This attribute indicates whether the platform allows software to set the performance level for a specific performance domain. 0b0: Performance level change is not allowed. 0b1: Performance level change is allowed. | | [0] | Fast-channel support. This attribute indicates whether the platform supports fast-channel for a specific performance domain. 0b0: Fast-channel is not supported. 0b1: Fast-channel is supported. |
2	NUM_LEVELS	uint32	The total number of supported performance levels.
3	TRANSITION_LATENCY	uint32	Minimum amount of time that needs to pass between two consecutive requests, in microseconds (us).
4:7	DOMAIN_NAME	uint8[16]	Performance domain name, a NULL-terminated ASCII string up to 16-bytes.

4.10.7 Service: PERF_GET_SUPPORTED_LEVELS (SERVICE_ID: 0x04)

This service provides a list of the available performance levels or also called operating performance points (OPPs) for a specific performance domain. These represent different performance levels that can be set for the components in the domain, and are defined by a combination of frequency, power cost and other parameters. By using this information, the OS can select the optimal performance level based on the system’s workload and power constraints using performance level index returned in this service.

/* Pseudocode to retrieve the list of the supported performance levels. */

index = 0;
num = 0;
/* Allocate a buffer based on the value returned from the NUM_LEVELS */
total_num_levels = perf_domain_attributes.num_levels;

loop:
	list = get_domain_opp_list(index, domain_id);
	entry_num = 0;

	for (i = 0; i \< list.returned; i++, num++) {
		opp[num].index = list.entry[entry_num++];
		opp[num].freq = list.entry[entry_num++];
		opp[num].power = list.entry[entry_num++];
		opp[num].transition_latency = list.entry[entry_num++];
	}

	/* Check if there are remaining OPP to be read */
	if (list.remaining) {
		index += list.returned;
		goto loop;
	}

The pseudocode above demonstrates the process for retrieving the level information for a specific performance domain. First, the number of performance levels is determined by checking the NUM_LEVELS parameter returned by the PERF_GET_ATTRIBUTES service.

The total number of performance levels included in one message must not exceed the available word count in the message’s DATA field. If the performance levels exceed this limit, the platform microcontroller will return the number of levels that can be accommodated in one message and set the REMAINING field accordingly. When the REMAINING field is not zero, the application processor must call this service again with the appropriate PERF_LEVEL_INDEX to retrieve the remaining levels. Multiple service calls may be required to obtain all the levels.

Table 128. Request Data

Word	Name	Type	Description
0	DOMAIN_ID	uint32	Performance domain ID.
1	PERF_LEVEL_INDEX	uint32	Index of performance data array. The first index starts at zero.

Table 129. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully. | | RPMI_ERR_INVALID_PARAM | DOMAIN_ID or PERF_LEVEL_INDEX is invalid. | - Other errors Table 6.
1	FLAGS	uint32	Reserved and must be 0.
2	REMAINING	uint32	Remaining number of levels (number of arrays).
3	RETURNED	uint32	Number of levels returned (number of arrays).
4	LEVEL[]	uint32[4]	Refer to section-perf-attribute for the complete structure of performance level attributes.

4.10.8 Service: PERF_GET_LEVEL (SERVICE_ID: 0x05)

This service is used to obtain the current performance level index of a specific performance domain in the system.

Table 130. Request Data

Word	Name	Type	Description
0	DOMAIN_ID	uint32	Performance domain ID.

Table 131. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully. | | RPMI_ERR_INVALID_PARAM | DOMAIN_ID is invalid. | - Other errors Table 6.
1	LEVEL	uint32	Current performance level index of the domain.

4.10.9 Service: PERF_SET_LEVEL (SERVICE_ID: 0x06)

This service is used to set the current performance level index of a specific performance domain in the system.

Table 132. Request Data

Word	Name	Type	Description
0	DOMAIN_ID	uint32	Performance domain ID.
1	LEVEL	uint32	Performance level index.

Table 133. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully. | | RPMI_ERR_INVALID_PARAM | DOMAIN_ID or LEVEL is invalid. | | RPMI_ERR_DENIED | Denied due to no permission. | | RPMI_ERR_HW_FAULT | Operation failed due to hardware error. | - Other errors Table 6.

4.10.10 Service: PERF_GET_LIMIT (SERVICE_ID: 0x07)

This service is used to obtain the current performance limit of a specific performance domain in the system.

Table 134. Request Data

Word	Name	Type	Description
0	DOMAIN_ID	uint32	Performance domain ID.

Table 135. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully. | | RPMI_ERR_INVALID_PARAM | DOMAIN_ID is invalid. | - Other errors Table 6.
1	MAX_PERF_LEVEL	uint32	Maximum allowed performance level index.
2	MIN_PERF_LEVEL	uint32	Minimum allowed performance level index.

4.10.11 Service: PERF_SET_LIMIT (SERVICE_ID: 0x08)

This service is used to set the performance limit of a specific performance domain in the system. The platform must ensure that any subsequent calls to PERF_SET_LEVEL to adjust the performance level remain within the currently defined limits.

If the current performance level falls outside the newly defined minimum or maximum ranges, the platform will automatically adjust it to comply with the updated limits.

note

Examples:

• If the current performance level is below the new minimum limit, the platform will set it to the new minimum limit.
• If the current performance level exceeds the new maximum limit, the platform will set it to the new maximum limit.
• No adjustment is required if the current performance level is within the new limits.

If notifications are enabled, the platform will send an appropriate notification (e.g., PERF_LEVEL_CHANGE, PERF_POWER_CHANGE, etc.) to the application processor.

Table 136. Request Data

Word	Name	Type	Description
0	DOMAIN_ID	uint32	Performance domain ID.
1	MAX_PERF_LEVEL	uint32	Maximum allowed performance level index.
2	MIN_PERF_LEVEL	uint32	Minimum allowed performance level index.

Table 137. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully. | | RPMI_ERR_INVALID_PARAM | DOMAIN_ID or performance level is invalid. | | RPMI_ERR_NOT_SUPPORTED | Performance limit change is not allowed. | | RPMI_ERR_DENIED | Denied due to no permission. | | RPMI_ERR_HW_FAULT | Operation failed due to hardware error. | - Other errors Table 6.

4.10.12 Service: PERF_GET_FAST_CHANNEL_REGION (SERVICE_ID: 0x09)

This service retrieves the physical address of the fast-channel region used in the performance service group. The fast-channel region is grouped in a continuous block of memory to ease the configuration of memory region protection.

Table 138. Request Data

NA

Table 139. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully. | | RPMI_ERR_NOT_SUPPORTED | Fast-channel is not implemented. | - Other errors Table 6
1	REGION_PHYS_ADDR_LOW	uint32	Lower 32-bit of the fast-channels shared memory region physical address.
2	REGION_PHYS_ADDR_HIGH	uint32	Upper 32-bit of the fast-channels shared memory region physical address.
3	REGION_SIZE_LOW	uint32	Lower 32-bit of the fast-channels shared memory region size.
4	REGION_SIZE_HIGH	uint32	Upper 32-bit of the fast-channels shared memory region size.

4.10.13 Service: PERF_GET_FAST_CHANNEL_ATTRIBUTES (SERVICE_ID: 0x0A)

This service allows clients to query attributes of the fast-channel for a specific performance domain and performance service.

Table 140. Request Data

Word	Name	Type	Description
0	DOMAIN_ID	uint32	Performance domain ID.
1	SERVICE_ID	uint32	Performance Service ID. Refer service ID in Table 121.

Table 141. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully. | | RPMI_ERR_INVALID_PARAM | DOMAIN_ID is invalid. | | RPMI_ERR_NOT_SUPPORTED | Fast-channel is not implemented. | - Other errors Table 6.
1	FLAGS	uint32	| Bits | Description | | --- | --- | | [31:3] | Reserved and must be 0. | | [2:1] | Doorbell register width. This field is unused if doorbell is not supported. 0b00: 8-bit. 0b01: 16-bit. 0b10: 32-bit. 0b11: Reserved. | | [0] | Doorbell support. 0b0: Doorbell is not supported. 0b1: Doorbell is supported. |
2	FASTCHAN_OFFSET_LOW	uint32	Lower 32-bit offset of fast-channel physical address region.
3	FASTCHAN_OFFSET_HIGH	uint32	Upper 32-bit offset of fast-channel physical address region.
4	FASTCHAN_SIZE	uint32	The size of fast-channel physical address in bytes.
5	DB_ADDR_LOW	uint32	Lower 32-bit of doorbell register address for Performance Request fast-channel. This field is unused if the doorbell is not supported.
6	DB_ADDR_HIGH	uint32	Upper 32-bit of doorbell register address for Performance Request fast-channel. This field is unused if the doorbell is not supported.
7	DB_WRITE_VALUE	uint32	If the doorbell register width is less than 32-bit, the lower bits in this field equal to the doorbell register width must be used as write value.

4.11 Service Group - MANAGEMENT_MODE (SERVICEGROUP_ID: 0x000B)

This MANAGEMENT_MODE service group provides RPMI client a mechanism to invoke the Management Mode (MM) in a secure execution environment. For general background on Management Mode, refer to the Platform Initialization (PI) specifications [4], Volume 4: Management Mode Core Interface.

The Management Mode (MM) provides an environment for implementing OS agnostic MM services such as secure variable storage, and firmware updates in the platform firmware. The MANAGEMENT_MODE service group defines RPMI services for invoking an MM service synchronously where the MM_COMMUNICATE RPMI service is used as a synchronous call from the non-secure world to the secure world and the data exchanged with the MM service is passed via special Management Mode (MM) shared memory.

The following table lists the services in the MANAGEMENT_MODE service group:

Table 142. MANAGEMENT_MODE Services

Service ID	Service Name	Request Type	RPMI Version
0x01	MM_ENABLE_NOTIFICATION	NORMAL_REQUEST	1.0
0x02	MM_GET_ATTRIBUTES	NORMAL_REQUEST	1.0
0x03	MM_COMMUNICATE	NORMAL_REQUEST	1.0

4.11.1 Notifications

This service group does not support any events for notification.

4.11.2 Service: MM_ENABLE_NOTIFICATION (SERVICE_ID: 0x01)

This service allows the application processor to subscribe to MANAGEMENT_MODE service group notifications. The platform may optionally support notifications for events that may occur. The platform microcontroller can send these notification messages to the application processor if they are implemented and the application processor has subscribed to them. The supported events are described in Section 4.11.1.

Refer to Table 8 for Request Data and Table 9 for Response Data.

4.11.3 Service: MM_GET_ATTRIBUTES (SERVICE_ID: 0x02)

This RPMI service gets the attributes about Management Mode, including MM version, MM shared memory location, etc.

Table 143. Request Data

NA

Table 144. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully. | - Other errors Table 6.
1	MM_VERSION	uint32	Management Mode version. | Bits | Description | | --- | --- | | [31:16] | Major version. | | [15:0] | Minor version. |
2	MM_SHMEM_ADDR_LOW	uint32	Lower 32-bit of the MM shared memory physical address.
3	MM_SHMEM_ADDR_HIGH	uint32	Upper 32-bit of the MM shared memory physical address.
4	MM_SHMEM_SIZE	uint32	The size of MM shared memory in bytes.

4.11.4 Service: MM_COMMUNICATE (SERVICE_ID: 0x03)

The MM_COMMUNICATE service invokes an MM service implemented in the secure execution environment. The input data needed to identify and invoke the MM service is referred to as MM_COMM_INPUT_DATA whereas the output data returned by the MM service is referred to as MM_COMM_OUTPUT_DATA. The RPMI client in the non-secure execution environment provides the location of MM_COMM_INPUT_DATA and MM_COMM_OUTPUT_DATA in the MM shared memory as parameters of MM_COMMUNICATE service.

Table 145. Request Data

Word	Name	Type	Description
0	MM_COMM_INPUT_DATA_OFFSET	uint32	The offset in the MM shared memory where the input data is passed to the MM service.
1	MM_COMM_INPUT_DATA_SIZE	uint32	The size of the input data in the MM shared memory.
2	MM_COMM_OUTPUT_DATA_OFFSET	uint32	The offset in the MM shared memory where the output data will be written by the MM service.
3	MM_COMM_OUTPUT_DATA_SIZE	uint32	The maximum size of the output data which can be written by the MM service in the MM shared memory.

Table 146. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully. | | RPMI_ERR_INVALID_ADDR | Input data end (or Output data end) is outside MM shared memory. | | RPMI_ERR_DENIED | Denied due to no permission. | - Other errors Table 6.
1	MM_COMM_RETURN_DATA_SIZE	uint32	Actual size of the output data written by the MM service in the MM shared memory.

4.12 Service Group - RAS_AGENT (SERVICEGROUP_ID: 0x000C)

The RAS_AGENT service group provides services to enumerate various error sources in a system and to retrieve their descriptors.

Each error source in a system is assigned a unique 32-bit identification number, referred to as RAS_ERR_SRC_ID.

The following table lists the services in the RAS_AGENT service group:

Table 147. RAS Agent Services

Service ID	Service Name	Request Type	RPMI Version
0x01	RAS_ENABLE_NOTIFICATION	NORMAL_REQUEST	1.0
0x02	RAS_GET_NUM_ERR_SRCS	NORMAL_REQUEST	1.0
0x03	RAS_GET_ERR_SRCS_ID_LIST	NORMAL_REQUEST	1.0
0x04	RAS_GET_ERR_SRC_DESC	NORMAL_REQUEST	1.0

4.12.1 Error Source Descriptor Format

4.12.1.1 ACPI Systems

For systems that support ACPI/APEI, the format of the error source descriptor is as defined in ACPI specification v6.4 or above, (GHESv2) [3]. If the value of RAS_GET_ERR_SRC_DESC.FLAGS[3:0] is 0, it indicates that the error source descriptor format is GHESv2.

The RAS agent populates the error source descriptor fields according to the error source specified by RAS_ERR_SRC_ID.

note

The error source descriptor has an error_status_structure field which is a generic address structure (GAS) as defined in ACPI v6.4 (GHESv2) [3]. This field specifies the location of a register that contains the physical address of a block of memory that holds the error status data for the specified error source. This block of memory is referred to as error_status_block. The allocation of error_status_block is platform dependent and is done by the RAS agent. The physical address of error_status_block is stored in the error_status_structure field of the error source descriptor being returned.

4.12.1.2 Non-ACPI Systems

RAS is not standardized for non-ACPI systems. Such systems may define custom format for an error source descriptor. The type of custom error source descriptor format can be read from RAS_GET_ERR_SRC_DESC.FLAGS[3:0].

4.12.2 Notifications

This service group does not support any events for notification.

4.12.3 Service: RAS_ENABLE_NOTIFICATION (SERVICE_ID: 0x01)

This service allows the application processor to subscribe to RAS_AGENT service group notifications. The platform may optionally support notifications for events that may occur. The platform microcontroller can send these notification messages to the application processor if they are implemented and the application processor has subscribed to them. The supported events are described in Section 4.12.2.

Refer to Table 8 for Request Data and Table 9 for Response Data.

4.12.4 Service: RAS_GET_NUM_ERR_SRCS (SERVICE_ID: 0x02)

This service queries number of error sources available in the system.

Table 148. Request Data

NA

Table 149. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully and number of error sources returned as NUM_ERR_SRCS. | - Other errors Table 6.
1	NUM_ERR_SRCS	uint32	Number of error sources.

4.12.5 Service: RAS_GET_ERR_SRCS_ID_LIST (SERVICE_ID: 0x03)

This service returns a list of RAS_ERR_SRC_ID for all error sources present in the system. The RAS_ERR_SRC_ID can be used to get the associated descriptor of the error source.

Table 150. Request Data

Word	Name	Type	Description
0	START_INDEX	uint32	Starting index of RAS_ERR_SRC_ID list. 0 for the first call, subsequent calls will use the next index of the remaining items.

Table 151. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully and list of error sources returned. | | RPMI_ERR_INVALID_PARAM | START_INDEX is invalid. | - Other errors Table 6.
1	FLAGS	uint32	Reserved and must be 0.
2	REMAINING	uint32	Remaining number of error source IDs.
3	RETURNED	uint32	Number of error source IDs returned in this request.
4	RAS_ERR_SRC_ID[N]	uint32	An array of error source IDs where each entry in the array is a unique error source ID. N is equal to RETURNED number of error source IDs in this request.

4.12.6 Service: RAS_GET_ERR_SRC_DESC (SERVICE_ID: 0x04)

This service retrieves the error source descriptor of an error source specified by RAS_ERR_SRC_ID.

Word	Name	Type	Description
0	RAS_ERR_SRC_ID	uint32	Error source ID for which attributes are to be returned.
1	BYTE_OFFSET	uint32	Offset from which the descriptor is to be read. Offset 0 for the first call, subsequent byte offset of the remaining bytes.

Table 152. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully and partial/complete error source descriptor returned. | | RPMI_ERR_INVALID_PARAM | RAS_ERR_SRC_ID or BYTE_OFFSET is invalid. | - Other errors Table 6.
1	FLAGS	uint32	| Bits | Description | | --- | --- | | [31:4] | Reserved and must be 0. | | [3:0] | Format of the error source descriptor. 0b0000: GHESv2 format. 0b0001 - 0b1110: Reserved. 0b1111: Implementation specific. |
2	REMAINING	uint32	Remaining number of bytes to be read.
3	RETURNED	uint32	Number of bytes read in this request.
4	ERR_SRC_DESC[N]	uint8	Full or partial descriptor N is equal to the RETURNED bytes in this request.

4.13 Service Group - REQUEST_FORWARD (SERVICEGROUP_ID: 0x000D)

The REQUEST_FORWARD service group allows application processors to retrieve and process RPMI request messages which are forwarded by platform microcontroller from some other RPMI client. This service group also allows an SBI implementation to forward RPMI request messages from one system-level partition (or domain) to another using the SBI MPXY extension [1].

The platform microcontroller (or SBI implementation) should maintain a first-in first-out queue of forwarded RPMI request messages. The first (or oldest) forwarded RPMI request message in the queue is referred to as the current forwarded RPMI request message. The RPMI services defined by the REQUEST_FORWARD service group allow application processors to retrieve and process one forwarded RPMI request message at a time.

The Table 153 below lists the services defined by the REQUEST_FORWARD service group:

Table 153. Request Forward Services

Service ID	Service Name	Request Type	RPMI Version
0x01	REQFWD_ENABLE_NOTIFICATION	NORMAL_REQUEST	1.0
0x02	REQFWD_RETRIEVE_CURRENT_MESSAGE	NORMAL_REQUEST	1.0
0x03	REQFWD_COMPLETE_CURRENT_MESSAGE	NORMAL_REQUEST	1.0

4.13.1 Notifications

The Table 154 below lists the notification events defined by the REQUEST_FORWARD service group.

Table 154. Request Forward Notification Events

Event ID	Name	Event Data	Description
0x01	REQFWD_NEW_MESSAGE	An array of N bytes representing the first N bytes of the current forwarded RPMI request message. The value N is specified by the EVENT_DATALEN field of the RPMI notification event as shown in Table 5.	This RPMI notification event represents the arrival of a new forwarded RPMI request message when there were no other pending forwarded RPMI request message in the queue.

4.13.2 Service: REQFWD_ENABLE_NOTIFICATION (SERVICE_ID: 0x01)

This service allows the application processor to subscribe to REQUEST_FORWARD service group notifications. The platform may optionally support notifications for events that may occur. The platform microcontroller can send these notification messages to the application processor if they are implemented and the application processor has subscribed to them. The supported events are described in Section 4.13.1.

Refer to Table 8 for Request Data and Table 9 for Response Data.

4.13.3 Service: REQFWD_RETRIEVE_CURRENT_MESSAGE (SERVICE_ID: 0x02)

This service allows application processors to retrieve the current forwarded RPMI request message. The current message may be the oldest forwarded RPMI request message in the platform microcontroller (or SBI implementation) queue.

Table 155. Request Data

Word	Name	Type	Description
0	START_INDEX	uint32	Starting index of first byte of the current forwarded RPMI request message. Use 0 for the first call, subsequent calls will use the next index of the remaining bytes.

Table 156. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully. | | RPMI_ERR_INVALID_PARAM | START_INDEX is invalid. | | RPMI_ERR_NO_DATA | No forwarded RPMI request message available. | - Other errors Table 6.
1	REMAINING	uint32	Remaining number of bytes in the current forwarded RPMI request message.
2	RETURNED	uint32	Number of bytes N of the current forwarded RPMI request message returned in this request.
3	REQUEST_MESSAGE[N]	uint8	An array of N bytes representing a part of the current forwarded RPMI request message at byte offset specified by START_INDEX.

4.13.4 Service: REQFWD_COMPLETE_CURRENT_MESSAGE (SERVICE_ID: 0x03)

This service allows the application processors to inform the platform microcontroller (or SBI implementation) that:

• The processing of the current forwarded RPMI request message has completed and RPMI response message must be sent to the original source of RPMI request message.
• The current forwarded RPMI request message must now point to the next forwarded RPMI request message if available.

If the service is called without retrieving the message, an error is returned. The service also returns NUM_MESSAGES, which is the number of forwarded messages available for retrieval from the platform microcontroller, excluding the current forwarded message.

Table 157. Request Data

Word	Name	Type	Description
0	RESPONSE_DATA[N]	uint8	An array of bytes representing the RPMI message data to be send as response data for the current forwarded RPMI request message. The N represents the total number of bytes in the response data which can be inferred by the platform microcontroller (or SBI implementation) from the overall size of the REQFWD_COMPLETE_CURRENT_MESSAGE service message.

Table 158. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully. | | RPMI_ERR_NO_DATA | No forwarded request message retrieved. | - Other errors Table 6.
1	NUM_MESSAGES	uint32	Number of forwarded messages available for retrieval, excluding the current forwarded message.

4.14 Service Group - LOGGING (SERVICEGROUP_ID: 0x000E)

This service group defines services used by an application processor to set the log data defined by the UEFI Platform Initialization specification [4] or other similar implementations. This service group provides a reliable way to track the progress of the system for diagnostic purposes. The data provided by the services can then be relayed to other consumers in the system such as the BMC, LCD display, etc.

The following table lists the services in the LOGGING service group:

Table 159. LOGGING Services

Service ID	Service Name	Request Type	RPMI Version
0x01	LOG_ENABLE_NOTIFICATION	NORMAL_REQUEST	2.0
0x02	LOG_DATA	NORMAL_REQUEST	2.0

4.14.1 Notifications

This service group does not support any events for notification.

4.14.2 Service: LOG_ENABLE_NOTIFICATION (SERVICE_ID: 0x01)

This service allows the application processor to subscribe to LOGGING service group notifications. The platform may optionally support notifications for events that may occur. The platform microcontroller can send these notification messages to the application processor if they are implemented and the application processor has subscribed to them. The supported events are described in Section 4.14.1.

Refer to Table 8 for Request Data and Table 9 for Response Data.

4.14.3 Service: LOG_DATA (SERVICE_ID: 0x02)

This service is used to set the log data.

4.14.3.1 Log Types

Table 160. Log Types

Value	Description
0x00000000
0x00000001 - 0x7FFFFFFF	Reserved.
0x80000000 - 0xFFFFFFFF	Implementation Specific.

Table 161. Request Data

WORD	Name	Type	Description
0	LOG_TYPE	uint32	Refer Table 160 for more details.
1	NUM_WORDS	uint32	Number of WORDs of data sent.
2	WORDS[]	uint32[]	Data to be logged.

Table 162. Response Data

WORD	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Logged successfully. | | RPMI_ERR_INVALID_PARAM | Invalid LOG_TYPE. | - Other errors Table 6.

note

EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT.

WORD	Value	Description
0	0x00000000	Type: UEFI Status Code.
1	0x00000002	Number of WORDS to follow: 2.
2	0x00000001	UEFI status code type: PROGRESS.
3	0x03051001	Value: 0x03051001.

EFI_CU_MEMORY_EC_UNCORRECTABLE.

WORD	Value	Description
0	0x00000000	Type: UEFI Status Code.
1	0x00000008	Number of WORDS to follow: 8.
2	0x90000002	UEFI status code type: ERROR with UNRECOVERED severity.
3	0x00051003	Value: 0x00051003.
4	0x00100004	HeaderSize + Size packed.
5	0xDDDDDDDD	first 32 bits of GUID.
6	0xDDDDDDDD	second 32 bits of GUID.
7	0xDDDDDDDD	third 32 bits of GUID.
8	0xDDDDDDDD	fourth 32 bits of GUID.
9	0xDEADBEAF	Payload.

4.15 Service Group - SYSTEM_IRQ (SERVICEGROUP_ID: 0x000F)

The SYSTEM_IRQ service group defines services to allow application processors receive external interrupts from the platform microcontroller. The platform microcontroller can use this service group to forward platform interrupts or inject software generated interrupts.

A platform microcontroller can trigger interrupt to a fixed number of targets using this service group where a target can be either direct or indirect. A direct target is an external interrupt line of a particular application processor associated with the RISC-V privilege level same as the underlying RPMI context. An indirect target is an interrupt source line of some other hardware interrupt controller which eventually triggers external interrupt to any of the application processors at RISC-V privilege level same as the underlying RPMI context. The number of targets supported by this service group is referred to as SYS_NUM_TARGET. Each target is assigned a unique index which is also referred to as SYS_TARGET_INDEX where 0 \<&#8203;= SYS_TARGET_INDEX \< SYS_NUM_TARGET.

To implement this service group, the platform microcontroller must have an implementation specific way to set and clear interrupt for all supported targets.

The number of system interrupts (IRQs) supported by this service group is fixed and referred to as SYS_NUM_IRQ. Each system IRQ is assigned a unique index which is also referred to as SYS_IRQ_INDEX where 0 \<&#8203;= SYS_IRQ_INDEX \< SYS_NUM_IRQ.

The association between actual source of interrupt and system IRQ index (aka SYS_IRQ_INDEX) is platform specific and must be discovered using hardware description mechanisms such as device tree or ACPI.

A system IRQ can only be associated with one of the supported targets and this can be configured by the application processors using the SYSIRQ_SET_IRQ_TARGET service. By default, the platform microcontroller will associate any target with a system IRQ.

The system IRQ state is a 32-bit word also referred to as SYS_IRQ_STATE which includes whether the system IRQ is enabled/disabled and whether system IRQ is currently pending at the platform microcontroller. The Table 163 below shows the encoding of SYS_IRQ_STATE.

Table 163. System IRQ State

Bits	Permission	Description
[31:2]	NA	Reserved and must be 0.
[1]	Read-Only	0b0: IRQ is not pending.
[0]	Read-Write	0b0: IRQ disabled.

The platform microcontroller must set interrupt for a particular target when at least one system IRQ associated with the target is pending and enabled.

The platform microcontroller must clear interrupt for a particular target when none of the system IRQs associated with the target are pending and enabled.

Upon receiving external interrupt, an application processor must claim pending and enabled interrupts the SYSIRQ_CLAIM service.

Upon successful claim of a system IRQ by an application processor, the platform microcontroller must clear the pending state of the system IRQ.

The Table 164 below lists the services in the SYSTEM_IRQ service group:

Table 164. SYSTEM_IRQ Services

Service ID	Service Name	Request Type	RPMI Version
0x01	SYSIRQ_ENABLE_NOTIFICATION	NORMAL_REQUEST	2.0
0x02	SYSIRQ_GET_ATTRIBUTES	NORMAL_REQUEST	2.0
0x03	SYSIRQ_GET_TARGET_ATTRIBUTES	NORMAL_REQUEST	2.0
0x04	SYSIRQ_GET_IRQ_ATTRIBUTES	NORMAL_REQUEST	2.0
0x05	SYSIRQ_SET_IRQ_STATE	NORMAL_REQUEST	2.0
0x06	SYSIRQ_GET_IRQ_STATE	NORMAL_REQUEST	2.0
0x07	SYSIRQ_SET_IRQ_TARGET	NORMAL_REQUEST	2.0
0x08	SYSIRQ_GET_IRQ_TARGET	NORMAL_REQUEST	2.0
0x09	SYSIRQ_CLAIM	NORMAL_REQUEST	2.0

4.15.1 Notifications

This service group does not support any events for notification.

4.15.2 Service: SYSIRQ_ENABLE_NOTIFICATION (SERVICE_ID: 0x01)

This service allows the application processor to subscribe to SYSTEM_IRQ service group notifications. The platform may optionally support notifications for events that may occur. The platform microcontroller can send these notification messages to the application processor if they are implemented and the application processor has subscribed to them. The supported events are described in Section 4.15.1.

Refer to Table 8 for Request Data and Table 9 for Response Data.

4.15.3 Service: SYSIRQ_GET_ATTRIBUTES (SERVICE_ID: 0x02)

This service is used to discover attributes of the system IRQ service group.

Table 165. Request Data

NA

Table 166. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully. | - Other errors Table 6.
1	SYS_NUM_TARGET	uint32	Number of targets.
2	SYS_NUM_IRQ	uint32	Number of system IRQs.
3:7	FLAGS	uint32[5]	Reserved and must be 0.

4.15.4 Service: SYSIRQ_GET_TARGET_ATTRIBUTES (SERVICE_ID: 0x03)

This service is used to discover attributes of a particular target.

Table 167. Request Data

Word	Name	Type	Description
0	SYS_TARGET_INDEX	uint32	Index of the target.

Table 168. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully. | | RPMI_ERR_INVALID_PARAM | SYS_TARGET_INDEX value is greater than SYS_NUM_TARGET. | - Other errors Table 6.
1	SYS_TARGET_FLAGS	uint32	| Bits | Description | | --- | --- | | [31:1] | Reserved and must be 0. | | [0] | 0b1: Indirect target 0b0: Direct target |
2	SYS_TARGET_HART_ID	uint32	Hart ID of the direct target. This field should be ignored for indirect target.
3:7	SYS_TARGET_NAME	uint8[20]	Target name, a NULL-terminated ASCII string up to 20-bytes.

4.15.5 Service: SYSIRQ_GET_IRQ_ATTRIBUTES (SERVICE_ID: 0x04)

This service is used to discover attributes of a particular system IRQ.

Table 169. Request Data

Word	Name	Type	Description
0	SYS_IRQ_INDEX	uint32	Index of the system IRQ.

Table 170. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully. | | RPMI_ERR_INVALID_PARAM | SYS_IRQ_INDEX value is greater than SYS_NUM_IRQ. | - Other errors Table 6.
1:2	FLAGS	uint32[2]	Reserved and must be 0.
3:7	SYS_IRQ_NAME	uint8[20]	System IRQ name, a NULL-terminated ASCII string up to 16-bytes.

4.15.6 Service: SYSIRQ_SET_IRQ_STATE (SERVICE_ID: 0x05)

This service is used to update the state of a system IRQ. Specifically, it allows application processors to enable or disable a system IRQ. The read-only bits of the system IRQ state are not updated by this service.

Table 171. Request Data

Word	Name	Type	Description
0	SYS_IRQ_INDEX	uint32	Index of the system IRQ.
1	SYS_IRQ_STATE	uint32	System IRQ state as defined in Table 163.

Table 172. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | IRQ is enabled or disabled successfully. | | RPMI_ERR_INVALID_PARAM | SYS_IRQ_INDEX value is greater than SYS_NUM_IRQ or SYS_IRQ_STATE value is reserved or invalid. | - Other errors Table 6.

4.15.7 Service: SYSIRQ_GET_IRQ_STATE (SERVICE_ID: 0x06)

This service is used to get the current state of a system IRQ.

Table 173. Request Data

Word	Name	Type	Description
0	SYS_IRQ_INDEX	uint32	Index of the system IRQ.

Table 174. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | IRQ state is returned successfully. | | RPMI_ERR_INVALID_PARAM | SYS_IRQ_INDEX value is greater than SYS_NUM_IRQ. | - Other errors Table 6.
1	SYS_IRQ_STATE	uint32	System IRQ state as defined in Table 163.

4.15.8 Service: SYSIRQ_SET_IRQ_TARGET (SERVICE_ID: 0x07)

This service is used to associate a system IRQ with a target.

Table 175. Request Data

Word	Name	Type	Description
0	SYS_IRQ_INDEX	uint32	Index of the system IRQ.
1	SYS_IRQ_TARGET	uint32	imply SYS_TARGET_INDEX of a specific target.

Table 176. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Target configured successfully. | | RPMI_ERR_INVALID_PARAM | or SYS_IRQ_TARGET value is greater than SYS_NUM_TARGET and less than 0xffffffff. | - Other errors Table 6.

4.15.9 Service: SYSIRQ_GET_IRQ_TARGET (SERVICE_ID: 0x08)

This service is used to get the target associated with a system IRQ.

Table 177. Request Data

Word	Name	Type	Description
0	SYS_IRQ_INDEX	uint32	Index of the system IRQ.

Table 178. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Target details returned successfully. | | RPMI_ERR_INVALID_PARAM | SYS_IRQ_INDEX value is greater than SYS_NUM_IRQ. | - Other errors Table 6.
1	SYS_IRQ_TARGET	uint32	value will be 0xffffffff.

4.15.10 Service: SYSIRQ_CLAIM (SERVICE_ID: 0x09)

This service is used to claim pending and enabled interrupts to be handled for a particular target.

Table 179. Request Data

Word	Name	Type	Description
0	SYS_TARGET_INDEX	uint32	Index of the target.

Table 180. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | IRQs claimed successfully. | | RPMI_ERR_INVALID_PARAM | HART_ID is invalid. | - Other errors Table 6.
1	RETURNED	uint32	Number of claimed IRQs returned.
2	SYS_IRQ_INDEX[]	uint32	System IRQ indexes of claimed IRQs.

4.16 Service Group - TEE (SERVICEGROUP_ID: 0x0010)

The TEE service group defines services to allow a client in one or more REEs (Rich Execution Environments) to invoke services in one or more TEEs (Trusted Execution Environments). A TEE is a secure, hardware-isolated environment running a trusted OS, and provides, directly or via hosted Trusted Applications (TAs), security-sensitive services such as key management, cryptographic operations, hardware-bound decoding of DRM-protected data streams, etc.

Throughout this chapter we refer to REEs and TEEs as described by the Global Platform TEE System Architecture [6].

The TEE service group defines RPMI services enabling the interaction of REEs and TEEs in a system where Hypervisor-level software can be optionally present in one or both domains.

No assumption is being made for the isolation technology, or collection thereof, used to separate the runtime execution of REEs and TEEs. No explicit reference is made to a system in which more than two domains exist, and the usage of the proposed services does not explore such a system.

In line with the accepted model for REE and TEE execution, the scheduling assumption that a TEE and its hypervisor only run when explicitly invoked by an REE (and/or its hypervisor) or in order to serve interrupts it has registered.

This yields to an execution model in which the REE domain routinely controls all the harts in the system, and invokes the TEE domain to synchronously process individual requests. When an interrupt registered by the TEE domain fires upon the application processor, its servicing by the TEE domain takes priority over any currently running REE task on the same hart.

This service group describes RPMI services to allow the discovery of the REE/TEE topology, sharing, lending and donating memory between REEs and TEEs, raising asynchronous signals and sending synchronous messages between REEs and TEEs. The RPMI services here defined allow multiple combinations of REEs and TEEs to work together (single REE with single TEE, multiple REEs with single TEE, multiple REEs with multiple TEEs) and interoperate with different hypervisor and firmware implementations as long as they all support and implement these services.

We refer to the implementation of the TEE service group in hypervisors and M-Mode firmware as the TEE framework, or simply framework.

The Table 181 table lists the services in the TEE service group:

Table 181. TEE Services

Service ID	Service Name	Request Type
0x01	TEE_ENABLE_NOTIFICATION	NORMAL_REQUEST
0x02	TEE_PROBE_FEATURES	NORMAL_REQUEST
0x03	TEE_PROBE_SYSTEM	NORMAL_REQUEST
0x04	TEE_EXIT	NORMAL_REQUEST
0x05	TEE_SIGNAL_BUS_SETUP	NORMAL_REQUEST
0x06	TEE_SIGNAL_BUS_TEARDOWN	NORMAL_REQUEST
0x07	TEE_SIGNAL_RAISE	NORMAL_REQUEST
0x08	TEE_SIGNAL_RETRIEVE	NORMAL_REQUEST
0x09	TEE_MEMORY_PARCEL_CREATE	NORMAL_REQUEST
0x0A	TEE_MEMORY_PARCEL_ACCEPT	NORMAL_REQUEST
0x0B	TEE_MEMORY_PARCEL_RELEASE	NORMAL_REQUEST
0x0C	TEE_MEMORY_PARCEL_RECLAIM	NORMAL_REQUEST
0x0D	TEE_MEMORY_SEGMENT_SEND	NORMAL_REQUEST
0x0E	TEE_MEMORY_SEGMENT_RECEIVE	NORMAL_REQUEST
0x0F	TEE_REGISTER_FOR_LIFECYCLE_INFO	NORMAL_REQUEST
0x10	TEE_ON_START_INFO	NORMAL_REQUEST
0x11	TEE_ON_SHUTDOWN_INFO	NORMAL_REQUEST
0x12	TEE_ON_CHANGED_INFO	NORMAL_REQUEST
0x13	TEE_CALL	NORMAL_REQUEST

Of the services listed in Table 181 only TEE_ENABLE_NOTIFICATION, TEE_PROBE_FEATURES and TEE_CALL are mandated to be supported by the framework and all connected REEs/TEEs. All remaining services should be considered optional both in the framework and in REEs/TEEs and their invocation can always fail with an RPMI_ERR_NOT_SUPPORTED error.

4.16.1 Endpoints and proxies

It is possible for an REE or TEE to contain multiple proxied endpoints, or even for the framework itself to contain proxied endpoints, i.e. entities with a unique identity to which messages can be routed to, irrespective of their physical location inside a specific REE or TEE operating system, which proxies them. Proxied endpoints can be used to represent special secure runtime modes for on-device accelerators, with whom memory can be shared, donated or lent at runtime to model and implement complex secure use cases.

All endpoints, proxied or physical, are given by the framework a unique identity. The mechanism by which this happens is outside of the scope of the present document.

All proxied endpoints exist within some physical endpoint, i.e. an REE or TEE. The physical endpoint where they reside is usually referred to as their proxy.

Most of the services described in this document apply to all endpoints, whether they are physical or proxied, TEEs or REEs; in all such cases we’ll use the word endpoint throughout the document instead of explicitly calling out whether we’re referring to a TEE or an REE, a physical or proxied entity.

When instead referring to physical entities and not generic endpoints, the REE and TEE terms will be used explicitly.

4.16.2 Notifications

This service group does not support any events for notification.

4.16.3 Service: TEE_ENABLE_NOTIFICATION (SERVICE_ID: 0x01)

This service allows the application processor to subscribe to TEE service group notifications. The platform may optionally support notifications for events that may occur. The framework can send these notification messages to the endpoint if they are implemented and the endpoint has subscribed to them. The supported events are described in Section 4.16.2.

Refer to Table 8 for Request Data and Table 9 for Response Data.

4.16.4 Service: TEE_PROBE_FEATURES (SERVICE_ID: 0x02)

This service can be used by an endpoint to discover which features the framework supports.

The service is used by passing a feature identifier as parameter, and the response is interpreted based on the queried feature.

Table Table 182 details which features can be queried and how the response should be interpreted.

Note that the level of support for memory management services depends on the technology used to isolate REEs and TEEs. Some isolation technology might not allow memory to be shared or lent (thereby changing its properties at runtime) between domains.

Table 182. TEE framework features

FEATURE	ID	VALUE
MEMORY_DONATE	1	| Value | Description | | --- | --- | | 0 | Not supported | | 1 | Supported between TEEs, but not between REEs and TEEs. | | 2 | Fully supported |
MEMORY_LEND	2	| Value | Description | | --- | --- | | 0 | Not supported | | 1 | Supported between TEEs, but not between REEs and TEEs. | | 2 | Fully supported |
MEMORY_SHARE	3	| Value | Description | | --- | --- | | 0 | Not supported | | 1 | Supported between TEEs, but not between REEs and TEEs. | | 2 | Fully supported |
SIGNAL_BUS	4	| Bits | Description | | --- | --- | | [31:12] | System MSI index or System IRQ index to be used for receiving availability of signals on the signal bus. If signals are not supported, this field is invalid and must be zero. | | [11:2] | Maximum width of the bus (i.e. maximum number of signals per pair of physical endpoints). If signals are not supported, this field is invalid and must be zero. | | [1:0] | 0: Not supported 1: Signals supported and delivered as System MSI. 2: Signals supported and delivered as System IRQ. 3: Reserved for future use. |
MULTISEGMENT_OPS	5	Number of concurrent pending multi-segment memory operations supported per endpoint. A memory operation whose content does not fit in the available transport buffer would need to be split into multiple segmented operations, thus making it theoretically possible for an endpoint to have more than one memory operation pending with the framework at a time. A value of 0 for this feature means that the framework does not support multi-segment memory operations.
SYSINFO_FORMAT	6	List of the formats in which the framework can describe the running system and its parts for the TEE_PROBE_SYSTEM and lifecycle services | Bits | Name | Description | | --- | --- | --- | | [31:31] | CBOR | CBOR [5] description following the CCDL [7] schema in Listing 1. | | [30:0] | Reserved | Must be 0. |

Table 183. Request Data

Word	Name	Type	Description
0	FEATURE_ID	uint32	Identifier of a feature in the TEE Service group as defined in Table 182.

Table 184. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully. | | RPMI_ERR_INVALID_PARAM | Invalid FEATURE_ID. | - Other errors Table 6.
1	VALUE	uint32	As defined in Table 182.

4.16.5 Service: TEE_PROBE_SYSTEM (SERVICE_ID: 0x03)

This service provides the caller with information on all the endpoints present in the system and reachable via the framework.

This service can be used to obtain a description of the whole system (i.e. all REEs and TEEs reachable via the services of the TEE Service Group) or selected components of it, as described in the following table.

Table 185. TEE_PROBE_SYSTEM Target Types

Target type	VALUE	Description.
Whole system	0	This is the set of all REEs and TEEs reachable via the TEE Services, their identifiers, all their proxied endpoints, services and their characteristics. This target type allows a newly created endpoint to discover all the other entities it can interact with.
Endpoint	1	Single endpoint in the system (REE, TEE or proxied). If the endpoint is an REE or TEE, this includes the list of all of its services. This target type allows the caller to discover additional information on an endpoint for which it already has the identifier.
Service	2	Multiple endpoints can implement the same service (identified by a UUID). This target type allows the caller to quickly discover all the endpoints which implement a specific service without the need to parse the description of the whole system.
Self	3	This target type allows an endpoint to acquire from the framework information about itself. This can be used by a newly created REE or TEE to discover if the bootloaders which predated it in the current VM shared or lent memory for specific use cases, so that this memory can be later reclaimed.
Memory parcel	4	This target type allows an endpoint to acquire information from the framework about a specific memory parcel which it created and is the owner of. This can be used by a newly created REE or TEE to discover the details of each memory parcel which the bootloaders which predated it in the current VM shared or lent with another endpoint.

The current version of the RPMI TEE Service Group only specifies CBOR [5] as a mandated format, but other formats may be added in future.

The CBOR response data is encoded according to the CCDL [7] schema in the following table.

tee-subsystem = [2* domain]

domain = [* endpoint]

endpoint = ee-endpoint / proxied-endpoint

ee-endpoint = {
  type: "physical",
  id: uint,
  name: bstr,
  persistent: bool,
  proxied-endpoints: [* proxied-endpoint],
  services: [* buuid],
  metadata: bstr,
  ?active_parcels: [* parcel],
}

proxied-endpoint = {
  type: "proxied",
  id: uint,
  name: bstr,
  ?active_parcels: [* parcel],
}

parcel = {
  id: uint,
  residual_access: ac,
  others: [1* parcel_endpoint],
  label: bstr,
  ?memory: [1* memory_block],
}

ac = &(none: 0, ro: 1, wo: 2, rw: 3, rwx: 7)

parcel_endpoint = {
  id: uint,
  access: ac,
  accepted: bool,
}

memory_block = {
  address: uint,
  size: uint,
}

buuid = #6.37(bstr)

Table 186. Request Data

Word	Name	Type	Description
0	SYSINFO_FORMAT	uint32	The format in which the response data will be returned. Needs to be one of the formats returned by the TEE_PROBE_FEATURES service.
1	TARGET_TYPE	uint32	Type of the target being probed, as described in Table 185. Valid values and corresponding expected content of the returned response data are described in the following table | Value | Content of SYSTEM_DATA in Table 187. | | --- | --- | | 0 | Whole system. Description of the whole system topology excluding the items marked as optional in Listing 1. | | 1 | Endpoint Description of the requested endpoint. Items marked as optional in Listing 1 are not included. | | 2 | Service Description of the subset of the whole system topology comprising all the endpoints providing the requested service. Items marked as optional in Listing 1 are not included. | | 3 | Self Description of the calling endpoint including all of its available optional items, but not the memory blocks of the active parcels created by the endpoint. | | 4 | Memory parcel Full description, including the memory blocks, of the requested parcel. The parcel must belong to the calling endpoint. |
2	TARGET_LEN	uint32	Length (N) in bytes of the TARGET field. Based on the TARGET_TYPE, the following length values are expected. | TARGET_TYPE | Length (N) | Content | | --- | --- | --- | | 0 | 0 | NA | | 1 | 4 | Endpoint identifier. | | 2 | 16 | UUID of the service. | | 3 | 0 | NA | | 4 | 4 | ID of the parcel. |
3	TARGET[N]	uint8	The target being probed.

Table 187. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Service completed successfully. | | RPMI_ERR_INVALID_PARAM | Invalid SYSINFO_FORMAT, TARGET_TYPE or TARGET. | | RPMI_ERR_DENIED | Parcel does not belong to the calling endpoint. | - Other errors Table 6.
1	SYSTEM_DATA_LEN	uint32	Length (N) in bytes of the returned data.
2	SYSTEM_DATA[N]	uint8	Description of the system or portion thereof, as queried, in the requested format.

4.16.6 Service: TEE_EXIT (SERVICE_ID: 0x04)

This service is used by an REE or TEE to inform the framework that it is exiting the framework infrastructure.

After an REE/TEE sends this message, the framework will refrain from forwarding any further message and, for TEEs, interrupts, to it.

note

When an REE/TEE is disconnected from the framework:

• All the memory parcels it had accepted and not yet released are forcefully released by the framework and the REE/TEE immediately loses access to them.
• The in-progress construction of any multi-segment memory parcel by this REE/TEE is aborted and returned to the REE/TEE.
• The in-progress acceptance of any multi-segment memory parcel by this REE/TEE is aborted.
• All signal buses that this REE/TEE might have established with other endpoints are torn down by the framework and any attempt to access them by the other endpoint (to raise or retrieve a signal) before the reception of the TEE_ON_SHUTDOWN_INFO message will be answered by the framework as if the bus was being torn down. After the reception of the TEE_ON_SHUTDOWN_INFO message, the bus is considered torn down.
• Finally a TEE_ON_SHUTDOWN_INFO message containing the identity of this REE/TEE is sent to all endpoints which registered for it.

Table 188. Request Data

NA

Table 189. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | The framework will not return execution to the calling REE/TEE. | - Other errors Table 6.

4.16.7 Service: TEE_SIGNAL_BUS_SETUP (SERVICE_ID: 0x05)

Signals differ from data messages in that their implementation by the framework is not guaranteed to be synchronous.

When an endpoint running on a certain hart raises a signal to another endpoint, the framework does guarantee neither the hart nor the time at which the signal will be processed by the target endpoint.

Signals are modeled as bits on a logical bus, which is shared between two physical endpoints (REEs/TEEs, which are enough to uniquely identify it) and all the endpoints they proxy. The width of the bus, and thereby the number of concurrent signals it supports, is set when the bus is setup by the two physical endpoints, using the TEE_SIGNAL_BUS_SETUP service. Likewise the partitioning of the signals between the two physical endpoints is statically determined by the setup call, and is later enforced by the framework.

note

Because of scheduling constraints, the setup of a signal bus between an REE and a TEE can only be initiated by an REE.

This service is invoked by a physical endpoint, its fields verified by the framework, and passed to the target physical endpoint, which can accept or deny the request to setup and share the bus with the caller.

Signals on the bus can be raised and retrieved by any of the two physical endpoints and all the endpoints they proxy. The optional functional partitioning of the signals owned by a physical endpoint among use cases and proxied endpoints is not enforced or orchestrated by the framework: signals are always set and retrieved by the physical endpoints.

Table 190. Request Data

Word	Name	Type	Description
0	TARGET_ID	uint32	Unique identifier of the target physical endpoint with which the bus is being setup.
1	BUS_WIDTH	uint32	Number (M) of signals to be supported on the bus.
2	SENDER_SIGNALS	uint32	Number (N) of signals reserved for the sender endpoint to receive. Signals 0 ≤ x < N will be reserved for the target endpoint to raise and the sender endpoint to read. Signals N ≤ x < M will be reserved for the sender endpoint to raise and the target endpoint to read.

Table 191. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | The signal bus between the sender and target endpoints has been set up and partitioned as requested. | | RPMI_ERR_INVALID_PARAM | This error is returned exclusively by the framework. - TARGET_ID does not correspond to a physical endpoint (REE/TEE). | | RPMI_ERR_BAD_RANGE | This error is returned exclusively by the framework. - Invalid BUS_WIDTH exceeds maximum supported number of signals. - SENDER_SIGNALS is larger than BUS_WIDTH. | | RPMI_ERR_ALREADY | This error is returned exclusively by the framework. Bus between the sender and target endpoints already setup. | | RPMI_ERR_DENIED | This is the only error returned by the target endpoint. The target endpoint rejects the request to establish the bus. | - Other errors Table 6.

Error conditions leading to the RPMI_ERR_INVALID_PARAM, RPMI_ERR_BAD_RANGE and RPMI_ERR_ALREADY are checked by the framework before the Request Data in Table 190 reaches the target endpoint. The target endpoint is only allowed to respond with either RPMI_SUCCESS or RPMI_ERR_DENIED. The framework will proceed with the creation of the bus only if the target endpoint fills the STATUS field with the RPMI_SUCCESS value.

If the target endpoint returns any other error code than RPMI_SUCCESS or RPMI_ERR_DENIED, the framework will interpret it as a malfunction and behave as if it had invoked the TEE_EXIT service.

4.16.8 Service: TEE_SIGNAL_BUS_TEARDOWN (SERVICE_ID: 0x06)

This service is used by an REE or TEE to tear down the signal bus it has established with a target TEE.

note

For the same reasons as in Section 4.16.7, the teardown of a signal bus between an REE and a TEE can only be initiated by an REE.

This service is invoked by a physical endpoint, its fields verified by the framework, and passed to the target physical endpoint, which can only accept the request to teardown the signal bus.

note

If a signal bus is torn down when there are active, not yet retrieved, signals on it, those signals will be lost.

After sending a TEE_SIGNAL_BUS_TEARDOWN, the sender endpoint cannot raise any signal, but can retrieve pending signals up until the point a response has been received. Upon receiving a TEE_SIGNAL_BUS_TEARDOWN, the target endpoint can retrieve its own active signals, but not raise any signals.

Table 192. Request Data

Word	Name	Type	Description
0	TARGET_ID	uint32	Identifier of the physical endpoint with which the bus is shared.

Table 193. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Signal bus between the sender and target endpoints has been torn down. | | RPMI_ERR_INVALID_PARAM | This error is returned exclusively by the framework. - TARGET_ID does not correspond to a physical endpoint (REE/TEE). | | RPMI_ERR_ALREADY | This error is returned exclusively by the framework. No bus exists between the sender and target endpoints. | - Other errors Table 6.

Error conditions leading to the RPMI_ERR_INVALID_PARAM and RPMI_ERR_ALREADY are checked by the framework before the Request Data in Table 190 reaches the target endpoint. The target endpoint is only allowed to respond with RPMI_SUCCESS and can interpret this as a synchronous notification from the framework that the signal bus is no longer available.

If the target endpoint returns any other error code than RPMI_SUCCESS the framework will interpret it as a malfunction and behave as if it had invoked the TEE_EXIT service.

4.16.9 Service: TEE_SIGNAL_RAISE (SERVICE_ID: 0x07)

This service is used by an endpoint to raise one or more signals on the signal bus shared with the target endpoint.

Upon a successful return, the signals are considered to be raised and will have been set as pending. If any of them was already pending, their state does not change.

This message does not cause the target endpoint (or any of its proxied endpoints) to run to process the signals: it is implementation dependent when it will run and will process them.

Table 194. Request Data

Word	Name	Type	Description
0	TARGET_ID	uint32	Identifier of the physical endpoint with which the bus is shared.
1	SIGNAL_LEN	uint32	Length (N) of the SIGNAL array. Length cannot be 0.
2	SIGNAL[N]	uint32	Array of signals being set. Each signal needs to be in the range reserved for the sender endpoint to raise.

Table 195. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | The signals were successfully raised on the bus. | | RPMI_ERR_INVALID_PARAM | - One or more signals are outside the sender supported range. - No bus between the sender and target endpoints. | | RPMI_ERR_DENIED | The bus is being torn down. | - Other errors Table 6.

4.16.10 Service: TEE_SIGNAL_RETRIEVE (SERVICE_ID: 0x08)

This service is used by an endpoint to retrieve from the framework its pending signals.

Retrieving a signal causes the framework to reset its internal tracking state for it, so it can be set again by the endpoints who have write access on the bus it is on.

This service will return, per bus, all the signals which are raised and readable by the calling endpoint. If more than one bus has active signals, this will be indicated in the response and they can be retrieved by the caller with additional subsequent calls.

Table 196. Request Data

NA

Table 197. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Signals successfully retrieved. | | RPMI_ERR_NO_DATA | No pending signals on any bus. | - Other errors Table 6.
1	FLAGS	uint32	| Bits | Field | Description | | --- | --- | --- | | [31:31] | MORE_AVAILABLE | This bit is set to 1 if more signals from other buses are available. | | [30:0] | Reserved | Must be 0. |
2	TARGET_ID	uint32	Identifier of the endpoint with which the bus is shared.
3	SIGNAL_LEN	uint32	Length (N) of the SIGNAL array. On success, length will never be 0.
4	SIGNAL[N]	uint32	Array of active signals on this bus. Each signal is guaranteed to be in the range reserved for the calling endpoint to retrieve.

4.16.11 Service: TEE_MEMORY_PARCEL_CREATE (SERVICE_ID: 0x09)

This service allows an endpoint to create a memory parcel, which is a structured description of a memory management operation between a number of endpoints that the framework needs to mediate and enforce.

A memory parcel is identified by a unique handle, refers to one or more contiguous memory regions, the operation which is being asked on them and a list of endpoints whose access should be changed along with their access rights.

A memory parcel can describe three operations:

• Memory donation, in which the owner of one or more memory regions is transferring their ownership to another individual endpoint. The original owner does not retain any access to the memory, nor will be able to reclaim the memory back at a later time.
• Memory sharing, in which an endpoint which has access to one or more memory regions grants access rights to other endpoints, while optionally changing its own access rights to it. The memory, with the original access rights, can be later reclaimed.
• Memory lending, which is a corner case of memory sharing, in which the endpoint does not have any residual access to the memory, but can reclaim it later.

The other endpoints involved in the operation need to accept the parcel (via the TEE_MEMORY_PARCEL_ACCEPT service) in order for the framework to allow them to map and access it, and, when done, are expected to release the parcel (using the TEE_MEMORY_PARCEL_RELEASE service). After a parcel has been released by all receiving endpoints (or before it has been accepted by any of them), the endpoint which created it can reclaim it (using the TEE_MEMORY_PARCEL_RECLAIM service), thereby destroying the parcel itself. Parcels describing memory donations cannot be reclaimed, and they are destroyed by the framework when they are accepted by the endpoint which becomes the new owner of the memory.

If the description of the memory underlying a memory parcel doesn’t fit within the RPMI transport buffer used to communicate with the framework, endpoints are expected to segment it explicitly via the TEE_MEMORY_SEGMENT_SEND and TEE_MEMORY_SEGMENT_RECEIVE services.

After the successful completion of this service (or of the last of the following TEE_MEMORY_SEGMENT_SEND in case of segmented memory description), the framework is expected to have modified the access to the memory for the calling endpoint as instructed, using whichever hardware memory firewalling mechanism available on the system.

The caller is required to specify the access permission to this memory for each receiver, and the framework will enforce that none of them exceeds the access that the caller itself has to the memory.

note

The RPMI TEE Services only describe the messages which are exchanged to operate on ownership and access to memory. The mechanisms by which ownership and access are enforced and guaranteed are out of scope and depend on the extensions present in each RISC-V processor architecture, its implementation and software topology.

Each memory region as referenced by these services can only have one owner at any given time.

When referred to in service request and response data, memory is always represented as a scatter-gather list comprised of 3 fields, with lengths specified in number of 4 kB pages (fixed granule size), as in the table Table 198. The location of the fields in each service request or response data is not fixed, and vary based on presence and sizes of other fields.

Table 198. Memory representation as a scatter-gather list

Name	Type	Description
BLOCK_CNT	uint32	Total number (M) of contiguous memory blocks. Cannot be 0.
BLOCK_HIGH[M]	uint32	Array of memory blocks. Higher 32bit, encoded as follows | Bits | Field | Description | | --- | --- | --- | | [31:0] | ADDRESS_HIGH | Higher 32bits of the physical or guest-physical address of the i-th block, in number of 4kB pages. |
BLOCK_LOW[M]	uint32	Array of memory blocks. Lower 32bit, encoded as follows | Bits | Field | Description | | --- | --- | --- | | [31:12] | ADDRESS_LOW | Lower 20bits of the physical or guest-physical address of the i-th block, in number of 4kB pages. | | [11:0] | PAGE_COUNT | Number of pages, with an offset of 1. Range 0..4095 maps to page count 1..4096. |

A single block of memory (BLOCK_HIGH[i]:BLOCK_LOW[i]) can thus represent up to 4096 4kB pages, for a total of 16MB.

note

Many of the RPMI TEE Services have Request and Response Data comprising multiple variable-length arrays. To ease their parsing by the receiver and framework implementations all fixed-length fields are placed first, followed by the variable-length fields.

In all memory management services, the fields describing access to the memory by an endpoint is encoded as in Table 199.

Table 199. Memory Access

Bits	Field	Description
[31:31]	EXECUTE	0b0: non-executable 0b1: executable
[30:30]	WRITE	0b0: non-writeable 0b1: writeable
[29:29]	READ	0b0: non-readable 0b1: readable
[28:0]	Reserved	Must be 0.

Table 200. Request Data

Word	Name	Type	Description
0	CREATOR_ID	uint32	Identifier of the endpoint creating the parcel. This is either the identity of the calling TEE or REE, or of an endpoint which is proxied by the calling TEE or REE.
1	CREATOR_ACCESS	uint32	Access permission which the endpoint creating the memory parcel is reserving for itself after the completion of this command. Encoding as in Table 199. If the OWNER_XFER FLAG is set, this field must be 0.
2	RECEIVER_CNT	uint32	Length (N) of the RECEIVER_ID and ACCESS arrays.
3	FLAGS	uint32	| Bits | Field | Description | | --- | --- | --- | | [31:31] | MULTI_SEGMENT | This bit is set to 1 if this is the first segment of a multi-segment memory management message. The following segments will be sent via the TEE_MEMORY_SEGMENT_SEND service. | | [30:30] | OWNER_XFER | This bit is set to 1 if this parcel describes a memory donation. When an ownership transfer is requested, the framework will enforce the following for the memory parcel: - the endpoint creating it must not retain any access to it - a single receiver is allowed - the access granted to the receiver must match the current access of the owner. The parcel created for an ownership transfer becomes invalid after it is accepted with the TEE_MEMORY_PARCEL_ACCEPT service and cannot be released by the new owner nor reclaimed by the original owner. | | [29:0] | Reserved | Must be 0. |
4	NONCE	uint32	A token nonce which receivers will need to present to the framework, together with MEM_PARCEL_ID, to accept the memory. It is intended as a way to reduce the likelihood of accidental collisions on MEM_PARCEL_ID values, which can be reused by the framework after they have been destroyed.
5	BLOCK_CNT	uint32	Total number (M) of contiguous memory blocks. Cannot be 0.
6:9	LABEL	uint8[16]	Label to be associated with the parcel. The label can be used to associate a parcel with a specific use case when the parcel is recovered via the TEE_PROBE_SYSTEM service.
10	RECEIVER_ID[N]	uint32	Array with the identifiers of the endpoints to which the parcel is granting access to the memory.
10+N	ACCESS[N]	uint32	Array with the access permissions for each endpoint in RECEIVER_ID, encoded as in Table 199.
10+2N	BLOCK_HIGH[M]	uint32	See Table 198.
10+2N+M	BLOCK_LOW[M]	uint32	See Table 198.

Table 201. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | New access permissions applied to the creator endpoint. Receiver endpoints can now accept the memory using the returned MEM_PARCEL_ID. | | RPMI_ERR_DENIED | The creator endpoint does not have access to the memory. | | RPMI_ERR_HW_FAULT | Hardware limitations (e.g. memory firewalling technology) don’t allow access to the memory to be granted to one or more of the receivers. | | RPMI_ERR_INVALID_PARAM | - The access being granted to a receiver exceeds the access of the endpoint creating the memory parcel. - The endpoint creating the memory parcel is not the REE/TEE this service is being invoked from or one of its proxied endpoints. | - Other errors Table 6.
1	MEM_PARCEL_ID	uint32	Device-unique identifier representing the newly created memory parcel. This identifier can be used by the receivers to accept and thereby access the memory. If the request was the first part of a multi-segment memory operation, then MEM_PARCEL_ID is not yet usable with any other service except TEE_MEMORY_SEGMENT_SEND.

4.16.12 Service: TEE_MEMORY_PARCEL_ACCEPT (SERVICE_ID: 0x0A)

This service is used by an endpoint to accept memory to which it has been granted access and/or ownership.

The endpoint passes in this call the memory parcel identifier representing the memory it’s accepting, together with associated information used during parcel creation (which is used for validation), i.e.

• the identifier of the endpoint which created the memory parcel and its residual access rights (see Section 4.16.11)
• its own expected access rights to the memory
• optionally, in case of multiple endpoints having been granted access to the memory by the memory parcel, the list of the their identifiers and their access rights to it.

note

The ZERO flag is useful to preserve the confidentiality on memory content for use cases in which the original owner has completely removed its access when granting it to other endpoints (i.e. it has temporarily lent the memory to other endpoints).

The framework complies with this request even if the endpoint is shutdown or abort, thus causing all of the memory it was granted access at runtime to be available for its owner to reclaim.

note

If a GPA_HINT is requested but the endpoint is not running on top of a hypervisor, it’s not in the scope of the framework to provide a PA satisfying the hint. The framework can only return the PA(s) corresponding to the memory which is part of the transaction, since it cannot perform any additional translation. If these PA(s) do not satisfy the hint, the framework will fail with RPMI_ERR_FAILED.

Endpoints are expected to discover by other means whether they are running or not on top of a hypervisor.

Table 202. Request Data

Word	Name	Type	Description
0	ACCEPTOR_ID	uint32	Identifier of the endpoint which is accepting the memory parcel. This is either the identity of the calling TEE or REE, or of an endpoint which is proxied by the calling TEE or REE.
1	ACCESS	uint32	Access permissions that the accepting endpoint is expected to have been granted on the memory being accepted. This must match the access declared for it in the memory parcel. Encoding as in Table 199.
2	MEM_PARCEL_ID	uint32	Device-unique identifier representing the memory parcel being accepted.
3	NONCE	uint32	A token nonce set by the endpoint which created the memory parcel and associated to it.
4	CREATOR_ID	uint32	Identifier of the endpoint which invoked the TEE_MEMORY_PARCEL_CREATE which led to the creation of the memory parcel which is being accepted with this service.
5	CREATOR_ACCESS	uint32	Access permissions that the creator of the parcel retained as part of the invocation to TEE_MEMORY_PARCEL_CREATE. Encoding as in Table 199.
6	FLAGS	uint32	| Bits | Field | Description | | --- | --- | --- | | [31:30] | GPA_HINT | Whether the framework must use the ALIGNMENT or ADDRESS hints when selecting the returned address. The framework will return error if the hint, when request, cannot be satisfied. 0b00: No hint. 0b01: Use ALIGNMENT hint. 0b10: Use ADDRESS hint. 0b11: Reserved. | | [29:25] | ALIGNMENT | Must be 0 if GPA_HINT is not 0b01. The returned address needs to be aligned at the 2n 4kB boundary, with n being the value of the ALIGNMENT flag. | | [24:21] | Reserved | Must be 0. | | [20:20] | CHECK_OTHER | Framework must perform a validation of the other endpoints and their access as passed in the OTHER_ID and OTHER_ACCESS arrays. 0b0: Do the validation. 0b1: No validation. | | [19:19] | ZERO | Framework must zero this memory after this endpoint has released its access to it and before the memory parcel is reclaimed by the endpoint which created it. 0b0: Zeroing is not required. 0b1: Zeroing is required. | | [18:0] | Reserved | Must be 0. |
7	ADDRESS_HIGH	uint32	Higher 32bits of the address at which the framework must return the memory. Must be 0 if GPA_HINT is not 0b10.
8	ADDRESS_LOW	uint32	Lower 32bits of the address at which the framework must return the memory. The address needs to be 4kB aligned. Must be 0 if GPA_HINT is not 0b10.
9	MAX_PAGES	uint32	Maximum size, in number of pages, of the memory that the caller is ready to accept. The framework will fail this request if the total size of the memory associated to the memory parcel exceeds this maximum size.
10	OTHER_CNT	uint32	Total number (N) of other endpoints which were granted access to the memory by the memory parcel. If the accepting endpoint requests the framework to validate them (CHECK_OTHER flag), this list must contain the identifiers of all the endpoints, other than the acceptor, listed in the call to TEE_MEMORY_PARCEL_CREATE which created this memory parcel, excluding the identifier of the endpoint which created the parcel itself, whose identifier and access is passed in OWNER_ID and OWNER_ACCESS and always validated by the framework. Must be 0 if CHECK_OTHER flag is not set.
11	OTHER_ID[N]	uint32	Identifiers of the endpoints which were being granted access to the memory in addition to the endpoint which is accepting it and the one which created it.
11+N	OTHER_ACCESS[N]	uint32	Access permission for each endpoint in OTHER_ID, encoded as in Table 199.

Table 203. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Memory has been successfully accepted and made available by the framework. If the memory parcel described a memory donation, it has now been destroyed and its identifier can be reused by the framework. | | RPMI_ERR_DENIED | ZERO flag is set but the accepting endpoint has no write access to it. | | RPMI_ERR_INVALID_PARAM | - Invalid MEM_PARCEL_ID. - Validation error on ACCEPTOR_ID, OTHER_ID or their access permissions. - Validation error on NONCE. - Requested ADDRESS already in use. - Size exceeds MAX_PAGES - ZERO flag is set, but some of the memory is classified as device memory. - Invalid GPA_HINT. | - Other errors Table 6.
1	FLAGS	uint32	| Bits | Field | Description | | --- | --- | --- | | [31:31] | MULTI_SEGMENT | This field is set to 1 if this is the first segment of a multi-segment memory management response. The following segments will be retrieved via the TEE_MEMORY_SEGMENT_RECEIVE service. | | [30:0] | Reserved | Must be 0. |
2	PAGE_CNT	uint32	Total size of the memory, in number of 4kB pages.
3	BLOCK_CNT	uint32	Total number (M) of contiguous memory blocks. On success, will never be 0.
4	BLOCK_HIGH[M]	uint32	See Table 198.
4+M	BLOCK_LOW[M]	uint32	See Table 198.

4.16.13 Service: TEE_MEMORY_PARCEL_RELEASE (SERVICE_ID: 0x0B)

This service is called by an endpoint which was granted access (but not ownership) to some memory via a memory parcel, to release it back to the memory parcel creator, who can reclaim it back by using the TEE_MEMORY_PARCEL_RECLAIM service.

If multiple endpoints proxied by the same physical endpoint were granted access to memory via the same memory parcel, a single invocation of this service, listing all of them in the ENDPOINT_ID array, can be performed by the physical endpoint which proxies them.

This service can also be used by an endpoint which is in the process of accepting a multi-segment memory parcel (i.e. it hasn’t yet received a response to the TEE_MEMORY_SEGMENT_RECEIVE service with the LAST_SEGMENT bit set) to abort the operation. The parcel is thereby returned to the state it had before the multi-segment acceptance sequence by this endpoint had started.

note

The ZERO flag in TEE_MEMORY_PARCEL_RELEASE has the same effect as the ZERO flag in TEE_MEMORY_PARCEL_ACCEPT, but they serve a different purpose. In TEE_MEMORY_PARCEL_ACCEPT, it provides the guarantee that if the endpoint were to terminate without the opportunity to release the memory, no data would be leaked. In TEE_MEMORY_PARCEL_RELEASE, it serves mostly an optimization purpose, so that if multiple endpoints are releasing memory at the end of a use case, instead of them all zeroing the memory, the framework would be able to operate on it a single time.

This flag should be used for this second purpose only after careful consideration, since zeroing large amount of memory from within the framework might have an impact on the overall system responsiveness (e.g. it is implementation dependent if and which portions of the framework are capable of running with interrupts masked).

Table 204. Request Data

Word	Name	Type	Description
0	MEM_PARCEL_ID	uint32	Device-unique identifier representing the memory parcel being released.
1	FLAGS	uint32	| Bits | Field | Description | | --- | --- | --- | | [31:31] | ZERO | Request the framework to zero the memory before it is returned to the memory parcel creator. 0b0: Zeroing is not required. 0b1: Zeroing is required. | | [30:0] | Reserved | Must be 0. |
2	ENDPOINT_CNT	uint32	Number (N) of endpoints on behalf of which the sender REE/TEE is releasing access to the memory referred to by the memory parcel. This number cannot be 0.
3	ENDPOINT_ID[N]	uint32	Identifiers of the endpoints which are releasing access to the memory region referred to by the memory parcel.

Table 205. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | The memory parcel has been successfully released. The framework has removed access to its underlying memory from all endpoints in the ENDPOINT_ID array. | | RPMI_ERR_DENIED | - ZERO flag is set but none of the endpoints in the ENDPOINT_ID array has write access to it. - One or more of the listed endpoints is not proxied by the calling REE/TEE. | | RPMI_ERR_INVALID_PARAM | - Invalid/unknown MEM_PARCEL_ID. - ZERO flag is set, but some of the memory is classified as device memory. - Invalid FLAG. - Not all listed endpoints had been granted access to the memory referred to by the memory parcel (or they have already released their claim to it). | - Other errors Table 6.

4.16.14 Service: TEE_MEMORY_PARCEL_RECLAIM (SERVICE_ID: 0x0C)

This service is called by an endpoint which had previously created a memory parcel to reclaim access to the memory and access right it had before its creation. A successful completion of this service destroys the memory parcel, whose identifier can then be reused by the framework for a new parcel.

When this service is called, no other endpoint must have a claim on the memory parcel, so each of them must either have accepted and then released it, or never accepted it.

This service cannot be called on a memory parcel which describes memory ownership transfer after it has been accepted, since acceptance of such a parcel destroys it and hence makes the identifier invalid.

This service can also be used by an endpoint which is in the process of creating a multi-segment memory parcel (i.e. it hasn’t yet invoked the TEE_MEMORY_SEGMENT_SEND service with the LAST_SEGMENT bit set) to abort the operation. The parcel is thereby destroyed and its identifier can be reused by the framework.

note

In case of a REE/TEE hosting multiple endpoints, it is not necessary to specify on behalf of which the memory is being reclaimed, since the knowledge of the creator of the parcel is implicit in the MEM_HANDLE itself.

Table 206. Request Data

Word	Name	Type	Description
0	MEM_PARCEL_ID	uint32	Unique identifier of the memory parcel which is being reclaimed.

Table 207. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Memory has been successfully reclaimed. | | RPMI_ERR_DENIED | - Not all endpoints which accepted the memory parcel have released it. | | RPMI_ERR_INVALID_PARAM | - Invalid/unknown MEM_PARCEL_ID. - The memory parcel doesn’t refer to memory owned by any of the endpoints hosted by the caller. | - Other errors Table 6.
1	FLAGS	uint32	| Bits | Field | Description | | --- | --- | --- | | [31:31] | ZEROED | The memory was zeroed by the framework before the original access was restored and after the last of the receivers released the parcel. 0b0: The framework did not zero the memory. 0b1: The framework zeroed the memory. | | [30:0] | Reserved | Must be 0. |

4.16.15 Service: TEE_MEMORY_SEGMENT_SEND (SERVICE_ID: 0x0D)

This service is used to complete the creation of a memory parcel whose memory description doesn’t fit in the RPMI transport buffer used for the TEE_MEMORY_PARCEL_CREATE service.

In such a case the endpoint sets the MULTI_SEGMENT bit to 1 in the TEE_MEMORY_PARCEL_CREATE service, and completes the creation by invoking one or more time the TEE_MEMORY_SEGMENT_SEND service until all the memory has been completely described. The parcel is considered created (and no more segments can be added) when a segment with the LAST_SEGMENT flag bit set is sent.

note

In the case of a multi-segment parcel, the new access permissions for the creator are applied only when the last segment for the parcel is sent and the TEE_MEMORY_SEGMENT_SEND completes with success.

It is implementation specific (and discoverable via TEE_FEATURES_PROBE) if multiple concurrent multi-segment TEE_MEMORY_PARCEL_CREATE services are supported by the framework.

note

This service doesn’t require the calling REE/TEE to specify the endpoint which is continuing the creation of the memory parcel, since its identity has already been assigned during the initial TEE_MEMORY_PARCEL_CREATE (CREATOR_ID field). This service will only verify that the endpoint which initiated its creation is the calling REE/TEE or an endpoint it proxies.

Table 208. Request Data

Word	Name	Type	Description
0	MEM_PARCEL_ID	uint32	Identifier obtained from a TEE_MEMORY_PARCEL_CREATE multi-segment service, which this service is now continuing.
1	FLAGS	uint32	| Bits | Field | Description | | --- | --- | --- | | [31:31] | LAST_SEGMENT | 0b0: More segments to be sent. 0b1: This is the last segment. | | [30:0] | Reserved | Must be 0. |
2	BLOCK_CNT	uint32	Total number (M) of contiguous memory blocks. Cannot be 0.
3	BLOCK_HIGH[M]	uint32	See Table 198.
3+M	BLOCK_LOW[M]	uint32	See Table 198.

Table 209. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Memory added to the memory parcel. | | RPMI_ERR_DENIED | The endpoint creating the memory parcel does not have access to the memory or has less access than it is trying to grant with the parcel to other endpoints. | | RPMI_ERR_HW_FAULT | Hardware limitations (e.g. memory firewalling technology) don’t allow access to the memory to be granted to one or more of the receivers. | | RPMI_ERR_INVALID_PARAM | - The calling REE/TEE does not proxies the endpoint which initiated the creation of the parcel. | - Other errors Table 6.

4.16.16 Service: TEE_MEMORY_SEGMENT_RECEIVE (SERVICE_ID: 0x0E)

This service is used by an endpoint following an invocation of TEE_MEMORY_ACCEPT with the MULTI_SEGMENT flag set in the response data, i.e. when the memory description did not fit in the maximum message size supported by the transport.

The acceptance of the memory is not considered complete (and the memory is not accessible to the caller) until the last segment describing it has been received.

It is implementation specific (and discoverable via TEE_FEATURES_PROBE) if multiple concurrent multi-segment TEE_MEMORY_ACCEPT services are supported by the framework.

Table 210. Request Data

Word	Name	Type	Description
0	ACCEPTOR_ID	uint32	Identifier of the endpoint which is continuing a TEE_MEMORY_ACCEPT operation. It must match the ACCEPTOR_ID passed in the TEE_MEMORY_PARCEL_ACCEPT service call which initiated the accept operation.
1	MEM_PARCEL_ID	uint32	Identifier representing the memory parcel being accepted.

Table 211. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | The service completed successfully. If this was the last segment: - the new access permissions for the accepting endpoint have been applied by the framework, - no further call of TEE_MEMORY_SEGMENT_RECEIVE on this memory parcel can be issued by this accepting endpoint. | | RPMI_ERR_INVALID_PARAM | - Unknown MEM_PARCEL_ID, or not part of an in-progress multi-segment memory acceptance operation. - ACCEPTOR_ID does not belong to the calling REE/TEE. - ACCEPTOR_ID does not correspond to the endpoint which initiated the accept operation. | - Other errors Table 6.
1	FLAGS	uint32	| Bits | Field | Description | | --- | --- | --- | | [31:31] | LAST_SEGMENT | 0b0: More segments to be received. 0b1: This is the last segment. | | [30:0] | Reserved | Must be 0. |
2	BLOCK_CNT	uint32	Total number (M) of contiguous memory blocks. On success, it will be 0.
3	BLOCK_HIGH[M]	uint32	See Table 198.
3+M	BLOCK_LOW[M]	uint32	See Table 198.

4.16.17 Service: TEE_REGISTER_FOR_LIFECYCLE_INFO (SERVICE_ID: 0x0F)

When a hypervisor is present in a domain, EEs, as VMs, can be created and destroyed at runtime. The lifecycle services are meant to allow other REEs and TEEs to be made aware of information about the instantiation of a new physical endpoint (usually REEs, but potentially also TEEs) when they are created, their destruction or a change in their identity, for example as an effect of progressing in a chain of bootloaders.

They complement the TEE_PROBE_SYSTEM service, which provides information on the whole system at the moment it is invoked, by allowing REEs and TEEs to stay up to date with the state of whole system as it changes over time.

The TEE_ON_START_INFO, TEE_ON_SHUTDOWN_INFO and TEE_ON_CHANGED_INFO differ from other services in this service group by being invoked by the framework itself and delivered to the endpoints which have recorded their interest in receiving REE/TEE lifecycle information (via the TEE_REGISTER_FOR_LIFECYCLE_INFO service). They then differ from RPMI notifications by being synchronous invocations from the framework, which requires them to be processed by endpoints before subsequent operations can take place.

These services are invoked by the framework in a synchronous manner, and for all endpoints which have registered to receive the REE/TEE lifecycle data, the framework will guarantee that:

• No message from a newly created or changed REE/TEE is delivered to the receiving endpoint until it has completed the processing of the TEE_ON_START_INFO service.
• No message from a destroyed EE is delivered to the receiving endpoint after the framework initiate the delivery the TEE_ON_SHUTDOWN_INFO (or until a REE/TEE with the same identifier is created again at a later time).
• Lifecycle services are strictly serialized, specifically:
  • They are delivered in the same order for all receivers.
  • In case of a receiver gracefully yielding to the framework during the processing of a message (by returning the RPMI_ERR_IO error code), no further message will be presented to it except the message which was yielded, until its processing is completed with a non-yielding response.

Table 212. Request Data

Word	Name	Type	Description
0	SYSINFO_FORMAT	uint32	The format in which the data shall be returned by the framework when a new endpoint is created or changed. Needs to be one of the formats (i.e. a single bit) returned by the TEE_PROBE_FEATURES service.
1	FLAGS	uint32	| Bits | Field | Description | | --- | --- | --- | | [31:31] | REGISTER | 0b0: Deregister from lifecycle services. 0b1: Register to lifecycle services. | | [30:0] | Reserved | Must be 0. |

Table 213. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Framework has successfully recorded the new registration status for the calling endpoint. | | RPMI_ERR_INVALID_PARAM | - Caller already registered or deregistered. - Unsupported format. | - Other errors Table 6.

4.16.18 Service: TEE_ON_START_INFO (SERVICE_ID: 0x10)

The framework will send this message to an endpoint which has previously registered to receive information about lifecycle events when a new REE or TEE is started and registered on the framework.

note

The mechanisms by which REEs and TEEs are started, stopped, registered or deregistered from the framework are outside the scope of this specification.

The framework guarantees that this message can only come from the framework itself, and will reject any attempt by an endpoint to send it.

Table 214. Request Data

Word	Name	Type	Description
0	ENDPOINT_ID	uint32	Unique identifier of the REE/TEE.
1	DATA_LEN	uint32	Length (N) in bytes of the returned data containing the description of the newly created REE/TEE.
2	DATA[N]	uint8	Data describing the newly created REE/TEE, in the requested format.

Table 215. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Data for newly created REE/TEE has been processed. | | RPMI_ERR_IO | This error can only be returned by a TEE. The TEE received a foreign interrupt and could not complete the processing of the data. The Framework is expected to resend the message after the interrupt has been delivered to its target. | The endpoint is not allowed to return any other error. Any error returned other then the above will be interpreted by the framework as the endpoint malfunctioning and will be dealt with by the framework in an implementation defined manner.

4.16.19 Service: TEE_ON_SHUTDOWN_INFO (SERVICE_ID: 0x11)

The framework will send this message to an endpoint which has previously registered to receive information about lifecycle events when an REE or TEE is shutdown. It is also called when an endpoint decided to programmatically exit the framework by invoking the TEE_EXIT service, or when the framework detects the endpoint is malfunctioning and disconnects it from the framework itself.

The framework guarantees that this message can only come from the framework itself, and will reject any attempt by an endpoint to send it.

Table 216. Request Data

Word	Name	Type	Description
0	ENDPOINT_ID	uint32	Unique identifier of the REE/TEE.

Table 217. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | The endpoint has processed the information. | | RPMI_ERR_IO | This error can only be returned by a TEE. The TEE was interrupted by an interrupt and could not complete the processing of the data. The Framework is expected to resend the message after the interrupt has been delivered to its target. | The endpoint is not allowed to return any other error. Any error returned other then the above will be interpreted by the framework as an endpoint malfunctioning and will be dealt with by the framework in an implementation defined manner.

4.16.20 Service: TEE_ON_CHANGED_INFO (SERVICE_ID: 0x12)

The framework will send this message to an endpoint which has previously registered to receive information about lifecycle events when an existing REE/TEE changes its own internal configuration/runtime (typically as a result of progressing through the bootloader chain).

The framework guarantees that this message can only come from the framework itself, and will reject any attempt by an endpoint to send it.

Same as Table 214.

Same as Table 215.

4.16.21 Service: TEE_CALL (SERVICE_ID: 0x13)

This service is used to send data synchronously from an endpoint (in a REE or TEE) to a TEE.

The target TEE will execute on the same hart as the originator of the request until a response is returned.

The framework will validate the passed fields, route the message to the target endpoint and return the response to the caller.

note

The RPMI TEE Service Group does not define any synchronous mechanism for a TEE to send data to an REE, because of the scheduling constraints in the REE/TEE relationship.

Table 218. Request Data

Word	Name	Type	Description
0	SENDER_ID	uint32	Identifier of the endpoint which is sending the request. The framework will verify that this endpoint is associated with the REE/TEE which this service is being called from.
1	TARGET_ID	uint32	Identifier of the endpoint that implements the requested service.
2:5	SERVICE	uint8[16]	Bytes[0..15] of the UUID identifying the requested service.
6	SERVICE_DATA_LEN	uint32	Length (N) in bytes of the service data
7	SERVICE_DATA[N]	uint8	Service data.

Table 219. Response Data

Word	Name	Type	Description
0	STATUS	int32	Return error code. All error codes returned in the TEE_CALL Response Data are set by the framework. | Error Code | Description | | --- | --- | | RPMI_SUCCESS | Data successfully delivered and response data returned. | | RPMI_ERR_INVALID_PARAM | Invalid SENDER_ID, TARGET_ID or SERVICE. | | RPMI_ERR_BUSY | The target endpoint is busy and cannot handle the request. | | RPMI_ERR_IO | The target endpoint aborted while processing the request. | - Other errors Table 6.
1	SERVICE_RSP_LEN	uint32	Length (N) in bytes of the service response.
2	SERVICE_RSP[N]	uint8	Service response.