Skip to content

# Description SL STM32 MP15x devices

## Identification

SoM | SoM number | Description
--- | --- | ---
SL STM32 MP157 512MB/512MB | 40099 167 | SoM with STM32MP157A
SL STM32 MP157 256MB/256MB | 40099 168 | SoM with STM32MP157A
SL STM32 MP153 512MB/512MB | 40099 181 | SoM with STM32MP153A
SL STM32 MP153 256MB/256MB | n.a. | SoM with STM32MP153A
SL STM32 MP151 512MB/512MB | 40099 180 | SoM with STM32MP151A
SL STM32 MP151 256MB/256MB | 40099 189 | SoM with STM32MP151A

## Overview of SoM components and features

The SoM includes processor and DDR3-RAM, often also QSPI flash, gpio expander and an ethernet phy.

This is the configuration for the SL STM32 MP157 512MB/512MB SoM:

- STM32MP157A SoC (2xCortex-A7@650MHz, 1xCortex-M4@200MHz)
- 512 MB DDR3 RAM at 528MHz
- 2 MB QSPI NOR flash
- 512 MB QSPI NAND flash
- 1x Ethernet PHY (100MBit/s)
- 1x I2C GPIO Expander

There are also variants with different RAM and Flash configurations. The 'C' type SoMs have secure boot capabilities.

The differences between the MP151, MP153 and MP151 variants are:

Component | MP151 | MP153 | MP157
--- | --- | --- | ---
Cortex-A7 | Single | Dual | Dual
GPU | No | No | Yes
Display | TFT | TFT | TFT/DSI
CAN | No | Yes | Yes

## Software support

SoM | SoM number | Shortname | devicetree file | CubeMX configuration | Remark
--- | --- | --- | --- | --- | ---
SL STM32 MP157 512MB/512MB | 40099 167 | t1000 | stm32mp-t1000.dts | t1000-som-minimal.ioc |
SL STM32 MP157 256MB/256MB | 40099 168 | t1002 | stm32mp-t1002.dts | t1002-som-minimal.ioc |
SL STM32 MP153 512MB/512MB | 40099 181 | t1005 | stm32mp-t1005.dts | t1000-som-minimal.ioc |
SL STM32 MP153 256MB/256MB | n.a. | t1007 | stm32mp-t1007.dts | t1002-som-minimal.ioc |
SL STM32 MP151 512MB/512MB | 40099 180 | t1004 | stm32mp-t1004.dts | t1000-som-minimal.ioc |
SL STM32 MP151 256MB/256MB | 40099 189 | t1006 | stm32mp-t1006.dts | t1002-som-minimal.ioc |

Important

Not every software version provides full support for all devices and all configurations. See the appropriate release note for more information.

The devicetree configurations for the SoM components include all components which are located on the SoM module and all recommended external peripherals. For the t1000 module these are:

- SoC chip with default clock configuration
- DDR3 RAM
- QSPI NOR
- QSPI NAND
- Ethernet PHY
- GPIO Expander
- USB Host interface
- USB OTG interface
- Serial console on UART4
- SD card interface on SDMMC1
- LED1 on PA13

See the SoM hardware documentation for further details.

The CubeMX configurations for devices are the same. This is the case when the differences of these SoM variants are not relevant for the boot loader functionality (e.g. GPU or CAN interface).

In the device tree files for these SoMs sensible default settings for the clock configuration and security settings are done. They have to be adapted when there are special requirements.

### Compatibility

It is not required to provide the bootloaders u-boot and tf-a for all SoM variants. Relating to the devices needed to boot, the SoM variants differs only little. So the amount of bootloaders can be reduced. Here is the compatibility list which basic u-boot and tf-a bootloader can be used for a special SoM:

Shortname | t1000 compatible | t1002 compatible
--- | --- | ---
t1000 | x |
t1002 |  | x
t1004 | x |
t1005 | x |
t1006 |  | x
t1007 |  | x

Reasons for different tf-a bootloader is DDR3 configuration, clock and security settings. The differences in u-boot are mostly different machine names.

Hint

