Is there an issue with using a stm32mp153AACx device tree to boot a stm32mp151AACx board?

[cfilipescu]

I have tried it and it works but I wanted to see if there are any limitations. The boards are identical the only difference is the MPU.

[Olivier GALLIEN]

Hi @cfilipescu​ ,

main differences between MP151 and MP153 is A7 core numbers.

Dual on MP153 but single in MP151.

Don't you notice any warning in boot log related to attempt to start/use the second core ?

Olivier

[Bernard PUEL]

The question is more: Why you are not using a 151 dts with your 151 board ?

You have both is the kernel.

The diff are here:$ cat stm32mp153.dtsi

// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)

/*

 * Copyright (C) STMicroelectronics 2019 - All Rights Reserved

 * Author: Alexandre Torgue <alexandre.torgue@st.com> for STMicroelectronics.

 */

#include "stm32mp151.dtsi"

/ {

cpus {

cpu1: cpu@1 {

compatible = "arm,cortex-a7";

device_type = "cpu";

reg = <1>;

clocks = <&scmi0_clk CK_SCMI0_MPU>;

clock-names = "cpu";

operating-points-v2 = <&cpu0_opp_table>;

};

};

arm-pmu {

interrupts = <GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH>,

   <GIC_SPI 201 IRQ_TYPE_LEVEL_HIGH>;

interrupt-affinity = <&cpu0>, <&cpu1>;

};

soc {

m_can1: can@4400e000 {

compatible = "bosch,m_can";

reg = <0x4400e000 0x400>, <0x44011000 0x1400>;

reg-names = "m_can", "message_ram";

interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>,

   <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;

interrupt-names = "int0", "int1";

clocks = <&scmi0_clk CK_SCMI0_HSE>, <&rcc FDCAN_K>;

clock-names = "hclk", "cclk";

bosch,mram-cfg = <0x0 0 0 32 0 0 2 2>;

status = "disabled";

};

m_can2: can@4400f000 {

compatible = "bosch,m_can";

reg = <0x4400f000 0x400>, <0x44011000 0x2800>;

reg-names = "m_can", "message_ram";

interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>,

   <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;

interrupt-names = "int0", "int1";

clocks = <&scmi0_clk CK_SCMI0_HSE>, <&rcc FDCAN_K>;

clock-names = "hclk", "cclk";

bosch,mram-cfg = <0x1400 0 0 32 0 0 2 2>;

status = "disabled";

};

};

};

[Bernard PUEL]

To answer your question: You will declare a dual cpu whereas your hw does have only one. So you will get a bit less performances because of the SMP enabled in the kernel whereas you have only one core.

[cfilipescu]

@Bernard PUEL​ 

I need to have one production image that supports both versions (since 153 is not always available). I could make the default device tree the 151 but that would disable the 2nd core on the 151.

Is there a more elegant way to choose between the two device trees at boot? I guess in u-boot to pick between 151 and 153 device tree? I looked around in u-boot and I couldn't get the CPU model just the serial.

[cfilipescu]

@Community member​ 

There are no real warnings in the boot log.

All I see is this in u-boot right before the kernel load:

FDT: cpu 1 node remove for STM32MP151AAC Rev.Z

[Bernard PUEL · Accepted solution]

So I understand you will have the same board but with different SoC inside: some are 151 and others are 153 ?

If it is the case, the devicetree is not really the concern (I guess you are not using CAN and the only diff is one or 2 cpus). You can use the 153 devicetree with boths !

The problems comes from the SMP config (the kernel config) you activate on 153 to better use dual cpus. So in case of 151, you will get only one cpu (so less cpu power) + the penalty of SMP config.

Then if those penalties are not critical for your application = no pb.

[cfilipescu]

@Bernard PUEL​ 

That is correct some boards will use 151 some 153 but both will use the same image.

The CPU power is not critical so it is good to know that 151 will work just fine with the 153 device tree.

[Bernard PUEL]

ok great. By the way In ST delivery, SMP is activated for both 151 and 153 SoC. So you won't see the difference ... (the penalty is only few % depending on the memory used).

But this is good to know with a MP151 only config, you can save a bit of cpu performance by desactivating the SMP is the kernel.

[cfilipescu]

That is good to know. I will look into it when getting around to optimizing the image. Right now with a single core, the performance overhead is very large.