USB2PHY internal peripheral

Applicable for

Information

The objective of this article model is to minimize any misalignments between all articles related to internal peripheral.

The text highlighted in STLightGreen explains what is expected in each paragraph, and must be removed or replaced in your internal peripheral article.
The table of contents must be used as it is, without any modification in your internal peripheral article.
The text in black must be used as it is, or slightly adapted when needed, in your internal peripheral article.
The technical writers will review your internal peripheral article with this model as reference.
Your internal peripheral article must be named "XXX internal peripheral", where "XXX" is the internal peripheral.
If you have nothing to write in a paragraph, remove it.
If you have something to add in your internal peripheral article, add it in a paragraph defined by this model. If you don't find the right paragraph, please contact the Wiki maintainers.
The following template must be added at the bottom of your article: {{ArticleBasedOnModel | Internal peripheral article model}}
Example of articles that follow this model:
- USART internal peripheral

1. Article purpose[edit source]

The purpose of this article is to:

briefly introduce the USB2PHY peripheral and its main features,
indicate the peripheral instances assignment at boot time and their assignment at runtime (including whether instances can be allocated to secure contexts),
list the software frameworks and drivers managing the peripheral,
explain how to configure the peripheral.

2. Peripheral overview[edit source]

The XXX peripheral is used to ....

