Hi Roman,

TF-M NS interface is expected to be built with NS specific configurations, which can be different from S side, for example on PSoC 64.

It requires TF-M build routine to be fully aware of NS dedicated configuration to build NS interface. It brings in much complexities in builds. For example, NS specific configurations shall be added into TF-M config system, which shall be actually transparent to TF-M Secure side.

Besides, the NS side build environment can be different from TF-M CMake-based system.

Imo, it is more flexible to export all the interface files to NS during TF-M build and enable users to build NS interface library as they prefer to.

TF-M is enhancing the build sequence to better split TF-M secure build and NS build. It can help avoid mixing NS/S configurations/arch/cpu in TF-M builds.

Builds on dual-core platforms, such as PSoC 64, can be simplified a lot.

Introduction to the latest build split approach can be found in this tech forum session. Any feedback is welcome!

Best regards,

Hu Ziji

From: Roman.Mazurak--- via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Wednesday, July 12, 2023 4:40 PM
To: Kevin Peng <Kevin.Peng@arm.com>; tf-m@lists.trustedfirmware.org
Subject: [TF-M] Re: Why client API is built with tfm_sprt target?

Hi Kevin,

Thanks for reply!

> Assuming you are referring to the 5 PSA client APIs.

> The APIs implementations are totally different between NS/S sides.

> And even also different within NS/S side.

My bad, I mean client API for ITS, PS and other services…

See interface/CMakeLists.txt#52 – service API are added to tfm_sprt target.

I found answer to my question, I forgot about test repo with NS image. Service API is added by test application app/CMakeLists.txt#92 to tfm_api_ns target. So, my previous question is answered.

The reason I was asking this question is because I would like to add platform specific service client API to be available for secure and non-secure images. tfm_sprt is a good place for secure image. But tfm_api_ns for non-secure image is defined by test application, which means that this target is not a part of TF-M. So, users that are going to use TF-M can create target with different name for this purpose. Probably it make sense to consider to move tfm_api_ns from test project to TF-M project. Any thoughts on this?

Regards, Roman.

From: Kevin Peng <Kevin.Peng@arm.com>
Sent: Wednesday, July 12, 2023 06:04
To: Mazurak Roman (CSUKR CSS ICW SW FW 3) <Roman.Mazurak@infineon.com>; tf-m@lists.trustedfirmware.org
Subject: RE: Why client API is built with tfm_sprt target?

Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe.

Hi Roman,

Assuming you are referring to the 5 PSA client APIs.

The APIs implementations are totally different between NS/S sides.

And even also different within NS/S side.

For example, in the Secure side, depends on the isolation level and IPC/SFN backend, the APIs have 3 different implementations (SFN call, cross call and SVC call).

For NS side, if the platform’s using TrustZone, then the APIs go through the veneer sections.

And if it’s a multi-core platform, the APIs might go through the mailbox interfaces.

I don’t think they can be shared as a static library.

Even the code is the same between NS and S, it is still better to compile them separately as there could be compilation setting differences between NS and S.

Sometimes, NS and S even have different architectures which makes the compilation settings totally different.

-Kevin

From: Roman.Mazurak--- via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Tuesday, July 11, 2023 11:26 PM
To: tf-m@lists.trustedfirmware.org
Subject: [TF-M] Why client API is built with tfm_sprt target?

Hi all,

I’m wondering why client API is build with tfm_sprt target (Secure Partition Runtime Library)? Client API is used by non-secure clients and secure clients. It means that static library is built once, but used with two different images. And it’s expected that such images can use different types of cores, compilation settings, etc…

Probably it make sense to build this target in scope of psa_interface.

Regards,

Roman.