stm32mp151AACx custom board can't perform a reboot since it gets stuck at loading the kernel

[cfilipescu]

Using the ecosystem v1.2 after a cold boot the system boot properly but after issuing a reboot command the system loads u-boot but it gets stuck at loading the kernel.

Are there any known limitations/issues?

[Olivier GALLIEN]

Hi @cfilipescu​,

ecosystem V1.2 ?

Why such an old version ?

Did you try the same with more recent version ?

Also, are you working with a MP153 dts as stated in other post :

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

Olivier

[cfilipescu]

v1.2 is our current production version and because of the recent chip shortage we had to use alternative versions with the same schematic. Initial we tested if the device boots properly and assumed reboot would behave the same.

​

I made a device tree for stm32mp151 and the issues is still there.

The new ecosystem 3.1 works (after the SDcard pmic fix).

​

The problem is updating units in the field to 3.1 now requires reboots which would get the device stuck.

[Olivier GALLIEN]

Hi @cfilipescu​ ,

please provide complete reboot traces.

Thx

Olivier

[cfilipescu]

@Community member​ 

This is what I get when rebooting:

Stopping ntpd: OK
Stopping network: OK
Saving random seed: OK
Stopping klogd: OK
Stopping syslogd: OK
umount: devtmpfs busy - remounted read-only
[ 692.653426] EXT4-fs (mmcblk0p4): re-mounted. Opts: (null)
The system is going down NOW!
Sent SIGTERM to all processes
Sent SIGKILL to all processes
Requesting system reboot
[ 694.668603] reboot: Res
U-Boot SPL 2018.11-stm32mp-r4.3 (Jan 21 2022 - 18:20:31 +0000)
Model: STMicroelectronics custom STM32CubeMX board
RAM: DDR3-DDR3L 16bits 533000Khz
Trying to boot from MMC1
 
 
U-Boot 2018.11-stm32mp-r4.3 (Jan 21 2022 - 18:20:31 +0000)
 
CPU: STM32MP151AAC Rev.Z
Model: STMicroelectronics custom STM32CubeMX board
Board: stm32mp1 in basic mode (st,stm32mp153a-epic_miner_fw-mx)
DRAM: 512 MiB
Clocks:
- MPU : 650 MHz
- MCU : 208 MHz
- AXI : 266.500 MHz
- PER : 0 MHz
- DDR : 533 MHz
NAND: 0 MiB
MMC: STM32 SDMMC2: 0
Loading Environment from EXT4... ** File not found /uboot.env **
 
** Unable to read "/uboot.env" from mmc0:5 **
In: serial
Out: serial
Err: serial
invalid MAC address in OTP 00:00:00:00:00:00Net:
Warning: ethernet@5800a000 (eth0) using random MAC address - fe:af:d6:78:94:dd
eth0: ethernet@5800a000
Autoboot in 1 seconds
Boot over mmc0!
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:5...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
198 bytes read in 0 ms
1: stm32mp15-buildroot
Retrieving file: /boot/zImage
5378288 bytes read in 236 ms (21.7 MiB/s)
append: root=/dev/mmcblk0p5 rootwait console=ttySTM0,115200 vt.global_cursor_default=0
Retrieving file: /boot/stm32mp153a-epic_miner_fw-mx.dtb
73418 bytes read in 4 ms (17.5 MiB/s)
## Flattened Device Tree blob at c4000000
 Booting using the fdt blob at 0xc4000000
 Using Device Tree in place at c4000000, end c4014ec9
 
Starting kernel ...

Although the device tree name is 153 the source is modified to 151.

compatible = "st,stm32mp153a-epic_miner_fw-mx", "st,stm32mp151";

[cfilipescu]

@Community member​ 

Were you able to reproduce it on your side?

[Olivier GALLIEN]

Hi @cfilipescu​ ,

No, but I think it's due to usage of U-boot SPL aka basic boot.

See here :

Boot chains overview - stm32mpu-ecosystem-v1

"system shutdown" is not supported in basic boot ... so probably the reboot.

ST has never supported basic boot for a product, and is no longer supported V1.2.

I really invite you to switch to more recent ecosystem and trusted boot.

If for any reason you would like to stick in this version the next step for investigation is to get early printk

Dmesg and Linux kernel log - stm32mpu-ecosystem-v1

Olivier

[cfilipescu]

@Community member​ 

I see, I didn't realize the system shutdown was not supported.

I am trying to switch over, but I was looking for a way to update the units in the field and my solution right now requires a reboot which would hang the 151 parts.

I will look into kernel-debug prints to see if I can figure out why the 151 parts hang when booting the kernel.

