Guidance on Debugging and Upgrading to OpenSTLinux Ecosystem v6

[VivekB]

Hi there,

I am currently working on upgrading our EV charging solution from OpenSTLinux Ecosystem v4 (Linux kernel 5.15) to Ecosystem v6 (Linux kernel 6.6).

As part of the process to ensure we are on the right track, I have successfully upgraded to the minor release: OpenSTLinux release v4.1.0 (Linux 5.15-stm32mp-r2.2), and it is functioning as expected. The next step is to proceed with the upgrade to Ecosystem v6 (Linux kernel 6.6).

In preparation for this, I regenerated the DTS files using STM32CubeMX_6.13.0 and loaded the existing .ioc file. While regenerating the DTS files using STM32CubeMX_6.1.3 and loading the existing .ioc file, I selected the Migrate option when prompted by the tool. Could you please confirm if this is the correct choice, or would selecting Continue be more appropriate in this case?

Current Setup:

I am now attempting to recompile the following components with updated versions:

• TF-A: v2.8-stm32mp
• OP-TEE: 3.19.0-stm32mp
• U-Boot: v2023.10-stm32mp

 

Issue Encountered:

In the process, I mistakenly compiled OP-TEE with the older version of TF-A and flashed it onto the board, which resulted in the board becoming unresponsive after few initial prints on the console ("bricked"). I am concerned that a similar situation may arise even with a new board if there are mismatches or issues with any of the components (TF-A, OP-TEE, or U-Boot). I get the following on the console:

 

NOTICE: Early console setup
PANIC at PC : 0x2ffe8b55

 

Request for Assistance:

Debugging Process: Could you provide guidance on the proper mechanism to debug TF-A, OP-TEE, and U-Boot?

• I am open to turning off TF-A and focusing on bringing up the new U-Boot first, but I am unsure how to debug the board effectively in case something goes wrong during the process. Particularly if anything goes wrong in uboot I do not have a mechanism to even talk via usb (stm32prog usb 0 - that's what we use to connect to the CubeMx Programmer).  
• What tools or techniques are recommended to recover and debug the board if it becomes unresponsive?

We are using Buildroot for this project. Please let me know if any additional information is needed to assist with debugging or recovery. Your guidance would be highly appreciated to ensure a smooth upgrade process and avoid bricking the board again.

I am already referring to this post: https://community.st.com/t5/stm32-mpus/faq-stm32mpus-how-to-migrate-stm32cubemx-project-from-a-previous/ta-p/49262  

But doesn't talk about the debugging part mentioned above. 

Many thanks for your assistance.

Best regards,
Vivek

[GatienC]

Hello Vivek,

You can take a look at: Wrapper for FSBL images

To use with an OpenOCD/GDB setup (GDB )

This will allow you to attach at the entry point of TF-A.

On the other hand, the tags you provided are related to OSTL V5.x, is this what you wanted to work on?

 

[VivekB]

Hi @GatienC  thanks a lot for your response. I will explore this and get back if I have any questions. But I am not sure what you asked in this line: 

>> On the other hand, the tags you provided are related to OSTL V5.x, is this what you wanted to work on? 

Can you please elaborate the question please? Apologies. 

[VivekB]

I am trying to upgrade to the from OpenSTLinux Ecosystem v4 (Linux kernel 5.15) to Ecosystem v6 (Linux kernel 6.6).

[GatienC]

Hello Vivek,

I meant that the branch names you provided for OP-TEE and TF-A are part of the OSTLV5.x, not OSTLV6.x :)

Please take a look at the OSTL release note (Chapter: OpenSTLinux for Arm^® Cortex^®-A) to get the tags for the OSTLV6.x.

Best regards,

Gatien

[VivekB]

Ah! I see ..that's a big mistake on my part. Apologies and thanks a lot for pointing out. I need to get my head around this and then come back to you for any further questions. Thanks a bunch! 

[GatienC]

Hi Vivek,

According to the release note, yes.

Regards,

Gatien

[VivekB]

Hi @GatienC thanks for your response. I am trying to compile the following version of TF-A:

 

Trusted Firmware-A (TF-A): v2.10-stm32mp-r1

 

And it seems to be expecting mbedtls package. My earlier mbedtls package was of version 2.8.1. Now I have tried two the following two mbedtls pacge versions:

mbedtls 3.4.0 as well as mbedtls 3.5.0. But both seems to be failing with the below error:

 

make[2]: *** No rule to make target 'mbedtls-3.5.0/library/pk_ecc.c', needed by 'output/build/arm-trusted-firmware-custom/build/stm32mp1/release/libmbedtls/pk_ecc.o'. Stop.

 

This file pk_ecc.c seems to be included in the below tf-a makefile: 

arm-trusted-firmware-custom/drivers/auth/mbedtls/mbedtls_common.mk   

 

LIBMBEDTLS_SRCS		+= $(addprefix ${MBEDTLS_DIR}/library/,		\
					aes.c 				\
					asn1parse.c 			\
					asn1write.c 			\
					cipher.c 			\
					cipher_wrap.c 			\
					constant_time.c			\
					memory_buffer_alloc.c		\
					oid.c 				\
					platform.c 			\
					platform_util.c			\
					bignum.c			\
					bignum_core.c			\
					gcm.c 				\
					md.c				\
					pk.c 				\
					pk_ecc.c 			\
					pk_wrap.c 			\
					pkparse.c 			\
					pkwrite.c 			\
					sha256.c 		\
					sha512.c 		\
					ecdsa.c				\
					ecp_curves.c			\
					ecp.c				\
					rsa.c				\
					rsa_alt_helpers.c		\
					x509.c 				\
					x509_crt.c 			\
					)

 

Looking at this I suspect there is a mismatch between the mbedtls version the tf-a is expecting than the one I am using. 

Any idea what is the compatible mbedtls version for the following tf-a?

v2.10-stm32mp-r1

In the mean time I am looking into this further. Please let me know if you have any insight into this please. 

Many thanks 

Regards,

Vivek

[GatienC]

Hello Vivek,

 

Yes, please avec a look at docs/getting_started/prerequisites.rst in TF-A sources.

Regards,

Gatien