OSD32MP1 Variant Migration Guide

Published On: April, 29, 2021 By: Neeraj Dantu | Updated: November 29, 2022 by Greg Sheridan

Introduction

This application note describes the differences in features of various offerings in the OSD32MP1 SiP family and provides ways to migrate your product from one variant to another.

Notice: The information provided within this document is for informational use only. Octavo Systems provides no guarantees or warranty to the information contained.

Feature differences in OSD32MP1 Family

The OSD32MP1 SiP family is based on the STM32MP1 SoC family from STMicroelectronics. ST offers several variants with different feature sets and package formats. The following table shows the SiP variants that are offered from Octavo Systems and the key differences between each variant.

Device tree organization for STM32MP1 family

The STM32MP1 family is supported via the OpenSTLinux distribution from ST. Depending on the variant used, the board device tree is constructed from various include files that have device/feature specific device tree nodes.

The structure went through some iterations over time. So, the way device tree support is organized in OpenSTLinux V1.x is a little different from the organization in OpenSTLinux >V2.x. The following sections show an example of this organization in both versions.

Device tree organization for OpenSTLinux V2.x or later

To understand the device tree organization, we can examine the STM32MP157F-DK2 board that has STM32MP157F device. This development board features the ‘7F’ variant with several on board peripherals for application development.

The following figure shows the device tree organization for STM32MP157F-DK2 board. The main device tree file stm32mp157f-dk2.dts is on the left and each device tree include(.dtsi) file it includes is connected to this device tree. All the red colored boxes are device tree(.dts)/device tree include(.dtsi) files. All the blue colored boxes describe the function of additional nodes present in each file.

The base configuration of the SOC is present in stm32mp151.dtsi, which is included in stm32mp153.dtsi along with the second A7 core and CAN-FD nodes. The include file, stm32mp153.dtsi is added in stm32mp157.dtsi along with the GPU and DSI nodes. Similarly, stm32mp15xd.dtsi contains the base 800MHz OPP (Operational Performance Point) table, which is then included in stm32mp15xf.dtsi along with the hardware crypto acceleration configuration.

Device tree organization for OpenSTLinux V1.x

The following figure shows the device tree organization for STM32MP157C-DK2 board featuring the ‘7C’ variant of the device. The main device tree file stm32mp157c-dk2.dts is on the left and each .dtsi file it includes is connected to it directly.

Unlike in OpenSTLinux V2.x, the ‘7C’ variant of the SoC has its own config stm32mp157c.dtsi and is included in the stm32mp157a-dk1.dts board device tree, which is in turn included in the board device tree file stm32mp157c-dk2.dts. Note that all the variations of different boards include stm32mp157c.dtsi. There are no other variant specific base device tree include files. So, variation in different versions of the SoC is handled at the board level device tree file. For example, DSI node is simply left out of the stm32mp157a-dk2.dts.

Board pinmux is setup through stm32mp157-pinctrl.dtsi and stm32mp157cac-pinctrl.dtsi. M4 peripherals and pinmux are setup in stm32mp157c-m4-srm.dtsi.

Note: By default, STM32MP151x, STM32MP15xF, and STM32MP15xD devices are not supported in OpenSTLinux V1.x

Migrating between OSD32MP1 family variants

All variants of the OSD32MP1 family are pin compatible and are interchangeable. So, there are no considerations when migrating between the variants on the hardware side.

The software might require reflecting the change in device features. The following sub-sections describe the changes you need to make to the software to account for the features added or removed by switching to a new variant.

Migrating in OpenSTLinux V2.x or later

As you can see from observing the device tree structure in the previous section, the different variants of the SoC are configured using device tree include(.dtsi) files. Let us assume that you are migrating from a variant OSD32MP15αβ to OSD32MP15γδ. α and γ represent ‘3’ or ‘7’ while β and δ represent ‘A’, ‘C’ ‘D’ or ‘F’ variant designations.

Note: Changes to the device tree must be made in all components that make up the Linux image. The TF-A, U-Boot and Kernel device trees must be changed.

The following table describes the changes you will need to make in order to reconfigure the device tree to the correct variant.

Migrating in OpenSTLinux v2.x

Migrating from OSD32MP15αβ	Migrating to OSD32MP15αδ	Migrating to OSD32MP15γβ	Migrating to OSD32MP15γδ
Change stm32mp15α.dtsi	No change	Change to stm32mp15γ.dtsi	Change to stm32mp15γ.dtsi
Change stm32mp15xβ.dtsi	Change to stm32mp15xδ.dtsi	No change	Change to stm32mp15xδ.dtsi

