Difference between revisions of "RTC internal peripheral"

[quality revision] [quality revision]
 
 
Template:ArticleMainWriter Template:ReviewersList Template:ArticleApprovedVersion

1 Article purpose[edit]

The purpose of this article is to

  • briefly introduce the RTC peripheral and its main features
  • indicate the level of security supported by this hardware block
  • explain how it can be allocated to the three runtime contexts and linked to the corresponding software components
  • explain, when needed, how to configure the RTC peripheral.

2 Peripheral overview[edit]

The RTC peripheral is used to provide the date and clock to the application. It supports programmable alarms and wake up capabilities.

2.1 Features[edit]

Refer to STM32MP15 reference manuals for the complete list of features, and to the software components, introduced below, to know which features are really implemented.

2.2 Security support[edit]

The RTC peripheral is a secure peripheral.

3 Peripheral usage and associated software[edit]

3.1 Boot time[edit]

By default after a backup domain power-on reset (performed at boot time), all RTC registers can be read or written in both secure and non-secure modes.
In OpenSTLinux distribution, the first stage bootloader (FSBL, running in secure mode) keeps this default configuration, leaving full control to Linux® at runtime.

The RTC peripheral is able to generate two interrupts:

  • A secure interrupt, connected to the Arm® Cortex®-A7 GIC, not used in OpenSTLinux distribution.
  • A non-secure interrupt, connected both to Arm® Cortex®-A7 GIC and Cortex-M4 NVIC: this interrupt is used on Linux® and by default in OpenSTLinux distribution.

The RTC peripheral is part of the backup domain which reset and clock are controlled via the RCC by the first stage bootloader (FSBL, running in secure mode) at boot time.
The RTC reset occurs when the backup domain is reset. To avoid clearing the TAMP register contents, this is only done on cold boot, not on wake up.

3.2 Runtime[edit]

3.2.1 Overview[edit]

The RTC peripheral can be allocated to the Arm® Cortex®-A7 non-secure core to be used under Linux® with RTC framework.

3.2.2 Software frameworks[edit]

Domain Peripheral Software components Comment
OP-TEE Linux STM32Cube
Core RTC Linux RTC framework

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 STM32CubeMX tool for all internal peripherals, and then manually completed (especially for external peripherals) according to the information given in the corresponding software framework article.

For Linux kernel configuration, please refer to RTC device tree configuration.

3.2.4 Peripheral assignment[edit]

Internal peripherals

Check boxes illustrate the possible peripheral allocations supported by STM32 MPU Embedded Software:

  • means that the peripheral can be assigned () to the given runtime context.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

Refer to How to assign an internal peripheral to a runtime context for more information on how to assign peripherals manually or via STM32CubeMX.
The present chapter describes STMicroelectronics recommendations or choice of implementation. Additional possiblities might be described in STM32MP15 reference manuals.

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
Cortex-M4

(STM32Cube)
Core RTC RTC RTC is mandatory to resynchronize STGEN after exiting low-power modes.


<noinclude>

