diff --git a/src/intro.adoc b/src/intro.adoc index 6c31367..6622c09 100644 --- a/src/intro.adoc +++ b/src/intro.adoc @@ -48,6 +48,7 @@ An RPMI agent is an implementation instance of the RPMI Messaging Protocol and T agent in S-mode for some RPMI services, an M-mode RPMI agent also enhances security. +[#img-transport-topologies] .Transport for M-Mode and S-Mode image::transport-topologies.png[width=800,height=800] diff --git a/src/message-protocol.adoc b/src/message-protocol.adoc index 152f3c7..8b57a4a 100644 --- a/src/message-protocol.adoc +++ b/src/message-protocol.adoc @@ -39,7 +39,7 @@ each service dictates if acknowledgment is mandatory or not. ==== NOTIFICATIONS Notifications are messages which are sent asynchronously from PuC to AP to notify about the events happening in the system related to various service -groups. Notifications are covered in detail in below section <> +groups. Notifications are covered in detail in below <>. === Message Format On the AP side, each call to a service results in a message request to the PuC. @@ -143,8 +143,8 @@ can include the system states, power states, errors/faults in the system etc. Action taken on behalf of any event notification is completely dependent on the AP and they can be ignored. Platform Microcontroller may combine multiple events into a single message depending on the available space in the message data. -Individual events may also have additional data associated. _Figure 3.4_ shows -the notification message format. +Individual events may also have additional data associated. <> +shows the notification message format. Each service group will have a notification service with fixed `SERVICE_ID=0x00` across every service group. Notifications are sent from PuC to AP with events @@ -174,6 +174,8 @@ header. Event data and its format depend on the service group and details are present in respective service group sections. +[#img-notification-format] +.Notification Format image::notification-format.png[500,600] [#table_notification_message_format] diff --git a/src/srvgrp-base.adoc b/src/srvgrp-base.adoc index 33d0be6..e7c4323 100644 --- a/src/srvgrp-base.adoc +++ b/src/srvgrp-base.adoc @@ -64,7 +64,7 @@ Below table lists the services in this group: ==== Base Notifications Platform Microcontroller can send asynchronous notifications to AP via this service. There can be multiple types of events classified in the Base service -group which can be combined into a single message as depicted in _Figure 3.5_. +group which can be combined into a single message as depicted in <>. If Platform Microcontroller has multiple events for the same type, Platform Microcontroller can send the single instance of that event that was received last. [#table_base_srvgroup_events] diff --git a/src/srvgrp-hart-state-management.adoc b/src/srvgrp-hart-state-management.adoc index dc1fa55..d934d35 100644 --- a/src/srvgrp-hart-state-management.adoc +++ b/src/srvgrp-hart-state-management.adoc @@ -113,7 +113,7 @@ processor. [cols="5,5"] !=== ! *Error Code* ! *Description* -! RPMI_SUCCESS ! Service completed successfully and hart is started. +! RPMI_SUCCESS ! Service completed successfully and hart is stopped. ! RPMI_ERROR_DENIED ! Not allowed due to current hart state which is platform specific !=== @@ -147,7 +147,7 @@ _Only used for non-retentive suspend types._ [cols="6,5"] !=== ! *Error Code* ! *Description* -! RPMI_SUCCESS ! Service completed successfully and hart is started. +! RPMI_SUCCESS ! Service completed successfully. ! RPMI_ERROR_INVALID_PARAMETER ! Invalid SUSPEND_TYPE. !=== - Other errors <> @@ -173,7 +173,7 @@ This service gets the running status of a Hart. [cols="6,5"] !=== ! *Error Code* ! *Description* -! RPMI_SUCCESS ! Notifications are subscribed successfully. +! RPMI_SUCCESS ! Service completed successfully. ! RPMI_ERROR_INVALID_PARAMETER ! Invalid HART_ID. !=== - Other errors <> @@ -211,7 +211,7 @@ This service gets the list of harts with a specified Hart ID start index [cols="6,5"] !=== ! *Error Code* ! *Description* -! RPMI_SUCCESS ! Notifications are subscribed successfully. +! RPMI_SUCCESS ! Service completed successfully. ! RPMI_ERROR_INVALID_PARAMETER ! Invalid START_INDEX. !=== - Other errors <> @@ -245,7 +245,7 @@ items. [cols="7,5"] !=== ! *Error Code* ! *Description* -! RPMI_SUCCESS ! Notifications are subscribed successfully. +! RPMI_SUCCESS ! Service completed successfully. ! RPMI_ERROR_INVALID_PARAMETER ! Invalid START_INDEX. !=== - Other errors <> @@ -276,7 +276,7 @@ Get attributes of a suspend type. [cols="7,5"] !=== ! *Error Code* ! *Description* -! RPMI_SUCCESS ! Notifications are subscribed successfully. +! RPMI_SUCCESS ! Service completed successfully. ! RPMI_ERROR_INVALID_PARAMETER ! Invalid SUSPEND_TYPE. !=== - Other errors <> diff --git a/src/transport.adoc b/src/transport.adoc old mode 100644 new mode 100755 index fccb15e..a8cdc83 --- a/src/transport.adoc +++ b/src/transport.adoc @@ -9,8 +9,8 @@ a privilege level of a set of APs and one PuC. There can be multiple RPMI transport instances between a set of APs and one PuC. For example: there can be a separate transport instance between each privilege level of APs and one PuC. A platform can also have multiple PuCs with each having its own set of -RPMI transport to communicate with the APs. The _Figure 1.2_ above shows -different topologies of RPMI transport. +RPMI transport to communicate with the APs. The <> +above shows different topologies of RPMI transport. The physical medium of an RPMI transport can be shared memory or some other medium. This specification only defines a shared memory based RPMI @@ -86,11 +86,12 @@ and ==== Layout of Shared Memory The shared memory RPMI Transport defines four shared memory based queues for bidirectional synchronous/asynchronous communication between an AP and PuC. -The detailed layout of the shared memory and queues is shown in Figure 2.1. All -queues in the shared memory are contiguous and of equal size. Sequence of the queues is -arranged such that queues which enable Request-Acknowledgement for a side either -AP to PuC or vice versa are together. +The detailed layout of the shared memory and queues is shown in <>. +All queues in the shared memory are contiguous and of equal size. Sequence of +the queues is arranged such that queues which enable Request-Acknowledgement +for a side either AP to PuC or vice versa are together. +[#img-shmem-layout] .Memory Layout of Shared Memory image::shmem-layout.png[600,600]