Approved version. Approved on: 15:27, 4 February 2020
You are viewing an old version of this page. Return to the latest version.
Difference between revisions of "STM32MP15 RCC internal peripheral"
| [quality revision] | [quality revision] |
|
m
|
Contents
1 Article purpose[edit]
The purpose of this article is to:
- briefly introduce the RCC peripheral and its main features
- indicate the level of security supported by this hardware block
- explain, when necessary, how to configure the RCC peripheral.
2 Peripheral overview[edit]
The RCC peripheral is used to control the internal peripherals, as well as the reset signals and clock distribution. The RCC gets several internal (LSI, HSI and CSI) and external (LSE and HSE) clocks. They are used as clock sources for the hardware blocks, either directly or indirectly, via the four PLLs (PLL1, PLL2, PLL3 and PLL4) that allow to achieve high frequencies.
2.1 Features[edit]
Refer to the STM32MP15 reference manuals for the complete list of features, and to the software components, introduced below, to see which features are really implemented.
2.2 Security support[edit]
The RCC is a secure peripheral. There are two levels of security, which are controlled via two bits in the RCC_TZCR register (only accessible in secure mode):
- TZEN allows to set some RCC registers in secure mode, in particular registers for configuring PLL1 and PLL2, in order to secure a TrustZone perimeter for the Cortex®-A7 secure core and its peripherals.
- MCKPROT allows extending the TZEN secure clock control perimeter to PLL3 and to the MCU subsystem, so to the Cortex®-M4 and its bus clock.
Please note that all RCC registers can be read from the non-secure world.
3 Peripheral usage and associated software[edit]
3.1 Boot time[edit]
The RCC security level differs for each boot chain:
- the trusted boot chain sets TZEN to 1 an MCKPROT to 0
- the basic boot chain sets TZEN to 0 an MCKPROT to 0
The RCC is used by all the boot components: the ROM code, the FSBL, the SSBL and up to the Linux® kernel. Nevertheless, the main initialization step is performed by the FSBL that is responsible for the clock tree initialization: it consists in configuring all the input clocks, the PLL and the clock sources that are selected as kernel clocks for all peripherals. The whole configuration is carried out by the device tree.
The STM32CubeMX tool allows configuring in one place the clock tree that will be applied at boot time and used at runtime, so it is highly recommended to use it to generate your device tree. Moreover, the STM32CubeMX integrates all the information documented in the STM32MP15 reference manuals, making this configuration step straighforward.
3.2 Runtime[edit]
3.2.1 Overview[edit]
The RCC peripheral is shared at runtime:
- the Arm® Cortex®-A7 secure core controls all the secure registers (refer to TZEN and MCKPROT bit descriptions) through the RCC OP-TEE driver. The access to some secure registers from the Cortex®-A7 non-secure core can be achieved via runtime secure services implemented in the secure monitor (from the OP-TEE if it is present, otherwise from the TF-A).
- the Arm® Cortex®-A7 non-secure core controls the clock management via the clock framework, and the reset management via the reset framework in Linux®.
- the Arm® Cortex®-M4 core controls all the clock and reset managements in STM32Cube with the RCC HAL driver
Concurrent control from each context is possible because the above managements are performed via independent registers.
3.2.2 Software frameworks[edit]
Internal peripherals software table template
| Power & Thermal | RCC | OP-TEE RCC driver | Reset framework
Clock framework | STM32Cube RCC driver | |- |}
3.2.3 Peripheral configuration[edit]
The configuration is applied by the firmware running in the context to which the peripheral is assigned. The configuration can be done alone via the STM32CubeMX tool for all internal peripherals, and then manually completed (particularly for external peripherals), according to the information given in the corresponding software framework article.
3.2.4 Peripheral assignment[edit]
Internal peripherals assignment table template
| rowspan="1" | Power & Thermal | rowspan="1" | RCC | RCC | ✓ | ✓ | ✓ | |-
|}
4 How to go further[edit]
The RCC is interfaced with the HDP internal peripheral, thus offering the flexibility to monitor the main RCC state signals on the debug pins.
Please refer to the STM32MP15 reference manuals for the full list of signals that can be monitored.
5 References[edit]
==Article purpose== The purpose of this article is to: * briefly introduce the RCC peripheral and its main features * indicate the level of security supported by this hardware block * explain, when necessary, how to configure the RCC peripheral. ==Peripheral overview== The '''RCC''' peripheral is used to control the internal peripherals, as well as the '''reset''' signals and '''clock''' distribution. The RCC gets several internal (LSI, HSI and CSI) and external (LSE and HSE) clocks. They are used as clock sources for the hardware blocks, either directly or indirectly, via the four PLLs (PLL1, PLL2, PLL3 and PLL4) that allow to achieve high frequencies. ===Features=== Refer to the [[STM32MP15 resources#Reference manuals|STM32MP15 reference manuals]] for the complete list of features, and to the software components, introduced below, to see which features are really implemented. ===Security support=== The RCC is a '''secure''' peripheral. There are two levels of security, which are controlled via two bits in the RCC_TZCR register (only accessible in secure mode): * '''TZEN''' allows to set some RCC registers in secure mode, in particular registers for configuring PLL1 and PLL2, in order to secure a TrustZone perimeter for the Cortex<sup>®</sup>-A7 secure core and its peripherals. * '''MCKPROT''' allows extending the TZEN secure clock control perimeter to PLL3 and to the MCU subsystem, so to the Cortex<sup>®</sup>-M4 and its bus clock. Please note that all RCC registers can be read from the non-secure world. ==Peripheral usage and associated software== ===Boot time=== The RCC security level differs for each [[Boot chainschain overview#STM32MP boot chainssequence|boot chain]]: * the trusted boot chain sets TZEN to 1 an MCKPROT to 0 * the basic boot chain sets TZEN to 0 an MCKPROT to 0<br /> The RCC is used by all the [[Boot chainschain overview|boot components]]: the ROM code, the FSBL, the SSBL and up to the Linux<sup>®</sup> kernel. Nevertheless, the main initialization step is performed by the FSBL that is responsible for the [[STM32MP15 clock tree|clock tree]] initialization: it consists in configuring all the input clocks, the PLL and the clock sources that are selected as kernel clocks for all peripherals. The whole configuration is carried out by the [[Device tree|device tree]].<br /><br /> The [[STM32CubeMX]] tool allows configuring in one place the [[STM32MP15 clock tree|clock tree]] that will be applied at boot time and used at runtime, so it is highly recommended to use it to generate your [[Device tree|device tree]]. Moreover, the [[STM32CubeMX]] integrates all the information documented in the [[STM32MP15 resources#Reference manuals|STM32MP15 reference manuals]], making this configuration step straighforward. ===Runtime=== ====Overview==== The RCC peripheral is shared at runtime: * the Arm<sup>®</sup> Cortex<sup>®</sup>-A7 secure core controls all the secure registers (refer to TZEN and MCKPROT bit descriptions) through the [[OP-TEE overview|RCC OP-TEE driver]]. The access to some secure registers from the Cortex<sup>®</sup>-A7 non-secure core can be achieved via runtime secure services implemented in the secure monitor (from the [[OP-TEE overview|OP-TEE]] if it is present, otherwise from the [[TF-A overview|TF-A]]). * the Arm<sup>®</sup> Cortex<sup>®</sup>-A7 non-secure core controls the clock management via the [[Clock overview|clock framework]], and the reset management via the [[Reset overview|reset framework]] in Linux<sup>®</sup>. * the Arm<sup>®</sup> Cortex<sup>®</sup>-M4 core controls all the clock and reset managements in STM32Cube with the [[STM32CubeMP1 architecture|RCC HAL driver]]<br /> Concurrent control from each context is possible because the above managements are performed via independent registers.<br /> {{InternalInfo| Note that the peripherals that are securable thanks to the [[ETZPC internal peripheral|ETZPC]] keep their reset and clock enable management secured in RCC, whatever the [[ETZPC internal peripheral|ETZPC]] configuration. As a consequence, a secure service is required for reset and clock enable management when such peripherals are set non-secure. This service can be avoided on STM32MP15 Rev.B for clock enable management since the enable register RCC_MC_ copies can be used to set a clock from the non-secure world (Cortex<sup>®</sup>-A7 non-secure or Cortex<sup>®</sup>-M4) for an [[ETZPC internal peripheral|ETZPC]] securable peripheral.}} ====Software frameworks==== {{:Internal_peripherals_software_table_template}} | Power & Thermal | [[RCC internal peripheral|RCC]] | [[OP-TEE_overview|OP-TEE RCC driver]] | [[Reset overview|Reset framework]]<br />[[Clock overview|Clock framework]] | [[STM32CubeMP1 architecture|STM32Cube RCC driver]] | |- |} ====Peripheral configuration==== The configuration is applied by the firmware running in the context to which the peripheral is assigned. The configuration can be done alone via the [[STM32CubeMX]] tool for all internal peripherals, and then manually completed (particularly for external peripherals), according to the information given in the corresponding software framework article. ====Peripheral assignment==== {{:Internal_peripherals_assignment_table_template}}<onlyinclude> | rowspan="1" | Power & Thermal | rowspan="1" | [[RCC internal peripheral|RCC]] | RCC | <span title="system peripheral" style="font-size:21px">✓</span> | <span title="system peripheral" style="font-size:21px">✓</span> | <span title="system peripheral" style="font-size:21px">✓</span> | |-</onlyinclude> |} ==How to go further== The RCC is interfaced with the [[HDP internal peripheral]], thus offering the flexibility to monitor the main RCC state signals on the debug pins. Please refer to the [[STM32MP15 resources#Reference manuals|STM32MP15 reference manuals]] for the full list of signals that can be monitored. ==References==<references/> <noinclude> [[Category:Power and Thermal peripherals]] {{PublicationRequestId | 9287 | 2018-10-22 | AnneJ}} {{ArticleBasedOnModel | Internal peripheral article model}}</noinclude>
| Line 21: | Line 21: | ||
==Peripheral usage and associated software== |
==Peripheral usage and associated software== |
||
===Boot time=== |
===Boot time=== |
||
| − | The RCC security level differs for each [[Boot |
+ | The RCC security level differs for each [[Boot chain overview#STM32MP boot sequence|boot chain]]: |
* the trusted boot chain sets TZEN to 1 an MCKPROT to 0 |
* the trusted boot chain sets TZEN to 1 an MCKPROT to 0 |
||
* the basic boot chain sets TZEN to 0 an MCKPROT to 0 |
* the basic boot chain sets TZEN to 0 an MCKPROT to 0 |
||
<br /> |
<br /> |
||
| − | The RCC is used by all the [[Boot |
+ | The RCC is used by all the [[Boot chain overview|boot components]]: the ROM code, the FSBL, the SSBL and up to the Linux<sup>®</sup> kernel. Nevertheless, the main initialization step is performed by the FSBL that is responsible for the [[STM32MP15 clock tree|clock tree]] initialization: it consists in configuring all the input clocks, the PLL and the clock sources that are selected as kernel clocks for all peripherals. The whole configuration is carried out by the [[Device tree|device tree]].<br /><br /> |
The [[STM32CubeMX]] tool allows configuring in one place the [[STM32MP15 clock tree|clock tree]] that will be applied at boot time and used at runtime, so it is highly recommended to use it to generate your [[Device tree|device tree]]. Moreover, the [[STM32CubeMX]] integrates all the information documented in the [[STM32MP15 resources#Reference manuals|STM32MP15 reference manuals]], making this configuration step straighforward. |
The [[STM32CubeMX]] tool allows configuring in one place the [[STM32MP15 clock tree|clock tree]] that will be applied at boot time and used at runtime, so it is highly recommended to use it to generate your [[Device tree|device tree]]. Moreover, the [[STM32CubeMX]] integrates all the information documented in the [[STM32MP15 resources#Reference manuals|STM32MP15 reference manuals]], making this configuration step straighforward. |
||