Add any further information that is in addition to the generic sentence below. This can be the main peripheral features to be introduced and briefly described here (e.g., DAC internal peripheral#Features).

Refer to the STM32 MPU reference manuals for the complete list of features, and to the software frameworks and drivers, introduced below, to see which features are implemented.

3. Peripheral usage[edit source]

This chapter is applicable in the scope of the OpenSTLinux BSP running on the Arm^® Cortex^®-A processor(s), and the STM32CubeMPU Package running on the Arm^® Cortex^®-M processor.

3.1. Boot time assignment[edit source]

If the peripheral is not used at boot time by any device, keep only the following sentence: The XXX peripheral is not used at boot time.

Else, only keep the sub-chapters applicable to this article. If the peripheral has the same assignment for a Series (e.g., same assignment for STM32MP13 lines and STM32MP15 lines), favor a single sub-chapter for the Series (e.g., STM32MP1 Series) to several chapters for each line.

The <section begin=stm32mpxx_[yy_]boottime /> and <section end=stm32mpxx_[yy_]boottime /> labels are mandatory: they specify the sections that are transcluded in the peripherals overview articles (e.g., STM32MP15 peripherals overview).

It is obviously possible to add here (before the sub-chapters) information about the boot time assignment that applies to all microprocessor devices.

3.1.1. On STM32MP25x lines [edit source]

Keep this chapter if the peripheral has different assignments for any of the lines of the Series (else remove it).

In the "Peripheral" column, make a link to the internal peripheral article itself. This link is useful in the articles that transclude the internal peripheral article (e.g., STM32MP25 peripherals overview).

If the peripheral is not used at boot time on these lines, only keep the following sentence: The XXX peripheral is not used at boot time.

If the internal peripheral is RIF-aware,

for each peripheral instance, add before the table about the boot time allocation of the features an anchor (syntax: <span id="stm32mp25_instance_name_a35_boottime_rif"/>),
in the "Comment" column, link to this table thanks to a comment such as "Shareable at internal peripheral level thanks to the RIF: see the boot time allocation per feature" (obviously, change "Contributors:Internal_peripheral_article_model" by the name of the internal peripheral article),
in the "Peripheral" column, add the icon so that a popup window ("RIF-aware internal peripheral") is shown if the mouse is left over it (syntax: <span title="RIF-aware internal peripheral"><sup>[[File:Info.png|15px|link=]]</sup></span>).

Click on to expand or collapse the legend...

☐ means that the peripheral can be assigned to the given boot time context.
☑ means that the peripheral is assigned by default to the given boot time context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
⬚ means that the peripheral can be assigned to the given boot time context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
✓ is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

The present chapter describes STMicroelectronics recommendations or choice of implementation. Additional possibilities might be described in STM32MP25 reference manuals.

Domain	Peripheral	Boot time allocation				Comment
Domain	Peripheral	Instance	Cortex-A35 secure (ROM code)	Cortex-A35 secure (TF-A BL2)	Cortex-A35 non-secure (U-Boot)	Comment
Domain	XXX	Instance1	☐	☐	☐	Shareable at internal peripheral level thanks to the RIF: see the boot time allocation per feature
Domain	XXX	Instance2	☐	☐	☐	Shareable at internal peripheral level thanks to the RIF: see the boot time allocation per feature

For the RIF-aware internal peripheral, add, for each peripheral instance, the below text and table to describe the boot time allocation for the features of this instance.

The below table shows the possible boot time allocations for the features of the instance_name instance.

Feature	Boot time allocation			Comment
Feature	Cortex-A35 secure (ROM code)	Cortex-A35 secure (TF-A BL2)	Cortex-A35 non-secure (U-Boot)	Comment
Feature 1	☐	⬚	☐
Feature 2		⬚	⬚

3.2. Runtime assignment[edit source]

Keep only the sub-chapters for which the article is applicable.

The <section begin=stm32mpxx_[yy_]runtime /> and <section end=stm32mpxx_[yy_]runtime /> labels are mandatory: they specify the sections that are transcluded in the peripheral overview articles (e.g., STM32MP15 peripherals overview).

It is obviously possible to add here (before the sub-chapters) information about the runtime assignment that applies to all microprocessor devices.

3.2.1. On STM32MP25x lines [edit source]

In the "Peripheral" column, link to the internal peripheral article itself. This link is useful in the articles that transclude the internal peripheral article (e.g., STM32MP25 peripherals overview).

If the internal peripheral is RIF-aware,

for each peripheral instance, add before the table about the runtime allocation of the features an anchor (syntax: <span id="stm32mp25_instance_name_a35_runtime_rif"/>),
in the "Comment" column, link to this table thanks to a comment such as "Shareable at internal peripheral level thanks to the RIF: see the runtime allocation per feature" (obviously, change "Contributors:Internal_peripheral_article_model" by the name of the internal peripheral article),
in the "Peripheral" column, add the icon so that a popup window ("RIF-aware internal peripheral") is shown if the mouse is left over it (syntax: <span title="RIF-aware internal peripheral"><sup>[[File:Info.png|15px|link=]]</sup></span>).

Click on to expand or collapse the legend...

STM32MP25 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.
☑ means that the peripheral is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
⬚ means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
✓ is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

The present chapter describes STMicroelectronics recommendations or choice of implementation. Additional possibilities might be described in STM32MP25 reference manuals.

Domain	Peripheral	Runtime allocation						Comment
Domain	Peripheral	Instance	Cortex-A35 secure (OP-TEE / TF-A BL31)	Cortex-A35 non-secure (Linux)	Cortex-M33 secure (TF-M)	Cortex-M33 non-secure (STM32Cube)	Cortex-M0+ (STM32Cube)	Comment
Domain	XXX	Instance1	☐^OP-TEE ☐^{TF-A BL31}	☐	☐	☐		Shareable at internal peripheral level thanks to the RIF: see the runtime allocation per feature
Domain	XXX	Instance1	☐^OP-TEE	☐	☐	☐		Shareable at internal peripheral level thanks to the RIF: see the runtime allocation per feature

For the RIF-aware internal peripheral, add, for each peripheral, instance the below text and table to describe the runtime allocation for the features of this instance.

The below table shows the possible runtime allocations for the features of the instance_name instance.

Feature	Runtime allocation					Comment
Feature	Cortex-A35 secure (OP-TEE / TF-A BL31)	Cortex-A35 non-secure (Linux)	Cortex-M33 secure (TF-M)	Cortex-M33 non-secure (STM32Cube)	Cortex-M0+ (STM32Cube)	Comment
Feature 1	☐^OP-TEE ☐^{TF-A BL31}	⬚	☐	☐
Feature 2	✓^{TF-A BL31}	⬚	⬚	⬚

4. Software frameworks and drivers[edit source]

Below are listed the software frameworks and drivers managing the XXX peripheral for the embedded software components listed in the above tables.

If there are several software frameworks and drivers (see for example the “Linux” bullet below), keep them in a single line. If a framework or a driver is not applicable to all microprocessor devices (see for example the “Linux” bullet below), use the MicroprocessorDevice template to provide this information.

Keep only the applicable bullets. Place the embedded software components in alphabetical order.

Replace YYY by the link(s) to the associated framework(s), driver article(s), and/or source code(s) (thanks to the CodeSource template) for the embedded software component that is being considered.

Linux^®: F1 framework (for STM32MP13x lines only), F2 framework, D1 driver and D2 driver
OP-TEE: YYY
STM32Cube: YYY
TF-A BL2: YYY
TF-A BL31: YYY
TF-M: YYY
U-Boot: YYY

5. How to assign and configure the peripheral[edit source]

The peripheral assignment can be done via the STM32CubeMX graphical tool (and manually completed if needed).
This tool also helps to configure the peripheral by generating:

partial device trees (pin control and clock tree) for the OpenSTLinux software components,
HAL initialization code for the STM32CubeMPU Package.

The configuration is applied by the firmware running in the context in which the peripheral is assigned.

If necessary, adapt this section to add more information (for example, links to the articles about the peripheral device trees) about the peripheral configuration for given runtime contexts. The user must be able to easily understand how to configure the peripheral by reading this paragraph or the software framework overview.

6. How to go further[edit source]

Use this paragraph to provide additional information or to refer to other documents such as application notes (AN).