It looks like we all agree to header-file-style configuration, with some questions about the implementation.

 

Kconfig provides an easy-to-use configuration GUI for make-based build system. I’m not sure if it is worth setting up another complex configuration system, besides existing CMake one, just to generate C header file.

I once created a Kconfig PoC for TF-M build system. It was a challenge to develop and maintain it, to resolve the dependencies here and there. It also required special workaround (cost) to integrate Kconfig and CMake together.

 

IMHO, a lightweight implementation to generate/parse the C header file(s) for configuration can be more flexible.

 

Best regards,

Hu Ziji

 

From: Ken Liu via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Wednesday, August 10, 2022 2:03 PM
To: tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: [TF-M] Re: What do you think using configuration headers in TF-M ?

 

For the first bullet:

 

- Configuration header files are a must, it is a common result for various project systems.

- Configuration switch is a project-system-specific item. Currently, we can provide a CMAKE config list for other CMAKE-based projects' convenience. For project systems other than CMAKE, we may need to use CMAKE export functionality or ask the user to add exporting support to export the CMAKE configurations into their project system file. At the current stage, start with CMAKE is a good choice.

 

/Ken

 

From: Kevin Peng via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Wednesday, August 10, 2022 11:20 AM
To: Andersson, Joakim <Joakim.Andersson@nordicsemi.no>; Andrej Butok <andrey.butok@nxp.com>; Anton Komlev <Anton.Komlev@arm.com>
Cc: tf-m@lists.trustedfirmware.org
Subject: [TF-M] Re: What do you think using configuration headers in TF-M ?

 

I think we have two topics here:

 

By “configuration” I’m referring to the process of users selecting certain build configurations such as the isolation level and what Secure Partitions to build.

 

For the results of configurations, seems configuration header file is the preferred one.

On the configuration part (producing the result), there might be multiple options, for example sticking to CMake or introducing another tool.

 

Best Regards,

Kevin

 

From: Andersson, Joakim via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Tuesday, August 9, 2022 11:04 PM
To: Andrej Butok <andrey.butok@nxp.com>; Anton Komlev <Anton.Komlev@arm.com>
Cc: tf-m@lists.trustedfirmware.org
Subject: [TF-M] Re: What do you think using configuration headers in TF-M ?

 

Hi. Anton.

How would this header file be supplied to the TF-M build system?
If we are talking about simply providing a single header file to the build system and leaving the generation of this header file up to the application user I don’t think this is an improvement upon Cmake cache variables.

Someone did already bring up using Kconfig in an earlier TF-M tech forum conversation.
I think introducing Kconfig as the configuration system into TF-M would be a better approach, and this is something we already have experience with in working with the zephyr project.

The Kconfig system in the end generates a header file, in zephyr we alse have support for getting the configuration macros as CMake variables for build control.

If this is of interest to the TF-M community I would be happy to contribute to a prototype and possible implementation of this solution.

 

-Joakim

 

From: Andrej Butok via TF-M <tf-m@lists.trustedfirmware.org>
Sent: tirsdag 9. august 2022 15:32
To: Anton Komlev <Anton.Komlev@arm.com>
Cc: tf-m@lists.trustedfirmware.org
Subject: [TF-M] Re: What do you think using configuration headers in TF-M ?

 

Hi Anton,

 

The proposal to “Configure TF-M via definitions in header files while leave CMake for a building control only” is highly wanted from very beginning, it can save a lot of time for us.

 

Thank you,

Andrej Butok

 

From: Anton Komlev via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Tuesday, August 9, 2022 3:22 PM
To: tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: [TF-M] What do you think using configuration headers in TF-M ?

 

Hello,

 

TF-M has many options to configure. All of them are declared as a CMake variables and many of them translated to compiler definitions later.

Since the idea of TF-M configuration via config header file(s) was warmly received on the last tech forum I would like to check with community opinion on such hypothetical move: Configure TF-M via definitions in header files while leave CMake for a building control only.

 

Please share your thoughts, opinions and the possible dependencies.

 

Thanks,

Anton