Description SL STM32 MP15x devices

Identification

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:

Software support

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:

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

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.

• (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:

Proposal for boards only with NOR boot:

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:

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

QSPI NAND memory

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!

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

Serial Interfaces

I2C busses

Devices on i2c-1

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

DSI display interface

One DSI display interface is available thru dedicated pins.

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>;
};

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!