Hi,

sorry, I don't quite understand what you are saying.

Are you saying that it is expected to overlap because too much is being enabled and it doesn't fit?

I have tried adding -DTFM_PROFILE=profile_small and removing -DTEST_S=ON and -DTEST_NS=ON.
But I still get overlapping hex files.

Is there some minimal configuration, that still produces tfm_s.hex, bl2.hex and tfm_ns.hex,
that I could use?

PS: It is strange that the LD script does not enforce that images fit within their allocated partitions.

From: Michel JAOUEN <michel.jaouen@st.com>
Sent: Wednesday, December 22, 2021 2:49 PM
To: Bøe, Sebastian <Sebastian.Boe@nordicsemi.no>
Cc: tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.org>
Subject: [TF-M] nucleo_l552ze_q platform does not build since TF-M 1.5
 

Hello,

This platform is tested for profile medium and low (-DTFM_PROFILE=profile_small or -DTFM_PROFILE=profile_medium). I just checked on master with medium profile and GNUARM.

 

The default config takes a crypto config with its associated crypto tests that leads to overlap in flash area. (This device has 512Kbytes Flash)

 

 

Best Regards

 

 

ST Restricted

From: TF-M <tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Bøe, Sebastian via TF-M
Sent: mercredi 22 décembre 2021 13:40
To: tf-m@lists.trustedfirmware.org
Subject: [TF-M] nucleo_l552ze_q platform does not build since TF-M 1.5

 

Hi,

 

I am observing that the nucleo_l552ze_q platform is producing hex files that overlap

since the 1.5 release. Tested on master and 1.5.

 

Is there an STM maintainer that could look into this?

 

Steps to reproduce:

 

rm -rf cmake_build && cmake -S . -B cmake_build -DTFM_PLATFORM=stm/nucleo_l552ze_q -DTFM_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=MinSizeRel -DTEST_S=ON -DTEST_NS=ON && make -C cmake_build install && /usr/bin/python3.8 /home/sebo/ncs/zephyr/scripts/mergehex.py -o merged.hex $(find cmake_build -name "*.hex")

 

 

"/usr/bin/python3.8 /home/sebo/ncs/zephyr/scripts/mergehex.py" must be replaced

with the preferred hex file merging tool.

 

output:

 

Traceback (most recent call last):

  File "/home/sebo/ncs/zephyr/scripts/mergehex.py", line 28, in merge_hex_files

    ih.merge(to_merge, overlap=overlap)

  File "/home/sebo/.local/lib/python3.8/site-packages/intelhex/__init__.py", line 875, in merge

    raise AddressOverlapError(

intelhex.AddressOverlapError: Data overlapped at address 0xC014400

 

During handling of the above exception, another exception occurred:

 

Traceback (most recent call last):

  File "/home/sebo/ncs/zephyr/scripts/mergehex.py", line 56, in <module>

    main()

  File "/home/sebo/ncs/zephyr/scripts/mergehex.py", line 52, in main

    merge_hex_files(args.output, args.input_files, args.overlap)

  File "/home/sebo/ncs/zephyr/scripts/mergehex.py", line 30, in merge_hex_files

    raise AddressOverlapError("{} has merge issues".format(hex_file_path))

intelhex.AddressOverlapError: cmake_build/install/outputs/STM/NUCLEO_L552ZE_Q/tfm_s.hex has merge issues

 

PS: Depending on the revision tested, it might be necessary to also apply this patch:

 

modified   platform/ext/target/stm/common/stm32l5xx/CMakeLists.txt

@@ -90,7 +90,7 @@ target_sources(platform_s

         ${CMAKE_CURRENT_SOURCE_DIR}/hal/Src/stm32l5xx_hal_gtzc.c

         ${CMAKE_SOURCE_DIR}/platform/ext/common/tfm_hal_isolation_mpu_v8m.c

         ${CMAKE_SOURCE_DIR}/platform/ext/common/tfm_hal_nvic.c

-        $<$<BOOL:${TFM_PARTITION_PLATFORM}>:${CMAKE_CURRENT_SOURCE_DIR}/secure/tfm_platform_system>

+        $<$<BOOL:${TFM_PARTITION_PLATFORM}>:${CMAKE_CURRENT_SOURCE_DIR}/secure/tfm_platform_system.c>

         ${CMAKE_CURRENT_SOURCE_DIR}/hal/Src/stm32l5xx_hal_rng.c

         ${CMAKE_CURRENT_SOURCE_DIR}/hal/Src/stm32l5xx_hal_rng_ex.c

     PUBLIC