Boot Failure on STM32MP157C: Secure Mode Issues (smc execution failure)

[VivekB]

Hi, 

I am working with an STM32MP157CAA Rev.Z on a custom STM32CubeMX board running OpenSTLinux 6.6 (Yocto Scarthgap MPU v24.11.06). I have successfully integrated and bootstrapped various boot components.

I first got the TF-A and OPTEE to boot the system and now it is also able to bring up the uboot. However, while trying to boot up the uboot gets into an "secure mode execution errors". I am not sure where it is coming from? We have hash-and-boot-options_hash-and-boot-options.bin flashed into the OTP area. Is that something could potentially lead to this type of issue? 

BL2 (TF-A) Loading

• BL2 (TF-A) executes as expected and starts platform initialization.

• The board is in trusted mode, and secure boot appears to be enabled.

• Below are the logs confirming BL2 is executing:

 

NOTICE: CPU: STM32MP157CAA Rev.Z
NOTICE: Model: STMicroelectronics custom STM32CubeMX board - openstlinux-6.6-yocto-scarthgap-mpu-v24.11.06
NOTICE: BL2: v2.10-stm32mp1-r1.0(release)
NOTICE: BL2: Built : 14:58:08, Mar 4 2025
NOTICE: TRUSTED_BOARD_BOOT support enabled

 

Image Loading Sequence

• BL2 successfully attempts to load various images, including:

  • TF-A (tf-a-stm32mp157c-ccb-mx_Signed.stm32)
  • OP-TEE (tos-fw.bin, tos-fw-extra1.bin)
  • SCP firmware (scp-fw.bin)
  • NT firmware (nt-fw.bin)

 

ERROR: BL2: Preparing to load image id 1 (tf-a-stm32mp157c-ccb-mx_Signed.stm32)
ERROR: BL2: Loading image id 1 (tf-a-stm32mp157c-ccb-mx_Signed.stm32)
ERROR: BL2: Calling load_auth_image() for image id 1 with base 0x2ffff000
ERROR: ROTPK is not deployed on platform. Skipping ROTPK verification.

 

"ROTPK is not deployed", looks like Root of Trust Public Key (ROTPK) verification is being skipped. I am not sure whether this is expected behaviour in my setup or what is causing this.

OP-TEE Boot & Peripheral Initialization

• OP-TEE initialises successfully and maps secure memory regions.

• Secure components like TZC400, STPMIC, and STM32MP1 clocks are initialized.

• However, multiple SMC call failures appear:

 

stm32_smc: Failed to exec svc=82001003 op=1 in secure mode (err = -1)

 

U-Boot Execution

• U-Boot executes successfully but reports errors related to secure mode calls:

 

stm32_smc: Failed to exec svc=82001003 op=1 in secure mode (err = -1)

 

EFI system partition detection fails, which is unexpected:

 

No EFI system partition
Failed to persist EFI variables

 

At this point, the system does not proceed further due to the OP-TEE watchdog panic.

 

E/TC:0 Panic 'Watchdog' at core/drivers/stm32_iwdg.c:228 <stm32_iwdg_it_handler>

 

I have also attached the full boot_log.txt in the attachment for reference. 

The below is the details of my platform: 

Hardware & Software Details

• CPU: STM32MP157CAA Rev.Z
• Board: STMicroelectronics custom STM32CubeMX board
• Software Version: OpenSTLinux 6.6 Yocto Scarthgap MPU (v24.11.06)
• TF-A Version: v2.10-stm32mp1-r1.0 (Release)
• U-Boot Version: 2023.10-stm32mp-r1
• OP-TEE Version: REL_0.8.7-8-g79647115eb
• Boot Mode: Trusted Mode with Secure Boot Enabled

I need some help to understand what are the areas I need to investigate to resolve this issue. 

Many Thanks

Best Regards, 

Vivek

[VivekB]

Hi,