[cfilipescu]

@Community member​ 

After enabling the kernel early prints I found that it was getting stuck on initializing the second CPU (CPU1).

I have generated a patch to remove the second CPU from the stm32mp157 device tree as a temporary workaround to be able to reboot old images and update them to the new ecosystem v3.1.0.

This is good enough for me and I will not investigate this further. Thank you for the help.

From c566118ba32519144c2fc6f1c302643aab06ea12 Mon Sep 17 00:00:00 2001
Date: Mon, 31 Jan 2022 21:14:33 -0500
Subject: [PATCH] removed cpu1 from 157 device trees
 
---
 arch/arm/boot/dts/stm32mp157a-dk1.dts | 4 ----
 arch/arm/boot/dts/stm32mp157c-ed1.dts | 4 ----
 arch/arm/boot/dts/stm32mp157c.dtsi | 33 +--------------------------
 3 files changed, 1 insertion(+), 40 deletions(-)
 
diff --git a/arch/arm/boot/dts/stm32mp157a-dk1.dts b/arch/arm/boot/dts/stm32mp157a-dk1.dts
index 9ec45de3c664..b4f25b257f2e 100644
--- a/arch/arm/boot/dts/stm32mp157a-dk1.dts
+++ b/arch/arm/boot/dts/stm32mp157a-dk1.dts
@@ -166,10 +166,6 @@
 	cpu-supply = <&vddcore>;
 };
 
-&cpu1{
-	cpu-supply = <&vddcore>;
-};
-
 &dma1 {
 	sram = <&dma_pool>;
 };
diff --git a/arch/arm/boot/dts/stm32mp157c-ed1.dts b/arch/arm/boot/dts/stm32mp157c-ed1.dts
index f5e685d51caf..c364b5a832e3 100644
--- a/arch/arm/boot/dts/stm32mp157c-ed1.dts
+++ b/arch/arm/boot/dts/stm32mp157c-ed1.dts
@@ -141,10 +141,6 @@
 	cpu-supply = <&vddcore>;
 };
 
-&cpu1{
-	cpu-supply = <&vddcore>;
-};
-
 &dac {
 	pinctrl-names = "default";
 	pinctrl-0 = <&dac_ch1_pins_a &dac_ch2_pins_a>;
diff --git a/arch/arm/boot/dts/stm32mp157c.dtsi b/arch/arm/boot/dts/stm32mp157c.dtsi
index b2e4bd6ba066..ccb40ffc6de3 100644
--- a/arch/arm/boot/dts/stm32mp157c.dtsi
+++ b/arch/arm/boot/dts/stm32mp157c.dtsi
@@ -27,14 +27,6 @@
 			nvmem-cell-names = "part_number";
 		};
 
-		cpu1: cpu@1 {
-			compatible = "arm,cortex-a7";
-			device_type = "cpu";
-			reg = <1>;
-			clocks = <&rcc CK_MPU>;
-			clock-names = "cpu";
-			operating-points-v2 = <&cpu0_opp_table>;
-		};
 	};
 
 	cpu0_opp_table: cpu0-opp-table {
@@ -57,7 +49,7 @@
 		compatible = "arm,cortex-a7-pmu";
 		interrupts = <GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH>,
 			 <GIC_SPI 201 IRQ_TYPE_LEVEL_HIGH>;
-		interrupt-affinity = <&cpu0>, <&cpu1>;
+		interrupt-affinity = <&cpu0>;
 		interrupt-parent = <&intc>;
 	};
 
@@ -1578,14 +1570,6 @@
 					};
 				};
 
-				port@2 {
-					reg = <2>;
-					funnel_in_port2: endpoint {
-					 slave-mode; /* A7-2 input */
-					 remote-endpoint = <&etm2_out_port>;
-					};
-				};
-
 				port@4 {
 					reg = <4>;
 					funnel_in_port4: endpoint {
@@ -1680,21 +1664,6 @@
 			};
 		};
 
-		/* Cortex A7-2 */
-		etm2: etm@500dd000 {
-			compatible = "arm,coresight-etm3x", "arm,primecell";
-			reg = <0x500dd000 0x1000>;
-			cpu = <&cpu1>;
-			clocks = <&rcc CK_TRACE>;
-			clock-names = "apb_pclk";
-
-			port {
-				etm2_out_port: endpoint {
-					remote-endpoint = <&funnel_in_port2>;
-				};
-			};
-		};
-
 		cryp1: cryp@54001000 {
 			compatible = "st,stm32mp1-cryp";
 			reg = <0x54001000 0x400>;
-- 
2.34.1