Hi,

Just some minor additions. In the TF-M build system Kconfig will most likely generate input for cmake scripts, so the compiler may not have a connection to it.

The original intention with DT is capturing configuration data to allow hardware independent binaries (for defining base address of peripherals, boot information, etc..), and is mostly parsed runtime. In the Cortex-M space this might be a bit out-of scope. Most likely it will be used as a “standard” language to define “retargeting” information, and a tool will be developed which runs compile time and which allows access to the retargeting data for cmake. Something like CMSIS zone, but closer to established open-source technologies.

In multicore systems having bot Cortex-A and M core DT would allow having a consistent solution for both A and M firmware. This is also a reason why cmake is a better build solution for TF-M than CMSIS Build.

/George

From: TF-M <tf-m-bounces@lists.trustedfirmware.org> On Behalf Of David Hu via TF-M
Sent: 12 June 2020 11:16
To: Thomas Törnblom <thomas.tornblom@iar.com>; tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: Re: [TF-M] CMake flags

Hi Thomas,

DT is another very attractive topic. TF-M currently doesn’t include any DT support.

So maybe there is mixed preprocessing of DT and Kconfig in Zephyr, but Kconfig can be parsed without any compiler.

Best regards,

Hu Ziji

From: Thomas Törnblom <thomas.tornblom@iar.com>
Sent: Friday, June 12, 2020 5:09 PM
To: David Hu <David.Hu@arm.com>; tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: Re: [TF-M] CMake flags

Perhaps I'm mixing dts and Kconfig up.

In Zephyr, dtc is used to generate output that is run through the gcc preprocessor in assembly mode.

The output from dtc looks like:
---
/dts-v1/;

/ {
ï¿½ï¿½ï¿½ #address-cells = < 0x1 >;
ï¿½ï¿½ï¿½ #size-cells = < 0x1 >;
ï¿½ï¿½ï¿½ model = "STMicroelectronics STM32F746G DISCOVERY board";
ï¿½ï¿½ï¿½ compatible = "st,stm32f746g-disco", "st,stm32f746";
ï¿½ï¿½ï¿½ chosen {
ï¿½ï¿½ï¿½ ï¿½ï¿½ï¿½ zephyr,console = &usart1;
ï¿½ï¿½ï¿½ ï¿½ï¿½ï¿½ zephyr,shell-uart = &usart1;
ï¿½ï¿½ï¿½ ï¿½ï¿½ï¿½ zephyr,sram = &sram0;
ï¿½ï¿½ï¿½ ï¿½ï¿½ï¿½ zephyr,flash = &flash0;
ï¿½ï¿½ï¿½ ï¿½ï¿½ï¿½ zephyr,dtcm = &dtcm;
ï¿½ï¿½ï¿½ };
...
---

Our preprocessor can not be run in assembler mode and it pukes on the "#address-cells" type elements in the file.

If this is not what Kconfig is about, then please ignore my comments.

Thomas

Den 2020-06-12 kl. 09:43, skrev David Hu:

Hi Thomas,

ï¿½

Iï¿½ve not met such a problem yet. Could you please give more details about the portability issues in Kconfig?

In our PoC, it firstly parses the Kconfig files and then convert the output Kconfig options into CMake flags. Thus the whole process is not related to any compiler.

I checked Zephyr previously. It looks like Zephyr has the similar idea as our PoC does.

ï¿½

Best regards,

Hu Ziji

ï¿½

From: TF-M <tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Thomas Tï¿½rnblom via TF-M
Sent: Friday, June 12, 2020 3:36 PM
To: tf-m@lists.trustedfirmware.org
Subject: Re: [TF-M] CMake flags

ï¿½

Introducing a dependency on Kconfig may cause portability issues with some toolchains (IAR for instance)

I am working on adding support for the IAR toolchain to Zephyr, and Kconfig is one of the issues I've run into.

At least in Zephyr, the output from Kconfig is run through the C preprocessor and this causes issues with the IAR preprocessor so for now I use gcc for this step.

Thomas

Den 2020-06-12 kl. 07:32, skrev David Hu via TF-M:

Hi Adrian,

ï¿½

Actually we have been investigating configuration alternatives and making some prototypes of Kconfig.

ï¿½

Kconfig can bring some advantages:

It can setup configuration and check dependency before CMake starts and therefore it can help CMake simplify dealing with the mutual dependencies. For example, if CPU and arch options can be configured in Kconfig, CMake can avoid the workaround to re-configure compiler after parsing platform files.
Kconfig can collect together the options which are distributed in various CMake files. Developers can more easily understand the options and their dependencies, compared with searching them all around the build system.

ï¿½

But Kconfig may not cover all the flags in command line. Flags such as compiler selections, build type and project config file, may vary in each build. It can be inconvenient to put them into Kconfig.

ï¿½

Best regards,

Hu Ziji

ï¿½

From: TF-M <tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Adrian Shaw via TF-M
Sent: Friday, June 12, 2020 12:24 AM
To: Raef Coles <Raef.Coles@arm.com>
Cc: tf-m@lists.trustedfirmware.org
Subject: [TF-M] CMake flags

ï¿½

Hi Raef. Thanks for the presentation today.

ï¿½

If I remember correctly, TF-M's CMake has quite a lot of command line flags now (the ones that are set with -D). And I think this will grow in the future as more options are needed.

ï¿½

From a command line point of view, this is kind of annoying because the commands end up being quite long. Do you guys think something like Kconfig could help?

ï¿½

Adrian

ï¿½

ï¿½

--

Thomas Tï¿½rnblom, Product Engineer
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom@iar.com Website: www.iar.com
Twitter: www.twitter.com/iarsystems

--

Thomas Tï¿½rnblom, Product Engineer
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom@iar.com Website: www.iar.com
Twitter: www.twitter.com/iarsystems