Be aware that the `compatible` string of the u-boot device tree file is used to find the approprioate linux device tree file. So these settings have to match between bootloader and linux boot configuration.

#### SPI-NAND types

Newer versions of the SoMs contain the SPI-NAND chip `KIOXIA P/N TC58CVG2S0HRAIJ`. This chip is supported in BSP version 1.5.0 and later. To enable older BSP versions to support this chip the required patches can be found at https://git.kontron-electronics.de/stm32mp/meta-ktn-stm32mp/-/commit/58b226bd1b00ccfd0d039ff3f8d5ee22803485ef

### Yocto configurations

The dedicated software configurations for these SoMs are the following. Replace shortname with the short name of your board.

build repository | build-stm32mp
branches | thud, dunfell
machine | stm32mp-shortname (e.g. stm32mp-t1000)
init-env command | `. init-env -t thud build-stm32mp`
EULA accept variable(1) | ACCEPT_EULA_stm32mp-shortname-s-multi = "1"
distros dedicated for these kits | ktn
images dedicated for these kits | image-ktn, image-ktn-qt
available boot devices(2) | mmc0 (SD-card), mmc1 (eMMC), ubifs0 (QSPI NAND), pxe (Ethernet1)
latest prebuild binaries(3) | https://files.kontron-electronics.de/stm32mp

- (1) Only required when GPU with proprietary drivers shall be used
- (2) Only if SoM provides this interface
- (3) Prebuilt binaries are not provided for all variants

### Licence information

This product contains software components which are licensed as free respectively open-source software under the GNU General Public License, versions 2 or 3, or the GNU Lesser General Public License, versions 2.1 or 3 or any other open-source licence. Everyone can get the source code of this software components from us by download or by storage medium within three years after the delivery of the product or as long as we offer spare parts or support for the product.

To get the source code on a data storage medium (CD-ROM, DVD, USB drive), please send a request to our customer support at the following address

    Kontron Electronics GmbH
    Max-Planck-Strasse 6
    72636 Frickenhausen
    Deutschland

    Web: www.kontron-electronics.de
    E-Mail: support@kontron-electronics.de

Including the statement of the following product data:

- Product name and product number
- Date of delivery

We also require a fee of EUR 10,- for the costs of preparation of the medium and shipping to be transferred.

Preventive it should be mentioned here that using the right of installing own versions of the open-source software components, which is guaranteed in the licence contract, will expire all certifications and warranties of the product. The operation of the manipulated product will happen on one's own authority.

If you want to download the source code covered by open-source licenses for this product use these URLs:

- For getting binaries, license texts and source code:
  https://files.kontron-electronics.de/stm32mp
  Look for the appropriate BSP version in this directory or in the archive subdirectory.
- For instructions how to build the software:
  https://docs.kontron-electronics.de/stm32mp/build-stm32mp

## Known issues and limitations

- The SoMs provide an internal RTC for timekeeping. Due to the chip technology this RTC is more power consuming as dedicated RTC chips. For optimal power consumption an external RTC should be used.

## Board design considerations

When you want to design your own baseboard for these SoM modules you should be aware of these restrictions and proposals to ease the bring up and production of your board:

- It is strongly recommended to use UART4 as console interface.

- Keep the USB OTG port accessible to be able to use CubeProgrammer for completely empty devices or first board bring up.

- CubeProgrammer is not able to program the QSPI NOR on the SoM module. So this has to be done from linux. Be aware that linux has to be loaded via on-chip ethernet, usb storage or sd-card. One of them has to be accessible from u-boot to load linux from. In case of sd-card the boot rom can directly boot from it (if default sd-card port is used).

- Use PA13 port as LED port. On USB boot mode this pin will be toggled from SOC ROM code to signal USB boot mode active.

- Keep bootstrap pins accessible to be able to force device in USB boot mode for reprogramming

- Even when every gpio line can be configured to generate an interrupt, the EXTI lines are limited to the count of 16. For external gpios the EXTI lines are mapped directly to the 16 gpio bank pins of each bank. So the gpio lines Px0, Px1, Px2, ... map to the same EXTI interrupt 0, 1, 2, ... . Because of this, it is not possible to use more than one as external interrupt source in the same devicetree configuration (e.g. using PA0 and PB0 together is not possible). Keep the external interrup lines on different gpio port lines in your board design!

