2025-01-27 03:10 AM - edited 2025-01-27 03:10 AM
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?
I am now attempting to recompile the following components with updated versions:
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
Debugging Process: Could you provide guidance on the proper mechanism to debug TF-A, OP-TEE, and U-Boot?
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
2025-01-27 05:59 AM
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?
2025-01-27 06:52 AM
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.
2025-01-27 06:53 AM
I am trying to upgrade to the from OpenSTLinux Ecosystem v4 (Linux kernel 5.15) to Ecosystem v6 (Linux kernel 6.6).
2025-01-27 07:03 AM - edited 2025-01-27 07:03 AM
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
2025-01-27 07:12 AM
Hi @GatienC
Some additional information on what we flash is as below:
Thought may add some extra information in this context.
2025-01-27 12:06 PM
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!
2025-01-29 01:13 AM
Hi @GatienC good morning. I just wanted to be sure that I have now identified the right component for this purpose, the following are the components I am looking at now:
Linux Kernel: 6.6-stm32mp-r1 (v6.6.48)
Trusted Firmware-A (TF-A): v2.10-stm32mp-r1
U-Boot: v2023.10-stm32mp-r1
OP-TEE: 4.0.0-stm32mp-r1
Are these all looking the right versions?
Many thanks
Regards,
Vivek
2025-01-29 02:42 AM
Hi Vivek,
According to the release note, yes.
Regards,
Gatien
2025-01-30 06:11 AM
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