I'm following the first build example in docs\getting_started\tfm_build_instruction.rst, for the mps2/an521.
cmake -S . -B cmake_build -DTFM_PLATFORM=mps2/an521 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake
Building on Windows with gnu, it progresses pretty far then stops with the error shown below.
Any suggestions?
Kevin
-- Configuring done
CMake Error at toolchain_GNUARM.cmake:114 (add_library):
No SOURCES given to target: tfm_s_scatter
Call Stack (most recent call first):
platform/ext/target/mps2/an521/CMakeLists.txt:27 (target_add_scatter_file)
CMake Error at toolchain_GNUARM.cmake:114 (add_library):
No SOURCES given to target: tfm_ns_scatter
Call Stack (most recent call first):
platform/ext/target/mps2/an521/CMakeLists.txt:40 (target_add_scatter_file)
CMake Error at toolchain_GNUARM.cmake:114 (add_library):
No SOURCES given to target: bl2_scatter
Call Stack (most recent call first):
platform/ext/target/mps2/an521/CMakeLists.txt:63 (target_add_scatter_file)
CMake Generate step failed. Build files cannot be regenerated correctly.
Hi,
With the new build system, TF-M downloads all dependant repositories to the BUILD folder as part of CMAKE configuration. CMake does provide `make clean` target to clean the build and rebuild but this doesn't track any config changes between the builds. Previously, the CMake workflow was to delete all contents in the BUILD folder before re-configuring for a new build but now this means the developer has to re-download all the dependant git repositories before the project can be build again. This can be a slow and cumbersome process for developers. Deleting the CMakecache.txt doesn't seem to solve the problem either.
The most obvious solution is to move the cloned repositories outside the BUILD/ folder , so we can follow the previous workflow of deleting the BUILD folder before re-build. The sample test sequence to reproduce the problem is given below:
/* Build secure regressions test suite */
$ make clean; cmake .. -DTFM_PLATFORM=mps2/an521 -DCMAKE_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake -DTEST_S=ON -DCMAKE_BUILD_TYPE=Debug; make install
/* reconfigure and build PSA Crypto API test suite */
$ make clean; cmake .. -DTFM_PLATFORM=mps2/an521 -DCMAKE_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Debug -DTEST_PSA_API=CRYPTO; make install
Built binary is still for regression test suite.
There are multiple suggestions to solve the problem, One is to move the clone repositories outside the BUILD/ folder, or introduce a build target like `make cleanall` which does the equivalent of rm -rf !(lib) within the BUILD folder (i.e the build target will remove all folders except the lib folder which has the cloned repositories). Please let us know of your suggestions on this.
Best Regards
Soby Mathew
Hi All,
The agenda for the forum today:
1. New build system features, tricks and known issues.
See you,
Anton
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M
Sent: 28 September 2020 11:39
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] TF-M Technical Forum call – October 1
Hello,
The next Technical Forum is planned on Thursday, October 1 at 15:00-16:00 UTC (US time zone).
Please reply on this email with your proposals for agenda topics.
Recording and slides of previous meetings are here:
https://www.trustedfirmware.org/meetings/tf-m-technical-forum/
Best regards,
Anton
Yes, it seems like the core tests slipped through conversion. I've already had a report of this and got a patch together but it needs some thorough testing since it affects the linking order.
I'll notify here once the patch is submitted for review. Should be this morning.
Raef
________________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Christopher Brand via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: 30 September 2020 23:45
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] CORE_TEST and the new build system
It seems that docs/reference/services/core_test_services_integration_guide.rst hasn’t been updated to reflect the new build system (it says to build using ConfigCoreTest.cmake). That config isn’t mentioned in docs/getting_started/tfm_build_instruction.rst.
So how do I build the CORE_TEST stuff with the new build system (I’m particularly interested in the IRQ test).
Thanks,
Chris Brand
Sr Prin Software Engr, MCD: WIRELESS
Cypress Semiconductor Corp.
An Infineon Technologies Company
#320-13700 International Place, Richmond, British Columbia V6V 2X8 Canada
www.infineon.com<http://www.infineon.com> www.cypress.com<http://www.cypress.com>
This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.
Hi Raymond,
Thanks for reporting the issue!
The observed behaviour has two reason:
- In the new build system the default CMAKE_BUILD_TYPE=Release. In this case the logging is disabled in MCUboot to get smaller binary. You can set manualy to Debug in the command line to enable logging from bootloader
* This commit 7d591a684b4abb0f61fbba8668dd6ea7b4b68698 introduced a crash in Musca S1/B1. Fix is ongoing.
Tamas
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Raymond Ngun via TF-M
Sent: 30 September 2020 17:44
To: David Hu via TF-M <tf-m(a)lists.trustedfirmware.org>
Subject: [TF-M] Musca-B1 and new build system
Hi all,
I am attempting to build Musca-B1 with the latest in master but I'm not able to get it to run (nothing shows on the UART). At a minimum, the User Guide is out of date in terms of how the final hex is created. So, I have a couple questions.
1. Is the latest tested with Musca-B1?
2. Can I obtain some updated information on how to build and create an image for Musca-B1?
Thank you,
Ray
This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.
It seems that docs/reference/services/core_test_services_integration_guide.rst hasn't been updated to reflect the new build system (it says to build using ConfigCoreTest.cmake). That config isn't mentioned in docs/getting_started/tfm_build_instruction.rst.
So how do I build the CORE_TEST stuff with the new build system (I'm particularly interested in the IRQ test).
Thanks,
Chris Brand
Sr Prin Software Engr, MCD: WIRELESS
Cypress Semiconductor Corp.
An Infineon Technologies Company
#320-13700 International Place, Richmond, British Columbia V6V 2X8 Canada
www.infineon.com<http://www.infineon.com> www.cypress.com<http://www.cypress.com>
This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.
Hi all,
I am attempting to build Musca-B1 with the latest in master but I'm not able to get it to run (nothing shows on the UART). At a minimum, the User Guide is out of date in terms of how the final hex is created. So, I have a couple questions.
1. Is the latest tested with Musca-B1?
2. Can I obtain some updated information on how to build and create an image for Musca-B1?
Thank you,
Ray
This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.
This is excellent work and great news for both projects. Well done.
Best,
Adrian
________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Tamas Ban via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: 30 September 2020 11:13
To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com>
Subject: [TF-M] Removal of MCUboot fork from TF-M
Hi,
In the last few quarter TF-M team have worked on actively to upstream the TF-M related features from the forked MCUboot repo to the original repository.
This activity has been finished recently and as a result the MCUboot fork has been removed from TF-M repo.
Currently TF-M exclusively relies on MCUboot project as a secure bootloader. From now on all new development will be directly contributed to the upstream repo.
List of feature which were upstreamed:
* HW rollback protection
* HW key integration
* Data exchange between MCUboot and runtime firmware
* RAM_LOAD boot mode
* DIRECT_XIP boot mode
BR,
Tamas Ban
Hi,
In the last few quarter TF-M team have worked on actively to upstream the TF-M related features from the forked MCUboot repo to the original repository.
This activity has been finished recently and as a result the MCUboot fork has been removed from TF-M repo.
Currently TF-M exclusively relies on MCUboot project as a secure bootloader. From now on all new development will be directly contributed to the upstream repo.
List of feature which were upstreamed:
* HW rollback protection
* HW key integration
* Data exchange between MCUboot and runtime firmware
* RAM_LOAD boot mode
* DIRECT_XIP boot mode
BR,
Tamas Ban
Hello Jaouen,
I have a development issue when running TFM download process on the STM32L562.Print a error log"[ERR] Image in the secondary slot is not valid!" when download tfm_s_enc_sign.bin.ALL other 3 bin（tfm_s_sign.bin，tfm_ns_sign.bin，tfm_ns_enc_sign.bin） download success.
I follow the document UM2671 chapter 11.4 Download a new firmware image.
The project is en.stm32cubel5_v1-3-0.zip，file：Projects\STM32L562E-DK\Applications\TFM
Steps to reproduce:
1.run Projects\STM32L562E-DK\Applications\TFM\TFM_SBSFU_Boot\MDK-ARM\regression.bat to init device
2.build TFM_SBSFU_Boot application，TFM_Appli secure application，TFM_Appli non-secure application，Build TFM_Loader application
3.run Projects\STM32L562E-DK\Applications\TFM\TFM_SBSFU_Boot\MDK-ARM\TFM_UPDATE.bat to programing into STM32L5 internal and external Flash memory
4.success to run into app
5.press user button (blue) during board reset, the user enters local loader menu.
6.use ymodem to download tfm_s_enc_sign.bin to secure image
7.reset and then print error log "[ERR] Image in the secondary slot is not valid!"
Reason：
1.hash verify not pass because after decrypt， the image not same with origin image.log as below：
=====================================================
[INF] verify counter 0 1000000 1000000
[INF] counter 0 : ok
[INF] hash256 : 54, cc, 2c, 4c, 97, b5, 55, 68,
[INF] hash256 buf : cd, 76, a3, a1, cb, 1, 4d, bc,
[ERR] Image in the secondary slot is not valid!
======================================================
Does anyone know what I39m doing wrong?
Thanks in advance!
