Hi Anton,

> I am not sure if TF-M requires add/remove files

Not physically, but in scope of a project. This is the fact from very beginning.

> With this occasion let me remind that TF-M is an open source project where design proposal or code change are welcome from everyone.

Yes, but it should be approved and pushed by leaders, otherwise it will not work, and the main leading force of PSA projects is ARM. After that, the approach should be followed by every committer.

Thank you,

Andrej

From: Anton Komlev <Anton.Komlev@arm.com>
Sent: Tuesday, March 3, 2020 3:24 PM
To: Andrej Butok <andrey.butok@nxp.com>
Cc: nd <nd@arm.com>
Subject: RE: Call for a feedback on TF-M adaptation experience

Hi Andrej,

Thank you for your feedback!

I am not sure if TF-M requires add/remove files for config change but have to agree that build system requires review and refactoring to be less restrictive and easy for integration.

This is a valuable input for us for improvement planning and task prioritizing.

With this occasion let me remind that TF-M is an open source project where design proposal or code change are welcome from everyone.

Thanks again,

Anton

From: Andrej Butok <andrey.butok@nxp.com>
Sent: 03 March 2020 13:31
To: Anton Komlev <Anton.Komlev@arm.com>
Cc: nd <nd@arm.com>
Subject: RE: Call for a feedback on TF-M adaptation experience

Hi Anton,

The biggest inconvenience for us is the way which TFM is using CMAKE.

The configuration is done on level of CMAKE - adding/deleting/renaming files based on project-level configuration.

So it is difficult to use the original TFM as a component, required for SDKs and CMSIS packs.

For every combination of parameters is needed to create a separate project. As it is not possible, we have to choose one typical configuration.

For example, if a user need to change from Isolation2&IPC to Isolation1&Lib, it is not enough to change configuration parameters, he/she must manually to add/delete source files in the project.

The improvement request:

- platform-independent TFM source-code file set must be fixed for any TFM project.

- optional functionality must be covered by #ifdef – NOT by adding/deleting files.

- allow to change configuration parameters using a user-config file (e.g. as it’s done for mbedTLS/Cypto).

All these has no conflict with CMAKE and brings no limits to TFM.

Please, do not ignore it.

Thank you,

Andrej Butok

From: TF-M <tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M
Sent: Friday, February 7, 2020 2:13 PM
To: tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: [TF-M] Call for a feedback on TF-M adaptation experience

Dear All,

As I mentioned on yesterday’s call, there is a concern on user experience related to TF-M use.

To In order to understand and potentially improve it I am looking for a voice of partners who adopted TF-M project.

Please share your experience and thoughts on parts which are good or might be done better to simplify TF-M integration with your project.

You feedback will be very appreciated in any form – as a response to this mail or as a direct mail to me (anton.komlev@arm.com) if it’s more comfortable for you.

Thank you in advance,

Anton