- Keep in mind that some peripherals share their clock source and can influence themselves when they change their base clock. This is especially true for audio equipment, which sometimes must change the clock base on the run to achieve the required sampling rate. In this case the other equipment can be influenced by the clock change. This behavior affects SPI1/2 and SPI4/5 which also can be used as SSI interfaces for audio hardware.

Here are proposals for the bootstrap pin accessibility. SW1 and SW2 are the proposed switches mentioned in the SoM hardware user guide. It is an good idea to keep SW1 and SW2 on pads or use 0 ohm bridges to enable forcing some boot mode while production.

Proposal for boards with SD card and NOR boot:

boot mode | SW1 | SW2 | comment
--- | --- | --- | ---
sd, nor | Leave SW1 open | Leave SW2 open | Program fuses for first boot device SD card, then NOR (OTP_CFG3=0x22000000)
USB boot | Close SW1 temporarily | Close SW2 temporarily |
Engineering | Close SW1 temporarily | Leave SW2 open |

Important

Kontron SoMs with default configuration are already pre programmed with boot fuses. For these devices a 'NOR only boot' is not available.

Proposal for boards only with NOR boot:

boot mode | SW1 | SW2 | comment
--- | --- | --- | ---
nor | Leave SW1 open | Close SW2 with 0 ohms resistor |
USB boot | Close SW1 temporarily | Close SW2 with 0 ohms resistor |
Engineering | Close SW1 temporarily | Remove SW2 0 ohms resistor temporarily | This is only required for a few development boards

## Delivery configuraton

The SoMs are delivered with

- 2 MAC addresses reserved,
  if the SoM has an Ethernet interface. The first one is fused into OTP memory, the second is the following MAC address, calculated in the bootlader and written to the device tree on boot for the configuration of the Kontron BL boards.
- OTP boot fuses
  configured for booting from SD card and fallback to boot from NOR (OTP_CFG3=0x22000000)
- Pre programmed U-Boot bootloader
  in NOR flash, able to fetch extlinux boot configuration from SD card or boot from network (pxe). U-Boot is equipped with serial console, drivers for QSPI NOR, QSPI NAND and USB host.

## Description of board components

The following sections describe the hardware components and, if available, their interface to to linux os.

### DDR3 memory

The DDR3 memory is clocked with 528MHz and is available with various size configurations. Some memory is reserved as GPU memory and not available for linux. The size for GPU memory can be adapted in the device tree settings.

### GPU memory reservation

In the device tree some amount of memory is reserved for GPU. For SoMs with 512MiB RAM configuration, 64MiB are reserved for GPU. For the 256MiB RAM configuration it is reduced to 32MiB.

### QSPI NOR memory

QSPI NOR memory is used for boot. The contents are available in linux thru mtd interface:

MTD device | Memory area | Partition size | Name | Remark
--- | --- | --- | --- | ---
mtd0 | 0x000000 - 0x03FFFF | 256k (4 Blocks) | fsbl1 | reserved for first stage bootloader, first copy
mtd1 | 0x040000 - 0x07FFFF | 256k (4 Blocks) | fsbl2 | reserved for first stage bootloader, second copy
mtd2 | 0x080000 - 0x1BFFFF | 1,25M (20 Blocks) | ssbl | reserved for u-boot bootloader
mtd3 | 0x1C0000 - 0x1DFFFF | 128k (2 Blocks) | env | reserved for u-boot environment
mtd4 | 0x1E0000 - 0x1FFFFF | 128k (2 Blocks) | nor_user | free for user(1)

- (1) may be shrinked in future versions if bootloader or u-boot environment grows

### QSPI NAND memory

MTD device | Partition size | Name | Remark
--- | --- | --- | ---
mtd5 | 20000000 | spi0.1 | for ubifs linux filesystems on ubi device mapper

Hint

The size can variy, depending on variant

### SOC OTP memory

