soc: s32k3: fix RAM retention

Initialize TCM and SRAM contents only after a destructive reset (e.g.
PoR reset). SRAM retains content during functional reset through a
hardware mechanism, therefore accesses do not cause content
corruption errors.

Fixes #75912

Signed-off-by: Manuel Argüelles <marguelles.dev@gmail.com>
(cherry picked from commit ec72890)

soc/nxp/s32/common/power_soc.c

@@ -87,6 +87,9 @@ static int nxp_s32_power_init(void)
 
 	Power_Ip_Init(&power_cfg);
 
+	/* Read and clear the reset reason to avoid persisting it across resets */
+	(void)Power_Ip_GetResetReason();
+
 	return 0;
 }
 

soc/nxp/s32/s32k3/s32k3xx_startup.S

@@ -8,19 +8,35 @@
 #include <zephyr/toolchain.h>
 #include <zephyr/linker/sections.h>
 
+#define MC_RGM_BASE 0x4028C000
+#define MC_RGM_DES  0x0
+#define MC_RGM_FES  0x8
+
 _ASM_FILE_PROLOGUE
 
 GTEXT(z_arm_platform_init)
 
 SECTION_FUNC(TEXT, z_arm_platform_init)
 
 	/*
-	 * After chip power-on reset, SRAM must be initialized to a known value
-	 * using a 64-bit master before 32-bit masters can read or write to RAM.
+	 * On destructive reset, SRAM and TCM memories must be initialized to a known value using a
+	 * 64-bit master before 32-bit masters can read or write to them. Note that SRAM retains
+	 * content during functional reset through a hardware mechanism, therefore accesses do not
+	 * cause any content corruption errors.
 	 *
 	 * This is implemented directly in ASM, to ensure no stack access is performed.
 	 */
 
+	/* If we come from a destructive reset, then ignore functional reset flags */
+	ldr r1, =MC_RGM_BASE
+	ldr r2, [r1, MC_RGM_DES]
+	cmp r2, 0x0
+	bne ECC_INIT
+	ldr r2, [r1, MC_RGM_FES]
+	cmp r2, 0x0
+	bne ECC_END
+
+ECC_INIT:
 	ldr r1, = DT_REG_ADDR(DT_CHOSEN(zephyr_sram))
 	ldr r2, = DT_REG_SIZE(DT_CHOSEN(zephyr_sram))
 
@@ -64,4 +80,5 @@ DTCM_LOOP:
 	bge DTCM_LOOP
 #endif
 
+ECC_END:
 	bx lr