Traditional Texas Instruments SoCs have implemented system control functions such as power management within operating systems on each of the processing units (ARM/DSP). However, such a traditional approach has had tremendous challenges to ensure system stability. Few of the challenges faced include:
Device Management (DM) and TI Foundational Security Software(TIFS) attempt to resolve these issues by being a consistent component of Keystone 3 SoC architecture performing the role of a centralized SoC power, security and device management controller.
In effect, this is a microcontroller and runs a safety and security certified firmware that provides services to the rest of the OSes/Software running on various other processors on the SoC.
DM controls the power management of the device, hence is responsible for bringing the device out of reset, enforce clock and reset rules. DM power management functions are critical to bring device to low power modes, for example DeepSleep, and sense wake-up events to bring device back online to active state.
The TIFS firmware manages SoC central security resources. The security subsystem provides APIs to other software entities to avail these features in a controlled and secure way. The security management firmware is subdivided into modules listed below:
The DM firmware Resource Management (RM) (sub) system manages SoC shared resources. RM manages access and configuration of shared resources amongst SoC processing entities. RM provides a set of interfaces over which SoC processing entities can allocate and free access to shared resources.
The resource management firmware is subdivided into modules listed below:
DM is a "black box" with respect to the other processing entities (ARM/DSP) on the SoC. Communication with DM occurs over a messaging protocol called the Texas Instruments System Control Interface (TI-SCI). TI-SCI is a predefined request-response protocol that provides access to the various services provided by DM.
The actual messaging hardware block varies depending on SoC, but typical examples include "Proxy over message manager" and "Secure Proxy over Ring Accellerator". These communication mechanisms are standardized and secured by DM firmware prior to operation.
The request/response format is described overall as in Figure 2 . The message type describes the service to be performed and is operated on depending on few attributes including privileges allowed and operational state of the SoC.
Type | Byte Index | Data Type | Header |
---|---|---|---|
TISCI Header | [0:1] | U16 | Message_type |
[2] | uint8_t | Host | |
[3] | uint8_t | Sequence_id | |
[4:7] | U32 | Flags | |
Payload | Depends on type of message | Payload Fields |
Sub Modules | |
Sciclient Interface to DMSC ROM | |