{{ArticleBasedOnModel| [[Internal peripheral article model]]}}
{{ArticleMainWriter|AmelieD}}
{{ReviewersList | AmelieD, GeraldB}}
{{ArticleApprovedVersion| AmelieD | AmelieD, GeraldB | No previous approved version | AnneJ - 21Jan-19 - 10398 | 21Jan'19}}
[[Category:Core peripherals]]</noinclude>

==Article purpose==
The purpose of this article is to
* briefly introduce the RTC peripheral and its main features
* indicate the level of security supported by this hardware block
* explain how it can be allocated to the three runtime contexts and linked to the corresponding software components
* explain, when needed, how to configure the RTC peripheral.

==Peripheral overview==
The '''RTC''' peripheral is used to provide the date and clock to the application. It supports programmable alarms and wake up capabilities.<br />


===Features===
Refer to [[STM32MP15 resources#Reference manuals|STM32MP15 reference manuals]] for the complete list of features, and to the software components, introduced below, to know which features are really implemented.<br>


===Security support===
The '''RTC''' peripheral is a '''secure''' peripheral.{{ReviewsComments|NSA W830 :does the modification i did , to make it similare to model , is correct<br />

ADE W830  : I'm sorry I don't catch the modification you did, what is it ?<br> NSA :W835 : it was written : "The RTC is '''secure aware'''"<br />

LDE W835: RTC is not secure, it is TrustZone-aware" as mentioned in RM, the securization is managed by IP itself, not by ETZPC<br />

GeraldB W836: "secure", "secure aware" or "trustzone aware", ... are concepts difficult to explain in the Wiki, that is why the "aware" aspect was removed from the Wiki and we only mention "secure" or "not secure". Then, we mention "(under ETZPC control)" wherever needed and this is not the case for RTC (that is in the same case as [[BSEC internal peripheral|BSEC]]) so I would simply propose "The RTC is a secure peripheral."<br/>

ADE W846: (under ETZPC control) removed.}}

==Peripheral usage and associated software==
===Boot time===
By default after a backup domain power-on reset (performed at boot time), all RTC registers can be read or written in both secure and non-secure modes.<br />

In OpenSTLinux distribution, the first stage bootloader (FSBL, running in secure mode) keeps this default configuration, leaving full control to Linux<sup>&reg;</sup> at runtime.
{{ReviewsComments|NSA W830  : below , we are here is the chapter boot time , are the paragraphes below in the righ chapter ?. A little bit confusing for me<br />

ADE W830 : in fact, RTC registers security can be changed during FSBL (in secure mode), so at boot time. But if it is confusing, this sentence should be rewritten!<br />

ADE W834 : is it clearer now ? <br> NSA W835 : yes it is, I have added "(performed at boot time)" , is it right ? else call me please ;-)}}
{{InternalInfo|This configuration could be changed in RTC_SMCR register, per sub function (initialization, calibration, alarm A, alarm B, wake up timer and time-stamp). The customer may adapt this configuration to his needs, sharing some functions with the co-processorcoprocessor or the secure world. This would require some code adaptation because, in case some functions are put in secure world, then secure services are needed to access to some control registers (like the write protection) from Linux.}}
The '''RTC''' peripheral is able to generate two interrupts:
* A secure interrupt, connected to the Arm<sup>&reg;</sup> Cortex<sup>&reg;</sup>-A7 [[GIC internal peripheral|GIC]], not used in OpenSTLinux distribution.
* A non-secure interrupt, connected both to Arm<sup>&reg;</sup> Cortex<sup>&reg;</sup>-A7 [[GIC internal peripheral|GIC]] and Cortex-M4 [[NVIC internal peripheral|NVIC]]: this interrupt is used on Linux<sup>&reg;</sup> and by default in OpenSTLinux distribution.<br />

The '''RTC''' peripheral is part of the backup domain which reset and clock are controlled via the [[RCC internal peripheral|RCC]] by the first stage bootloader (FSBL, running in secure mode) at boot time.<br />

The RTC reset occurs when the backup domain is reset. To avoid clearing the [[TAMP internal peripheral|TAMP]] register contents, this is only done on cold boot, not on wake up.

===Runtime===
====Overview====
The '''RTC''' peripheral can be allocated to the Arm<sup>&reg;</sup> Cortex<sup>&reg;</sup>-A7 non-secure core to be used under Linux<sup>&reg;</sup> with [[RTC overview|RTC framework]].

====Software frameworks===={{ReviewsComments|NSA W830  : as it is a secure peripheral, strange not to have some sw associated to OP-TEE ?<br />

ADE W830  : I confirm no sw associated to OP-TEE, but since Tamper is now managed by TF-A, there is an RTC driver in TF-A <br> NSA : Ok . How to give this information?<br />

GeraldB W836: RTC is a secure peripheral that is left unsecure at boot time, as this is explained in the chapter above. That is why there is no framework managing it on secure side. [[TAMP internal peripheral|TAMP]] does not need to be mentioned here as its secure management is covered in its own page.}}

{{:Internal_peripherals_software_table_template}}
 | Core
 | [[RTC internal peripheral|RTC]]
 |
 | [[RTC overview|Linux RTC framework]]
 |
 |
 |-
 |}

====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 [[STM32CubeMX]] tool for all internal peripherals, and then manually completed (especially for external peripherals) according to the information given in the corresponding software framework article.

For Linux kernel configuration, please refer to [[RTC device tree configuration|RTC device tree configuration]].

====Peripheral assignment====

{{:Internal_peripherals_assignment_table_template}}<onlyinclude>

 | rowspan="1" | Core
 | rowspan="1" | [[RTC internal peripheral|RTC]]
 | RTC
 | <span title="assignable peripheral" style="font-size:21px"></span>

 | <span title="assignable peripheral" style="font-size:21px"></span>

 |
 |  |-</onlyinclude>

 |}RTC is mandatory to resynchronize [[STGEN_internal_peripheral | STGEN]] after exiting [[Power_overview | low-power modes]].
 |-</onlyinclude>

 |}
<noinclude>

[[Category:Core peripherals]]
{{PublicationRequestId | 10398 | 2019-01-21 | AnneJ}}
{{ArticleBasedOnModel| Internal peripheral article model}}</noinclude>
(5 intermediate revisions by 3 users not shown)
Line 1: Line 1:
<noinclude>
 
{{ArticleBasedOnModel| [[Internal peripheral article model]]}}
 
{{ArticleMainWriter|AmelieD}}
 
{{ReviewersList | AmelieD, GeraldB}}
 