The following locations in OTP are reserved for special usage by Kontron. These locations may be already programmed with appropriate content and can't be used by customers for their needs!

OTP word | Intended usage
--- | ---
59 | serial number of SoM
60 | serial number of baseboard
61 | reserved
62 | reserved
63 | reserved
64 | reserved
65 | reserved
66 | reserved

With the help of mptool it is possible to read and write these values.

### Serial Interfaces

STM32MP1 | Used as | Linux access | Baud settings
--- | --- | --- | ---
uart4 | console | `/dev/ttySTM0` | 8 Bits, no parity, 115200 Baud

### I2C busses

Name | Accessible via | Used by
--- | --- | ---
I2C2 | i2c-1 | external and SoM internal bus

#### Devices on i2c-1

Address | Location | Komponente
--- | --- | ---
0x20 | SOM | GPIO port expander TCA6408A

Keep in mind that the TCA6408A gpio expander on I2C2 bus is limited to 400kHz operation!

### USB host

One USB 2.0 host interface is available thru dedicated pins and supported by the linux USB stack.

### USB OTG

One USB OTG interface is available thru dedicated pins and supported by the linux USB stack.

### Ethernet

Name | Linux device | Remark
--- | --- | ---
Ethernet 1 | eth0 | Native SOC interface

Remark

Ethernet is not provided by all variants

### DSI display interface

One DSI display interface is available thru dedicated pins.

Remark

- DSI interface is only available on variants with GPU
- Using the DSI display interface and the DPI interface at the same time is not possible!

### DMA

Different peripheals on the STM32MP1 SOC may use different DMA controllers. Some are connected to the `mdma` DMA controller, which is only available for the A7 domain. Peripheals which can be shared between M4 and A7 domain are connected to the DMA controllers `dma1` and `dma2`. Each of them provide 8 DMA channels.

The default configuration for the Kontron SOMs is to use `dma1` for A7 and `dma2` for M4. In some Linux configurations more than 8 dma channels are desired. In this case some peripheals won't work or will fall back to operate in non DMA mode.

If the DMA channels run out, a message similar to the following will be printed on the console

    stm32-dmamux 48002000.dma-router: Run out of free DMA requests

To find out which peripheal uses DMA channels extend the kernel command line with these arguments

    dyndbg="file drivers/dma/stm32-dmamux.c +p" loglevel=8

Then the Linux kernel will print out the current configuration like this

    stm32-dmamux 48002000.dma-router: Mapping DMAMUX(43) to DMA0(0)

Usually the associated peripheal can be located in the lines above. Otherwise check the device tree for DMA entries.

If your system runs out of DMA channels you have two options to go further:

- Remove the `dmas` entry in the device tree for peripheals which can do without DMA
- assign `dma2` also to A7 domain. The A7 domain then provides 16 DMA channels. For M4 there is no DMA available any more.

If you want to assign `dma2` also to A7 domain you have to modify the device tree for your setup like this:

    &dma2 {
        /* Enable dma2 for A7 (linux) */
        status = "okay";
    };
    &m4_dma2 {
        /* Disable dma2 for M4 */
        status = "disabled";
    };

    &dmamux1{
        /* With dma2, 2*8 dma channels are available */
        dma-masters = <&dma1 &dma2>;
        dma-channels = <16>;
    };

Important

`dma2` must also be available for A7 context. This requires modifications in the device tree of the arm-trusted-firmware (tf-a) bootloader!

After you modified the Linux device tree, you have also to modify your system partitionning in tf-a bootloader as described.

Set the appropriate configuation for the ETZPC peripheal (&etzpc) in the device tree of the tf-a bootloader. For example the file `fdts/stm32mp-som-t1000.dtsi` contains the default ETZPC table for the Kontron SOMs.

To enable `dma2` for Linux, the table needs an entry which assigns `dma2` to the A7 domain:

    DECPROT(STM32MP1_ETZPC_DMA2_ID, DECPROT_NS_RW, DECPROT_UNLOCK)

If `dma2` is not assigned to A7 domain, Linux can't access this peripheal, regardless you modified the Linux device tree like mentioned above!