One more information regarding this, I just figured out I have the following in my OPTEE conf file: 

 

CFG_STM32MP15=y
CFG_STM32MP_PROFILE=system_services
CFG_STM32MP1_OPTEE_IN_SYSRAM=n

 

CFG_STM32MP_PROFILE=system_services

Does this OP-TEE is not running from SYSRAM but rather from DDR? 

Also, figured this: 

 

~/tf-a-local/arm-trusted-firmware$ grep -rn "82001003"
plat/st/stm32mp1/include/stm32mp1_smc.h:30:#define STM32_SMC_BSEC 0x82001003

 

Looks like the SMC call failing in U-Boot is related to BSEC (Boot Secure Engine Controller).

 

~/tf-a-local/arm-trusted-firmware$ grep -rn "STM32_SMC_BSEC" plat/st/stm32mp1/
plat/st/stm32mp1/include/stm32mp1_smc.h:21: * STM32_SMC_BSEC call API
plat/st/stm32mp1/include/stm32mp1_smc.h:25: * Argument a1: (input) Service ID (STM32_SMC_BSEC_xxx)
plat/st/stm32mp1/services/stm32mp1_svc_setup.c:35:	case STM32_SMC_BSEC:

 

 

I can see the stm32mp1_svc_setup.c file inside the tf-a repository (code base). But I can''t see it is being compiled. 

However, the same is compiled as part of optee-os code base:

 

 

find . -name "stm32mp1_svc_setup.o" 2>/dev/null 
./output/build/optee-os-custom/out/core/arch/arm/plat-stm32mp1/nsec-service/stm32mp1_svc_setup.o

 

The following error seems to be coming from the file u-boot/arch/arm/match-stm32/include/match/stm32mp1_smc.h:

 

Board: stm32mp1 in trusted mode (st,stm32mp157c-ccb-mx)
VBDBG:stm32_smc: Failed to exec svc=82001003 op=1 in secure mode (err = -1)

#ifdef CONFIG_ARM_SMCCC
static inline u32 stm32_smc(unsigned long svc, unsigned long op,
			 unsigned long data1, unsigned long data2,
			 u32 *result)
{
	struct arm_smccc_res res;
	arm_smccc_smc(svc, op, data1, data2, 0, 0, 0, 0, &res);
	if (res.a0) {
		pr_err("VBDBG:%s: Failed to exec svc=%lx op=%lx in secure mode (err = %ld)\n",
		 __func__, svc, op, res.a0);
		return -EINVAL;
	}
	if (result)
		*result = (u32)res.a1;
	return 0;
}
#else

 

But I am not sure where arm_smcc_res is landing. The plat_svc_smc_handler is in tf-a code in the file plat/st/stm32mp1/services/stm32mp1_svc_setup.c but that file is not even being compiled at the moment: 

 