{{ArticleApprovedVersion| AmelieD | AmelieD, GeraldB | No previous approved version | AnneJ - 21Jan-19 - 10398 | 21Jan'19}}
 
[[Category:Core peripherals]]
 
</noinclude>
 
 
 
==Article purpose==
 
==Article purpose==
 
The purpose of this article is to
 
The purpose of this article is to
Line 22: Line 14:
 
===Security support===
 
===Security support===
 
The '''RTC''' peripheral is a '''secure''' peripheral.
 
The '''RTC''' peripheral is a '''secure''' peripheral.
{{ReviewsComments|NSA W830 :does the modification i did , to make it similare to model , is correct<br />
 
ADE W830  : I'm sorry I don't catch the modification you did, what is it ?<br> NSA :W835 : it was written : "The RTC is '''secure aware'''"<br />
 
LDE W835: RTC is not secure, it is TrustZone-aware" as mentioned in RM, the securization is managed by IP itself, not by ETZPC<br />
 
GeraldB W836: "secure", "secure aware" or "trustzone aware", ... are concepts difficult to explain in the Wiki, that is why the "aware" aspect was removed from the Wiki and we only mention "secure" or "not secure". Then, we mention "(under ETZPC control)" wherever needed and this is not the case for RTC (that is in the same case as [[BSEC internal peripheral|BSEC]]) so I would simply propose "The RTC is a secure peripheral."<br/>
 
ADE W846: (under ETZPC control) removed.}}
 
   
 
==Peripheral usage and associated software==
 
==Peripheral usage and associated software==
Line 32: Line 19:
 
By default after a backup domain power-on reset (performed at boot time), all RTC registers can be read or written in both secure and non-secure modes.<br />
 
By default after a backup domain power-on reset (performed at boot time), all RTC registers can be read or written in both secure and non-secure modes.<br />
 
In OpenSTLinux distribution, the first stage bootloader (FSBL, running in secure mode) keeps this default configuration, leaving full control to Linux<sup>&reg;</sup> at runtime.
 
In OpenSTLinux distribution, the first stage bootloader (FSBL, running in secure mode) keeps this default configuration, leaving full control to Linux<sup>&reg;</sup> at runtime.
{{ReviewsComments|NSA W830  : below , we are here is the chapter boot time , are the paragraphes below in the righ chapter ?. A little bit confusing for me<br />
+
{{InternalInfo|This configuration could be changed in RTC_SMCR register, per sub function (initialization, calibration, alarm A, alarm B, wake up timer and time-stamp). The customer may adapt this configuration to his needs, sharing some functions with the coprocessor or the secure world. This would require some code adaptation because, in case some functions are put in secure world, then secure services are needed to access to some control registers (like the write protection) from Linux.}}
ADE W830 : in fact, RTC registers security can be changed during FSBL (in secure mode), so at boot time. But if it is confusing, this sentence should be rewritten!<br />
 
ADE W834 : is it clearer now ? <br> NSA W835 : yes it is, I have added "(performed at boot time)" , is it right ? else call me please ;-)}}
 
{{InternalInfo|This configuration could be changed in RTC_SMCR register, per sub function (initialization, calibration, alarm A, alarm B, wake up timer and time-stamp). The customer may adapt this configuration to his needs, sharing some functions with the co-processor or the secure world. This would require some code adaptation because, in case some functions are put in secure world, then secure services are needed to access to some control registers (like the write protection) from Linux.}}
 
 
The '''RTC''' peripheral is able to generate two interrupts:
 
The '''RTC''' peripheral is able to generate two interrupts:
 
* A secure interrupt, connected to the Arm<sup>&reg;</sup> Cortex<sup>&reg;</sup>-A7 [[GIC internal peripheral|GIC]], not used in OpenSTLinux distribution.
 
* A secure interrupt, connected to the Arm<sup>&reg;</sup> Cortex<sup>&reg;</sup>-A7 [[GIC internal peripheral|GIC]], not used in OpenSTLinux distribution.
Line 47: Line 31:
   
 
====Software frameworks====
 
====Software frameworks====
{{ReviewsComments|NSA W830  : as it is a secure peripheral, strange not to have some sw associated to OP-TEE ?<br />
 
ADE W830  : I confirm no sw associated to OP-TEE, but since Tamper is now managed by TF-A, there is an RTC driver in TF-A <br> NSA : Ok . How to give this information?<br />
 
GeraldB W836: RTC is a secure peripheral that is left unsecure at boot time, as this is explained in the chapter above. That is why there is no framework managing it on secure side. [[TAMP internal peripheral|TAMP]] does not need to be mentioned here as its secure management is covered in its own page.}}
 
   
 
{{:Internal_peripherals_software_table_template}}
 
{{:Internal_peripherals_software_table_template}}
Line 73: Line 54:
 
  | rowspan="1" | [[RTC internal peripheral|RTC]]
 
  | rowspan="1" | [[RTC internal peripheral|RTC]]
 
  | RTC
 
  | RTC
  |  
+
  | <span title="assignable peripheral" style="font-size:21px">✓</span>
  | <span title="assignable peripheral" style="font-size:21px"></span>
+
  | <span title="assignable peripheral" style="font-size:21px"></span>
|
 
 
  |
 
  |
  +
| RTC is mandatory to resynchronize [[STGEN_internal_peripheral | STGEN]] after exiting [[Power_overview | low-power modes]].
 
  |-
 
  |-
 
</onlyinclude>
 
</onlyinclude>
 
  |}
 
  |}
  +
  +
<noinclude>
  +
[[Category:Core peripherals]]
  +
{{PublicationRequestId | 10398 | 2019-01-21 | AnneJ}}
  +
{{ArticleBasedOnModel| Internal peripheral article model}}
  +
</noinclude>