STM32MP157x: arm-trusted-firmware update to v2.4-stm32mp custom board

[AZaki.2]

I have a custom board based on stm32mp157c which is working with arm-trusted-firmware version v2.2-stm32mp.

I updated tf-a to version v2.4-stm32mp version keeping the same DTS file but the problem is that tf-a is starting and hangs at loading sp min as follow, no u-boot is showing:

NOTICE:  CPU: STM32MP157CAA Rev.Z
NOTICE:  Model: XYZ Variant 3
NOTICE:  BL2: v2.4-r2.1-nofip(release):v2.4-stm32mp-r2-37-gaaa0ea904-dirty
NOTICE:  BL2: Built : 17:56:47, Aug 25 2022
NOTICE:  BL2: Booting BL32
NOTICE:  SP_MIN: v2.4-r2.1-nofip(release):v2.4-stm32mp-r2-37-gaaa0ea904-dirty
NOTICE:  SP_MIN: Built : 17:56:54, Aug 25 2022

u-boot.stm32 is perfeclty loading and woking if I revert to v2.2-stm32mp.

I have no idea where to look !

[OlivierK]

Hi AZaki.2 (Community Member) 

There are lots of change between the 2 versions. You an also investigate in debug mode increasing the trace level to max to get more inputs from the log. However I would suggest to port the changes made on the DTS to a stable openstlinux environment release (an not just only updating TF-A).

Beware that the BSP FIP version is the only one supported on OpenSTLinux V4.0 onwards:

https://wiki.st.com/stm32mpu/wiki/STM32_MPU_OpenSTLinux_release_note_-_v4.0.0

From this release OpenSTLinux v4.0.0, FIP configuration is the only packaging format supported for boot loaders 

[AZaki.2]

Hi Oliver,

Thanks for the suggestion, I did try indeed to enable debugging in TF-A and found out excalty where the problem is originated:

https://github.com/STMicroelectronics/arm-trusted-firmware/blob/v2.4-stm32mp/plat/st/stm32mp1/sp_min/sp_min_setup.c#L589

If I comment the line above, u-boot is started correctly ( I use the legacy image by enabling STM32MP_USE_STM32IMAGE=1 )

I'm wondering why is it so ? I don't get that problem in old tf-a (v2.2) and how can I fix that ?

I did similar setup using the same source but enabling stm32mp175c-dk2 with a disco devkit and u-boot startup without problem ( no change in sp_min_setup.c)

in my DTS I have :

&rtc {

status = "okay";

secure-status = "okay";

};

I guess that disabling stm32_rtc_set_tamper_timestamp() is not great for the platfom security ?

[OlivierK]

Hi AZaki.2 (Community Member)

Thank you for this feedback. This function enable the timestamp bit for tamper and secure timestamp

 access. It does not remove the timestamp protection which status is enabled in tamp node.

I am not sure why removing this function allows you to get you going. The only recommendation I would suggest if platform security is a real concern is to use the FIP/OPTEE from DV4.x on.

[OlivierK]

Hi AZaki.2 (Community Member) 

Are you now sorted out? have you tried the complete BSP (TF-A/Op-tee/U-boot) using OSTL V4.0.1?