~/tf-a-local/arm-trusted-firmware$ grep -rn "smc" plat/st/stm32mp1/
plat/st/stm32mp1/stm32mp1_critic_power_wrapper.S:13:#include <smccc_helpers.h>
plat/st/stm32mp1/services/stm32mp1_svc_setup.c:17:#include <stm32mp1_smc.h>
plat/st/stm32mp1/services/stm32mp1_svc_setup.c:25:void plat_svc_smc_handler(uint32_t smc_fid, u_register_t x1,
plat/st/stm32mp1/services/stm32mp1_svc_setup.c:31:	switch (smc_fid) {
plat/st/stm32mp1/services/stm32mp1_svc_setup.c:43:		scmi_smt_fastcall_smc_entry(0);
plat/st/stm32mp1/services/stm32mp1_svc_setup.c:46:		scmi_smt_fastcall_smc_entry(1);
plat/st/stm32mp1/services/stm32mp1_svc_setup.c:50:		WARN("Unimplemented STM32MP1 Service Call: 0x%x\n", smc_fid);
plat/st/stm32mp1/services/bsec_svc.c:14:#include <stm32mp1_smc.h>
vivekb@vivekb-ThinkBook-16-G6-IRL:~/tf-a-local/arm-trusted-firmware$ grep -rn "plat_svc_smc_handler" plat/st/stm32mp1/
plat/st/stm32mp1/services/stm32mp1_svc_setup.c:25:void plat_svc_smc_handler(uint32_t smc_fid, u_register_t x1,

 

I am slightly confused whether this file should be compiled a s apart of tf-a or optee-os or both? Does it at all matter? Apologies for the speculative question. 

 

Did some further digging: 

grep "CFG_STM32MP_PROFILE" output/build/optee-os-custom/out/conf.mk 
CFG_STM32MP_PROFILE=system_services

With this configuration would it support secure services like BSEC? I am not sure. 

Thanks,

Vivek

 

[VivekB]

Update: 

I have now modified the optee makefile as below: 

git diff core/arch/arm/plat-stm32mp1/conf.mk
diff --git a/core/arch/arm/plat-stm32mp1/conf.mk b/core/arch/arm/plat-stm32mp1/conf.mk
index 3b3753986..be29fc892 100644
--- a/core/arch/arm/plat-stm32mp1/conf.mk
+++ b/core/arch/arm/plat-stm32mp1/conf.mk
@@ -124,11 +124,15 @@ ifeq ($(CFG_STM32MP13),y)
 CFG_STM32MP_PROFILE ?= secure_and_system_services
 endif #CFG_STM32MP13
 
+
 ifeq ($(CFG_STM32MP15),y)
 # STM32MP15: default select system_services, OP-TEE executes in DDR
 # (i.e. CFG_STM32MP1_OPTEE_IN_SYSRAM=n).
 # Alternate secure_and_system_services executes in SRAM
 # (i.e. CFG_STM32MP1_OPTEE_IN_SYSRAM=y).
+CFG_STM32MP1_OPTEE_IN_SYSRAM = y
+CFG_STM32MP_PROFILE = secure_and_system_services
+
 ifeq ($(CFG_STM32MP1_OPTEE_IN_SYSRAM),y)
 $(call force,CFG_STM32MP_PROFILE,secure_and_system_services)
 endif
@@ -140,6 +144,11 @@ $(call force,CFG_STM32MP1_OPTEE_IN_SYSRAM,n,Required by system_services profile)
 endif
 endif #CFG_STM32MP15
 
+$(info CFG_STM32MP15=$(CFG_STM32MP15))
+$(info CFG_STM32MP_PROFILE=$(CFG_STM32MP_PROFILE))
+$(info CFG_STM32MP1_OPTEE_IN_SYSRAM=$(CFG_STM32MP1_OPTEE_IN_SYSRAM))
+
+
 ifeq ($(filter $(CFG_STM32MP_PROFILE),system_services secure_and_system_services),)
 $(error CFG_STM32MP_PROFILE shall be one of system_services or secure_and_system_services)
 endif

 And when I compile optee now I can see the below settings: 

CFG_STM32MP15=y
CFG_STM32MP_PROFILE=secure_and_system_services
CFG_STM32MP1_OPTEE_IN_SYSRAM=y

So the optee is now in secure_and_system_services mode for sure. However when I now try booting the board it fails as below: 

NOTICE: CPU: STM32MP157CAA Rev.Z
NOTICE: Model: STMicroelectronics custom STM32CubeMX board - openstlinux-6.6-yocto-scarthgap-mpu-v24.11.06
NOTICE: Bootrom authentication failed
NOTICE: BL2: v2.10-stm32mp1-r1.0(release):REL_0.8.7-8-g79647115eb-dirty(79647115)
NOTICE: BL2: Built : 14:08:49, Mar 5 2025
NOTICE: TRUSTED_BOARD_BOOT support enabled
ERROR: BL2: Doing platform setup
ERROR: BL2: Preparing to load image id 1 (tf-a-stm32mp157c-ccb-mx_Signed.stm32)
ERROR: BL2: Loading image id 1 (tf-a-stm32mp157c-ccb-mx_Signed.stm32)
ERROR: BL2: Calling load_auth_image() for image id 1 (tf-a-stm32mp157c-ccb-mx_Signed.stm32) with base 0x2ffff000
ERROR: VBDBG: [common/bl_common.c:load_image:81] Entering function, image_id=17
ERROR: VBDBG: [common/bl_common.c:load_image:89] Image Info: image_base=0x2ffff000, image_max_size=0x1000
ERROR: VBDBG: [common/bl_common.c:load_image:108] Loading image id=17 at address 0x2ffff000
ERROR: VBDBG: [common/bl_common.c:load_image:138] Image id=17 loaded: 0x2ffff000 - 0x2ffff23f (Size: 0x23f)
NOTICE: ROTPK is not deployed on platform. Skipping ROTPK verification.
ERROR: VBDBG: [common/bl_common.c:load_image:81] Entering function, image_id=1
ERROR: VBDBG: [common/bl_common.c:load_image:89] Image Info: image_base=0x2ffff000, image_max_size=0x1000
ERROR: VBDBG: [common/bl_common.c:load_image:108] Loading image id=1 at address 0x2ffff000
ERROR: VBDBG: [common/bl_common.c:load_image:138] Image id=1 loaded: 0x2ffff000 - 0x2ffff1ea (Size: 0x1ea)
ERROR: BL2: Preparing to load image id 4 (tos-fw.bin)
ERROR: BL2: Loading image id 4 (tos-fw.bin)
ERROR: BL2: Calling load_auth_image() for image id 4 (tos-fw.bin) with base 0xde000000
ERROR: VBDBG: [common/bl_common.c:load_image:81] Entering function, image_id=7
ERROR: VBDBG: [common/bl_common.c:load_image:89] Image Info: image_base=0xde000000, image_max_size=0x2000000
ERROR: VBDBG: [common/bl_common.c:load_image:108] Loading image id=7 at address 0xde000000
ERROR: VBDBG: [common/bl_common.c:load_image:138] Image id=7 loaded: 0xde000000 - 0xde000284 (Size: 0x284)
NOTICE: ROTPK is not deployed on platform. Skipping ROTPK verification.
ERROR: VBDBG: [common/bl_common.c:load_image:81] Entering function, image_id=10
ERROR: VBDBG: [common/bl_common.c:load_image:89] Image Info: image_base=0xde000000, image_max_size=0x2000000
ERROR: VBDBG: [common/bl_common.c:load_image:108] Loading image id=10 at address 0xde000000
ERROR: VBDBG: [common/bl_common.c:load_image:138] Image id=10 loaded: 0xde000000 - 0xde00022a (Size: 0x22a)
ERROR: VBDBG: [common/bl_common.c:load_image:81] Entering function, image_id=14
ERROR: VBDBG: [common/bl_common.c:load_image:89] Image Info: image_base=0xde000000, image_max_size=0x2000000
ERROR: VBDBG: [common/bl_common.c:load_image:108] Loading image id=14 at address 0xde000000
ERROR: VBDBG: [common/bl_common.c:load_image:138] Image id=14 loaded: 0xde000000 - 0xde0002e2 (Size: 0x2e2)
ERROR: VBDBG: [common/bl_common.c:load_image:81] Entering function, image_id=4
ERROR: VBDBG: [common/bl_common.c:load_image:89] Image Info: image_base=0xde000000, image_max_size=0x2000000
ERROR: VBDBG: [common/bl_common.c:load_image:108] Loading image id=4 at address 0xde000000
ERROR: VBDBG: [common/bl_common.c:load_image:138] Image id=4 loaded: 0xde000000 - 0xde00002c (Size: 0x2c)
ERROR: BL2: OP-TEE Load Address: 0xde000000
ERROR: BL2: OP-TEE Image Size: 0x2c
ERROR: OPTEE header parse error.
PANIC at PC : 0x2ffeeb9b

 

[VivekB]

I did a comparison of the previous and current (modified/upgraded) file sizes: 

Previous trusted boot file sizes

vivekb@vivekb-ThinkBook-16-G6-IRL:~/workspace/source/JLRA-2007/SSB-buildroot/output/images/extracted_fip$ ls -la 
total 2736
drwxrwxr-x 2 vivekb vivekb 4096 Mar 5 14:38 .
drwxr-xr-x 4 vivekb vivekb 4096 Mar 5 14:37 ..
-rw-rw-r-- 1 vivekb vivekb 574 Mar 5 14:38 501D8DD2-8BCE-49A5-84EB-559A9F2EAEAF.bin
-rw-r--r-- 1 vivekb vivekb 1378678 Mar 5 14:38 fip.bin
-rw-rw-r-- 1 vivekb vivekb 506 Mar 5 14:38 fw-config.bin
-rw-rw-r-- 1 vivekb vivekb 84200 Mar 5 14:38 hw-config.bin
-rw-rw-r-- 1 vivekb vivekb 820768 Mar 5 14:38 nt-fw.bin
-rw-rw-r-- 1 vivekb vivekb 597 Mar 5 14:38 nt-fw-cert.bin
-rw-rw-r-- 1 vivekb vivekb 558 Mar 5 14:38 nt-fw-key-cert.bin
-rw-rw-r-- 1 vivekb vivekb 44 Mar 5 14:38 tos-fw.bin
-rw-rw-r-- 1 vivekb vivekb 737 Mar 5 14:38 tos-fw-cert.bin
-rw-rw-r-- 1 vivekb vivekb 108512 Mar 5 14:38 tos-fw-extra1.bin
-rw-rw-r-- 1 vivekb vivekb 360448 Mar 5 14:38 tos-fw-extra2.bin
-rw-rw-r-- 1 vivekb vivekb 554 Mar 5 14:38 tos-fw-key-cert.bin
-rw-rw-r-- 1 vivekb vivekb 644 Mar 5 14:38 trusted-key-cert.bin

 

Current fip files sizes

~/workspace/source/27-01-2025/SSB-buildroot/output/images/extracted_fip$ ls -la 
total 3640
drwxrwxr-x 2 vivekb vivekb 4096 Mar 5 14:42 .
drwxr-xr-x 5 vivekb vivekb 4096 Mar 5 14:42 ..
-rw-rw-r-- 1 vivekb vivekb 575 Mar 5 14:42 501D8DD2-8BCE-49A5-84EB-559A9F2EAEAF.bin
-rw-r--r-- 1 vivekb vivekb 1842256 Mar 5 14:42 fip.bin
-rw-rw-r-- 1 vivekb vivekb 490 Mar 5 14:42 fw-config.bin
-rw-rw-r-- 1 vivekb vivekb 84448 Mar 5 14:42 hw-config.bin
-rw-rw-r-- 1 vivekb vivekb 1172480 Mar 5 14:42 nt-fw.bin
-rw-rw-r-- 1 vivekb vivekb 597 Mar 5 14:42 nt-fw-cert.bin
-rw-rw-r-- 1 vivekb vivekb 558 Mar 5 14:42 nt-fw-key-cert.bin
-rw-rw-r-- 1 vivekb vivekb 44 Mar 5 14:42 tos-fw.bin
-rw-rw-r-- 1 vivekb vivekb 738 Mar 5 14:42 tos-fw-cert.bin
-rw-rw-r-- 1 vivekb vivekb 97264 Mar 5 14:42 tos-fw-extra1.bin
-rw-rw-r-- 1 vivekb vivekb 483328 Mar 5 14:42 tos-fw-extra2.bin
-rw-rw-r-- 1 vivekb vivekb 554 Mar 5 14:42 tos-fw-key-cert.bin
-rw-rw-r-- 1 vivekb vivekb 644 Mar 5 14:42 trusted-key-cert.bin

I am not seeing much of a difference. 

[GatienC]

Hello Vivek,

First of all, you can learn more about the two different OP-TEE profiles at: STM32MPU_OP-TEE_profiles 

Whether OP-TEE should run in internal RAM or not is dependent on your choice of running OP-TEE in memory that can be secured. The question is: do I want to have enhanced security hardening on my platform? It is done by enabling CFG_STM32MP1_OPTEE_IN_SYSRAM.

More information at: OP-TEE_in_SYSRAM_and_SRAMx 

Please note that TF-A should be compiled accordingly so that it knows where to load OP-TEE (DDR vs SYSRAM). Given that OP-TEE will be constrained by the memory size, be aware that it will affect performances as OP-TEE pager will be embedded. You can assign more contiguous RAM memory (SRAMs) to give more space to OP-TEE (explained in the Wiki).

Now, regarding the following trace:

ROTPK is not deployed on platform. Skipping ROTPK verification.

I guess you want to perform trusted boot on your platform?

NOTICE: TRUSTED_BOARD_BOOT support enabled

 This probably indicates that your chip is not in a closed state, then TF-A doesn't verify the signatures of your firmware when booting. (plat_get_rotpk_info() in plat/st/common/stm32mp_trusted_boot.c in TF-A).

Is TF-A compiled with 

STM32MP1_OPTEE_IN_SYSRAM?

 

Hope this helps,

Gatien

 

 

 

[VivekB]

Hi @GatienC , 

 

Thank you very much for the detailed response. I will go through all these and try to find out more and I will come back if I have any questions. 

 

Many thanks 

Best Regards,

Vivek

[GatienC]

Hello Vivek,

About OP-TEE running in system_services or secure_and_system_services: if you want isolate operations such as cryptographic operations, random number generation at runtime, etc... then it make sense to compile OP-TEE with secure_and_system_services profile. 

Supporting trusted boot and having secure runtime services is two different things that are not linked. You can very well have OP-TEE only embedding system_services if your only goal is to authenticate your firmware.

 

Now, regarding your smc errors, the SVC ID: 0x82001003 corresponds to the BSEC. It probably means that U-Boot is trying to access some fuse (OTP bits) through an SMC (Secure Monitor Call) and fails to achieve it. Maybe understanding what leads to this SMC call will help you identify what fails (USB? Serial? ...).

But anyways it's really strange that this feature is called, looking at the code in U-Boot in arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c, this legacy feature shouldn't be called when OP-TEE is in the bootchain. Instead, we expect to call the OP-TEE BSEC PTA. Is CONFIG_OPTEE set in U-Boot?

 

Note:

When debugging OP-TEE related errors, I highly suggest enabling at least debug log level by specifying CFG_TEE_CORE_LOG_LEVEL=3 when compiling OP-TEE. This, for instance, will help you identify what caused

E/TC:0 0 call_initcalls:43 Initcall __text_start + 0x0002e278 failed

For more information on OP-TEE, you can always take a look at the official documentation: OP-TEE doc or the stm32mpu wiki.

I hope this helps, it's always nice to see you take time to detail your questions.

Gatien

[VivekB]

Hi @GatienC that is really helpful and yes I would not like to over complicate it with features  (profile secure_and_system_services in this case) which I don't need. So I will rather run in the system_services profile to keep things simple. I will try to increase the log level and debug it again. I will look this further and come back. I can't appreciate more your time to time help and support in this. I am truly thankful.  

 

Many thanks 

Best Regards,

Vivek

[Tom-IowaSoft]

After adding some debug statements (*TRN*) to code it appears that in my case...

There is no Tee struct in the the efuse@5c005000 device/driver. This results in it calling stm32mp_bsec_read_shadow() instead of OP-TEE in stm32mp_bsec_read() defined in bsec.c 

The Tee struct is private data from the efuse device and is retrieve via dev_get_priv(dev)

*TRN* in stm32mp_bsec_read(); udevice="efuse@5c005000"
*TRN* CONFIG_OPTEE=y, ,priv->tee=0x00000000 in stm32mp_bsec_read()

*TRN* in stm32mp_bsec_read_shadow()

stm32_smc: Failed to exec svc=82001003 op=1 in secure mode (err = -1)

So does this mean that efuse@5c005000 needs to be moved down into etzpc in stm32mp151.dtsi ?

.

 

[GatienC]

Hello,

Thank you for the details. If there's priv->tee=0x00000000, then the op-tee driver may not be probed. Can you check that the OP-TEE node is present in your board.dtb using a tool like "fdtdump" please? The OP-TEE node is define in xx-scmi.dtsi device tree file because of legacy. This file should be included by the board, you can see what has been done on the STM32 reference boards.

I'm currently investigating if there are issue with the generation tools.

 

I hope this helps,

Gatien

[Tom-IowaSoft]

Yes, I was able to determine this late last night.  I had to add the following to the device tree root node. The strange thing is that it solved the issue for all but the first three times that error occurs just after u-boot displays it's title line. The first three times it continued to show priv->tee == 0x00000000.  We did not use any generation tool. We started from the Odyssey device tree since our board uses the Odyssey SOM from Seeed Studio.

    firmware {

        optee {

            compatible = "linaro,optee-tz";

            method = "smc";

        };

    };

 

[GatienC]

I suggest to add: bootph-some-ram; property to the OP-TEE node, suggesting that it should be probed before relocation. Maybe that'll solve you issue. You can refer to arch/arm/dts/stm32mp15-scmi-u-boot.dtsi.

 

I hope this solves your issue,

Gatien

 

 

[GatienC]

Hello @VivekB ,

Looking at your device tree, I'm not sure what you're trying to do.

SDMMC1 is your boot storage and seems to be an Emmc, right?  (deduced from mmc-ddr-3_3v; and bus-width = <8>; )

If you don't use SDMMC2, then please disable the node, there's no property to make it functional in your device tree. And it seems that you use Wifi on sdmmc3.

Which instance of sdmmc is causing this trace? Are all SDMMC instances secure configuration  that you use compatible with U-Boot (Non-secure, non isolated for cortex M4)?

Cheers,

Gatien

 

 

[VivekB]

Hi @GatienC apologies couldn't reply earlier. I was doing a bit of experiemnts with the sdmmc nodes I have. It would be deemed as my lack of understanding about the terminologies used in the uboot for the sdmmc. So trying to enable sdmmc2 was a failed attempt at that. Basically at the moment I facing the issue, while trying to download the code it fails with the following error: 

When I look into the log it shows the below: 

mmc_init: -110, time 24
Error: mmc device 1 not found

If I drop at the uboot prompt, and do a mmc rescan it finds the mmc1. So I tried implementing a rescan mechanims in the uboot code. If I do that it detects the mmc1 and the above error goes away but then it cannot fetch the erase block size for some reason and it fails again. Thta's why I was trying to check if SDMMC2 node has to be enabled in my project speciifc dts file and if that helps. But that didn't help. Sorry bit vague in my description but I am not entirely sure why it fails to detect mmc1. I have also tried changing the HW and it doesn't look like a HW issue. I think there maybe something wrong in my dts file and hence the error. Many thanks, Vivek

[GatienC]

Hi Vivek, I'm clearly not an expert on this but I expect most of the patch to be applied to core/drivers/regulator/regulator_dt.c for the device tree part and maybe handle the flag in pmic_supplied_init()?

 

Cheers,

Gatien

[VivekB]

Thanks @GatienC for the lead, I will investigate this area and come back.

BR, Vivek