packages/ti/drv/sciclient/soc/sysfw/binaries/system-firmware-public-documentation/_sources/1_intro/TISCI.rst.txt

   1 .. _pub_sysfw_introduction:
   2
   3 Introduction
   4 ============
   5
   6 Traditional Texas Instruments SoCs implement system control functions such as
   7 power management on each of the processing units (ARM/DSP etc).
   8 However, the traditional approach had tremendous challenges
   9 to ensure system stability. A few of the challenges include:
  10
  11 - Complex interactions between Operating Systems on heterogeneous SoCs for
  12   generic features.
  13 - Lack of centralized knowledge of system state.
  14 - Complex implementation challenges with regards to implementation of
  15   workarounds for system quirks.
  16 - Equivalent system capability entitlement on all variations of operation
  17   conditions.
  18
  19 K3 devices introduces the concept of a centralized Power, Resource and Security
  20 Management to allow mitigating the challenges of the traditional approach to
  21 system control.
  22
  23 |sysfw| is a collective term used to describe the TI Foundational Security (TIFS)
  24 and Resource Management (RM)/ Power Management (PM) services.
  25
  26 |sysfw| executes on the Security Manager and Device Manager Core.
  27 On K3 devices, the DMSC subsystem is the Security Manager Core in the SoC.
  28 The Device Manager core can be on the DMSC itself or the MCU R5F.
  29 The choice of whether this runs on the DMSC or the
  30 MCU R5F is based on the kind of applications the device is targeting.
  31 If the device is targetting applications, where there is a need for a dedicated
  32 HSM, the Device manager core is independent of the DMSC (which is exclusively
  33 kept for Security functions). For devices which do not have need for a dedicated
  34 security island or HSM, the device manager runs on the DMSC.
  35
  36 The following table highlights the variations
  37 of where the RM and PM execute versus the TIFS on the different K3 family of
  38 devices.
  39
  40 .. _pub_sysfw_map_per_device:
  41
  42 .. table:: TI Foundational Security Software and RM/PM SCI Server Mapping
  43
  44    +----------------+-------------------------+-------------------------+---------------------+
  45    | Device         |  TI Foundation Security | 3rd Party HSM/SHE stack |  RM/PM SCI Server   |
  46    +================+=========================+=========================+=====================+
  47    | AM65x/ DRA80x, |   DMSC (M3 based)       | NA                      |  DMSC (M3 based)    |
  48    | AM64x          |                         |                         |                     |
  49    +----------------+-------------------------+-------------------------+---------------------+
  50    | DRA82X, TDA4X  |   DMSC (M3 based)       | DMSC (M3 based)         |  Library on MCU R5* |
  51    |                |                         |                         |                     |
  52    +----------------+-------------------------+-------------------------+---------------------+
  53
  54
  55 Note, the TI provided software does not allow for a given SoC to support both HSM and non
  56 HSM applications. To know the mapping refer :ref:`pub_sysfw_map_per_device`.
  57
  58 The purpose of this document is to define the software interface for
  59 the |sysfw|. The split up of the responsibilities are:
  60
  61 - TIFS:
  62     - Responsible for Centralized Foundational Security Management. These
  63       include functions like authenticated boot, JTAG unlock etc.
  64     - Behaves like a forwarding agent for Resource Management and Power Management
  65       requests made by Secure hosts (other CPUs) in the SoC.
  66     - Behaves as a forwarding agent for Resource Management and Power Management
  67       responses from the device manager to the Secure Hosts.
  68     - Firewall Management for resources requested by both secure and non-secure
  69       hosts.
  70 - Device Manager (DMSC M3 or MCU R5F based on the device)
  71     - Responsible for servicing resource management and power management messages
  72       from secure and non-secure hosts.
  73     - Reponsible for forwarding non-secure host requests to set the processor
  74       boot control or firewall configuration for safety applications to the DMSC.
  75     - Responsible for forwaring response recieved from the DMSC to non-secure
  76       hosts for the above forwarded messages.
  77
  78 Centralized Device Management
  79 -----------------------------
  80
  81 In the Power management domain, the centralized power management takes into account that every device has:
  82
  83 - Different power and clock domains.
  84 - Derivatives have slight differences in the clocking architecture based on combination of modules.
  85
  86 It provides an OS agnostic interface for power management allowing peripherals and clocks to be
  87 handled by multiple processors running different OSes (Linux, RTOS, etc.). The centralized power
  88 management entity aims to provide the same control for power and clock setting across all OSes.
  89
  90 Centralized Resource management is driven by the centralized DMA architecture. Key components
  91 of the centralized resource management include:
  92
  93 - Navigator Subsystem: Collection of Data movement components
  94 - UDMA (Unified DMA), PKTDMA, BCDMA: DMA engine for standard parallel DMA (CBA) or PSI/stream based IP.
  95 - RA (Ring Accelerator): Queue management providing abstract SW view to HW DMA queues
  96 - Proxy: Allows efficient access to RA queues, also enables address containment/virtualization (access RA via separate MMU page / regions)
  97 - Interrupt & events handling: Interrupt aggregators and Interrupt routers
  98
  99 Centralized Foundational Security Management
 100 --------------------------------------------
 101
 102 The DMSC M3 subsystem in the K3 family of devices is responsible to run the software stack for
 103 the device foundational security management. This software entity is responsible for:
 104
 105 - Foundational device security in DMSC
 106
 107    - Secure boot with secure keys/root-of-trust, Security configuration and Debug unlock
 108    - RSA or ECC Root Keys, AES symmetric key
 109    - Utilizes PKA, SHA2 and AES Crypto accelerators
 110    - Basic security functionality to extend root of trust (optional)
 111    - Authenticated Key ring to extend root-of-trust keys
 112    - SYSFW and Bootloader Rollback protection via eFuse
 113    - Device Unique Key / Key Derivation to support 3P stacks
 114
 115 The centralized power, resource and security management entity is henceforth
 116 refered to as System Control Entity and System Firmware interchangeably.
 117 Any software and hardware entity which communicates with the System Control
 118 Entity is refered to as "Host".
 119 The block diagram of the System Controller Entity or System firmware is as below:
 120
 121 .. figure:: ../img/blockDiagram.png
 122
 123     System Controller Entity interacting with Other Hosts
 124
 125 Architecture Change between SDK 7.0 and SDK 7.1
 126 -------------------------------------------------
 127
 128 The SDK 7.1 (v2020.08 of |sysfw|) firmware is not compatible with SDK 7.0.
 129 (v2020.04 of the |sysfw|) and earlier releases in terms of location of the binaries.
 130 Note the TISCI interface is the same as what is available on earlier releases.
 131
 132 The following figure describes the typical software stack and highlights the
 133 difference in the location of execution of centralized services from |sysfw|.
 134
 135 .. figure:: ../img/softwareStack.png
 136
 137     DMSC Firmware Change | TDA4VM, DRA829, DRA821
 138
 139 Purpose of DMSC firmware change
 140
 141 - Secure HSM functions can run on a DMSC Security Island
 142 - Free a main domain R5F for general customer use.
 143 - Enables MCU Only mode with HSM functions on DMSC
 144 - Lockstep Safety R5F runs safety critical PM & RM functions.
 145
 146 The Memory / CPU requirement is minimal (< 150 KB, < 10 MHz) so having the RM
 147 and PM execute on the MCU R5f has minimal impact to user applications.
 148
 149 The SW impact summary for the end users is as given below. Kindly note since the
 150 API interface remains the same, the rest of the documentation for |sysfw| is the
 151 same between SDK 7.1 and 7.0. Refer to the SDK documentation to know more about
 152 the changes required for integration of the SCISERVER and RM/PM on the MCU R5F.
 153
 154 .. figure:: ../img/swimpact.png
 155
 156     SW Impact for end-users between SDK 7.0 and SDK 7.1
 157
 158 Further Reading
 159 ---------------
 160
 161 - In :ref:`pub_tisci_msg_doc`, we describe how one can communicate with the system control entity and the various messages that can be used.
 162 - In :ref:`pub_boardcfg_messages_index`, we desribe the format and content of the boardcfg messages that does onetime configuration of |sysfw|.
 163 - In :ref:`pub_interpret_trace`, we define trace data format.
 164 - In :ref:`pub_soc_family_doc`, we provide information specific to each SOC that is required using the TISCI messages described in :ref:`pub_tisci_msg_doc`.
 165 - In :ref:`pub_user_guides`, we provide user guides for the more complex scenarios.
 166
 167 Glossary
 168 --------
 169
 170 The following list defines the different acronyms and terms used in the rest of the document:
 171
 172 - **TIFS** (Texas Instruments Foundational Security): Foundational security software provided from TI.
 173 - **TISCI** (Texas Instruments System Controller Interface) : API interface to TIFS, RM/PM services.
 174 - **DM** (Device Manager) : Collective term used to refer to the Resource Management and Power Management Software.
 175 - **RM** (Resource Management): Term used to refer to the Resource Management Software.
 176 - **PM** (Power Management): Term used to refer to the Power Management Software.
 177 - **SYSFW** (System Firmware): Collective term used to refer to the TIFS and RM/PM Software.
 178
 179