Hi,

 

I don’t believe this is the right approach.

 

TF-M currently includes a non-secure side application (integration test) which is built together with the secure side. This is also reflected in “flash_layout.h” and “region_defs.h” which mixes defines for the secure and non-secure side.

 

While this might be convenient within TF-M current build setup for the platforms that are supported, it causes issues in real applications and when trying to make this scalable across a large number of platforms. We have seen those issues already while working on providing TF-M as a CMSIS-Pack.

 

There should be a clean separation of files between the secure and non-secure side.

 

The mentioned header files should not be imposed to the non-secure side.

 

Typically non-secure software will have a device specific linker script which will only need to know limited information from the memory layout (non-secure code and data location). Also the secure side might be prebuilt and the non-secure side developed and built separately.

 

One possible solution is to use a CMSIS-Zone to partition the memory layout on a global level and then splitting it to sub-systems for secure and non-secure and exporting only relevant information for each side. This approach will be used also with TF-M CMSIS-Pack which should be available soon.

 

Best regards,

Robert

 

From: TF-M <tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Devaraj Ranganna via TF-M
Sent: Friday 31 January 2020 17:09
To: TF-M@lists.trustedfirmware.org
Subject: [TF-M] Exporting flash_layout.h and region_defs.h

 

Hi,

 

The headers `flash_layout.h` and `region_defs.h` as the name suggests defines layout of flash and how different regions are organised in flash and ram respectively. These headers define the location of Bootloader if any, secure and non-secure firmware in flash and these defines are used in the linker scripts. As far as I can tell, these headers will be used by NS RTOS without any modifications, I can confirm that, this is the case in Mbed OS.

 

Since these headers are usually imported into NS RTOS without any modifications, I propose that we export these headers as part of the build.

 

Thanks,

Dev

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.