Note: Please review your board device tree in full to make sure that you have added/removed device tree nodes that reflect the device variant you are switching to.

There might be other changes you will have to make to the board device tree to include or eliminate device tree nodes to reflect the changes in the variant you are using. For example, DSI/LTDC nodes must be added to the board device tree to setup your display if you are switching from OSD32MP153x to OSD32MP157x. Similarly, device tree nodes will have to be removed if you are switching to a variant that does not offer the features you were previously using.

 

Migrating in OpenSTLinux V1.x

Since the organization of the device trees in OpenSTLinx v1.x is a different from OpenSTLinux v2.x, changes that are needed in the device tree configuration are different as well.

As discussed in the previous sections, for OpenSTLinux V1.x, the SoC variants do not get their own device specific include files. Instead, stm32mp157c.dtsi is used as the base include file for all boards. Only the features that are enabled in the board SoC are setup and activated in the board level device tree. The following table shows which device tree nodes need to be left out of a specific board device tree for each variant of the device. As mentioned earlier, OSD32MP15xD and OSD32MP15xF devices are not supported by default. So, changes will need to be made to stm32mp157c.dtsi to reflect the hardware configuration.

Using a device with a different variant’s configuration

If, for any reason, you are intending to switch to a variant in the future and you are currently using a variant that has additional features you do not need, you can run the device variant you are using in the configuration of the variant you want to switch to in the future depending on the feature set of the device you are using. The following table shows which device variant can be run with a different variant configuration.

Software compatibility between OSD32MP1 Family variants

Run On Run As	3A	3C	3D	3F	7A	7C	7D	7F
3A	–	NO	NO	NO	NO	NO	NO	NO
3C	YES	–	NO	NO	NO	NO	NO	NO
3D	YES	NO	–	NO	NO	NO	NO	NO
3F	YES	YES	YES	–	NO	NO	NO	NO
7A	YES	NO	NO	NO	–	NO	NO	NO
7C	YES	YES	NO	NO	YES	–	NO	NO
7D	YES	NO	YES	NO	YES	NO	–	NO
7F	YES	YES	YES	YES	YES	YES	YES	–

Note: In order to use an MP1 variant as another, you can utilize the device tree include file of the variant you want to use the current device as. For example, you can use stm32mp15xc.dtsi for a board that is mounted with OSD32MP157F variant. There is however a caveat related to speed grade support for the device.

The CPU’s OPP(Operational Performance Point) table is part of it’s device tree that lets the firmware know what speed grades are available for the device and which hardware variants support the speed grades defined in the OPP table. This information is described in “cpu0_opp_table” node of a device tree. The CPU OPP table for 800MHz speed grade devices is located in stm32mp15xd.dtsi which is included in stm32mp15xf.dtsi and other 800MHz variants’ device tree include files. The CPU OPP table for 650MHz speed grade devices is located in stm32mp15xa.dtsi which is included in stm32mp15xc.dtsi and other 650MHz variants’ device tree include files. The entries in cpu0_opp_table node are tied to the MP1 variants via “opp-supported-hw” property. For example, for 800MHz speed grade parts(STM32MP157F/STM32MP157D), opp-supported-hw is defined as “0x2”. For 650MHz speed grade parts, opp-supported-hw is defined as “0x1”.

So, using an 800MHz variant as 650mHz variant with the default device trees will break firmware support for speed grade maintenance. For example, cpu-freq utility(https://docs.kernel.org/cpu-freq/index.html) uses the opp-supported-hw property to organize cpu frequency scaling. This utility will fail to initialize if you use 650MHz speed grade device tree files on an 800Mhz device as the opp-supported-hw does not match the variant specific value. In order to use an 800MHz device as 650MHz device you will need to add the opp-supported-hw value of the 800MHz device to the cpu0_opp_table of the 650MHz device.

For example, in order to use OSD32MP157F(800MHz) as OSD32MP157C(650MHz), you will need to change “opp-supported-hw = <0x2>;” to “opp-supported-hw = <0x1 0x2>;” in stm32mp157c’s cpu0_opp_table located in stm32mp15xa.dtsi.

Conclusion

Using this application note as a guideline, you should be able to switch between the various offerings of the OSD32MP1 family by reconfiguring your software. No hardware changes are necessary when moving from one variant to another except for board design changes required to add/remove features to reflect the hardware configuration of the new variant.

If you have any questions please ask in our forums or contact one of our sales representatives.

Revision History

We are constantly updating and improving our documentation to answer common questions or make things more clear.  Stay up to date on any changes to this app note by filling out the form below: