Processor SDK RTOS RM

From Texas Instruments Wiki
Jump to: navigation, search


RTOS Software Developer Guide RM



Overview

User Interface

Application

Debug


Introduction

The Resource Manager (RM) is delivered as part of Processor-SDK as a means for managing system resource contentions. RM has the ability to allocate system resources within a software architecture based on sets of allocation rules. Resources can be allocated to anything from a device core, to an OS task or process, to a specific software module. RM's resource management is defined by the RM configuration parameters and how RM is integrated within a software framework. The RM source code is device agnostic. The RM configuration parameters are device specific allowing RM to function on any processor capable of compiling and executing a C binary.

RM Instance Types

Resource Manager is an instance-based architecture. Integrating RM into a system consists of creating a set of RM instances, connecting these instances via message-passing mechanisms, and then using the instances to request resources for cores, processes, tasks, modules, etc. There are no restrictions on where a RM instance can be created as long as the means exist to connect the instance to other RM instances within the system.

There are five instance types

  1. Server: Manages all defined system resources. Services resource requests received from connected Client Delegates and Clients.
  2. Client Delegate (CD): Acts as a low-request-latency proxy for the RM Server, managing resources provided by the RM Server. Services resource requests received from connected Clients.
  3. Client: Front-end for receiving/responding to resource requests from application. Forwards resource requests to Server, or CD, for servicing. Returns allocated resources to application once response is received from Server or CD.
  4. Shared Server: Same as the standard Server except all resource data structures are stored in shared memory allowing direct access from Shared Client instances.
  5. Shared Client: Same as Client except has direct access to the Server resource data structures via shared memory. Useful for low latency requests but not as robust from a software architecture perspective given shared memory MUST be available and used in order for Shared Server-Clients to function.

Driver Configuration

Resource Configuration

The RM Server instance must be provided a resource list and allocation policy at initialization time. The resource list and allocation policy are specified in the open source flattened device tree format. Device specific resource list and allocation policy files are provided in [PDK_INSTALL_PATH]/packages/ti/drv/rm/device/[SoC]/.

The Client Delegate and Client instances do not require a resource list and allocation policy at initialization.

Transport Configuration

RM instances must be attached to one another using a message passing mechanism. This mechanism can be shared memory, software/hardware queues, sockets or any other method capable of sending and receiving data packets between endpoints on the SoC.

An example transport implementation used by many PDK test applications is available in [PDK_INSTALL_PATH]/packages/ti/drv/rm/test/rm_transport_setup.c. The implementation uses an IPC shared memory transport to connect an RM Server to RM Clients on multiple DSP cores.

APIs

RM instance init/delete/status API reference for application:

#include <ti/drv/rm/rm.h>

RM instance transport API reference for application:

#include <ti/drv/rm/rm_transport.h>

RM instance service request/response API reference for application:

#include <ti/drv/rm/rm_services.h>

RM Server interface API reference for application:

#include <ti/drv/rm/rm_server_if.h>

Tests

Name
Description
Expected Results
RM DSP BIOS Test application

Unit Test application exercising APIs and the different service request/response mechanisms across the Server, Client Delegate, and Client instances.

Application successfully completes on two DSP cores.

RM Memory DSP BIOS Test application

Unit Test application to test for memory leaks during resource request/free operations.

Application successfully completes with no memory leaks on two DSP cores.

RM Shared DSP BIOS Test application

Unit Test application exercising Shared Server/Client APIs and resource allocation in a Shared Server/Client architecture.

Application successfully completes with no memory leaks on two DSP cores.

RM DSP BIOS Multi-Threaded Test application

Unit Test application verifying service request/response mechanism in a multi-threaded architecture.

Application successfully completes with no memory leaks on a single DSP core.

RM ARM Linux Test application

Unit Test application exercising APIs and the different service request/response mechanisms across the Server, Client Delegate, and Client instances.

Application successfully completes when run from Linux user-space.

RM ARM Linux Multi-Threaded Test application

Unit Test application verifying service request/response mechanism in a multi-threaded architecture.

Application successfully completes when run from Linux user-space.

Combined DSP BIOS & ARM Linux Test application

Unit Test application verifying service request/response mechanism over a heterogeneous processor boundary. RM Clients on two DSP cores request resources from an RM Server running in Linux user-space.

Application successfully completes with no memory leaks on two DSP cores.

Additional References

Document Location
API Reference Manual $(TI_PDK_INSTALL_DIR)\packages\ti\drv\rm\docs\doxygen\html\index.html
Release Notes $(TI_PDK_INSTALL_DIR)\packages\ti\drv\rm\docs\ReleaseNotes_RM.pdf
Resource Manager User Guide Processor_SDK_Resource_Manager