Hello,
After upgrade to the latest version of TFM, the Attestation test from the PSA Test Suite is failed (but the TFM Attestation regression tests are passed).
What combination of configuration parameters must be used (INCLUDE_OPTIONAL_CLAIMS, INCLUDE_TEST_CODE, INCLUDE_COSE_KEY_ID, BOOT_DATA_AVAILABLE) to follow PSA Test Suite expectations?
What commit of the PSA Test-suite must be used for the latest TFM? We are still on the 2019-07-25 (c80681ed7c7f3e2cbf02ded1ef2464ba2ca7ccd5) commit, which was OK with 2-month old TFM.
Is the PSA Test Suite Attestation test valid for the latest TFM?
Thank you,
Andrej Butok
Hi,
Currently the test framework which executes test suites doesn't return anything. Therefore it is not possible for application layer to know the status of test cases. The patchset https://review.trustedfirmware.org/c/trusted-firmware-m/+/3172 is intended to export the test case pass/fail status to application layer and beyond (if any test framework is used by Non-secure side).
If there are no objections then can the patchset be merged?
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.
Hi,
Can we agree on exporting both `flash_layout.h and region_defs.h` till a decision is made on tooling to be used/developed for device config and export in TF-M?
Exporting these files doesn’t mean that NS RTOS is obligated to use these rather just a choice. If NS RTOS decides to write/generate their own then these files will just be in the TF-M export folder.
Thanks,
Dev
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Anton Komlev via TF-M <TF-M(a)lists.trustedfirmware.org>
Reply to: Anton Komlev <Anton.Komlev(a)arm.com>
Date: Monday, 3 February 2020 at 17:00
To: "TF-M(a)lists.trustedfirmware.org" <TF-M(a)lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Exporting flash_layout.h and region_defs.h
Hi Robert,
I see two topics mixing together in this discussion:
1. Project configuration methods/strategy
2. Tooling for that
The CMSIS-Zone addresses both of the items somehow. Believe it would be beneficial if you could summaries the thoughts and bring this important topic for discussion on the upcoming Open Technical forum on Feb 6. This would be a good opportunity to present CMSIS-Zone and get a feedback from the community.
The best,
Anton
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Gyorgy Szing via TF-M
Sent: 03 February 2020 09:50
To: Robert Rostohar <Robert.Rostohar(a)arm.com>; tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Exporting flash_layout.h and region_defs.h
Hi Robert,
“It is a standalone utility that can be used also from command-line. “
The homepage says this is the command to run it “headless”:
eclipsec.exe -noSplash -consoleLog –launcher.suppressErrors -application com.arm.cmsis.zone.ui.headlessgen -azone FILENME.azone -ftl FTL_DIR -ftl_gen FTL_GEN_DIR
For me this means you still need Eclipse to be installed on your PC to run it and thus this is still and IDE extension just it has support being run headless.
There might be ways to run it without Eclipse, but this does not seem to be officially supported. This means there is expected to be sparse information on how-to-do this, no, or limited support. There is a risk in using this tool to generate extra work (need to work out what environment it needs, need to document it, need to test it to ensure proper operation, need to support issues with the environment, etc…).
This is not really helping us for now, hopefully this changes in the future.
/George
From: Robert Rostohar <Robert.Rostohar(a)arm.com<mailto:Robert.Rostohar@arm.com>>
Sent: 03 February 2020 09:27
To: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: RE: Exporting flash_layout.h and region_defs.h
Hi Gyorgy,
Yes, the memory map needs to be communicated to non-secure world and the existing headers are not the best way.
CMSIS-Zone is one possible tool that could help here and make it user friendly. It provides memory partitioning and also assignment of peripherals to secure or non-secure world.
It is a standalone utility that can be used also from command-line.
Best regards,
Robert
From: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>>
Sent: Monday 3 February 2020 09:05
To: Robert Rostohar <Robert.Rostohar(a)arm.com<mailto:Robert.Rostohar@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: RE: Exporting flash_layout.h and region_defs.h
Hi,
Looking at the big picture, the secure side is owning the memory map, so it seems to be inevitable to communicate this information to the non-secure world. There are many ways to do this, ranging from capturing the info in documentation to providing configuration to high-level memory layout definition tools. The build system could support multiple options, but the first implementation shall focus on portability.
Having a set of header files, which (as the tf-m build system already shows) make the needed information available for both the C program, the linker and the build system, seems to be a good fit to me. It might not be the most user friendly, but is highly accessible.
What those header files actually do contain is a different question. Sor security reasons it may be a good idea to remove all information not needed by the NS world. Luckily CMake has the needed features to solve this issue.
And when we are at the topic, we need to provide a solution for defining available peripherals to as the secure vs non-secure peripheral availability is also controlled by the secure-side.
There seems to be room for a tool independent of tf-m to help standardizing the format this information can be captured in, to help portability of this information and to enhance user-experience. Unfortunately CMSIS-Zone (as per this page https://arm-software.github.io/CMSIS_5/Zone/html/zTInstall.html ) is an IDE extension and thus it is hardly applicable in a command-line focused build environment.
/George
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Robert Rostohar via TF-M
Sent: 03 February 2020 08:15
To: TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org>
Subject: Re: [TF-M] Exporting flash_layout.h and region_defs.h
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(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Devaraj Ranganna via TF-M
Sent: Friday 31 January 2020 17:09
To: TF-M(a)lists.trustedfirmware.org<mailto: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.
Hi Tamas,
The failed tests are:
---
DoubleAsSmallestTest
FAILED (returned
-3
)
HalfPrecisionAgainstRFCCodeTest
FAILED (returned
-3
)
---
Cheers,
Thomas
Den 2020-02-04 kl. 14:49, skrev Tamas Ban via TF-M:
>
> Hi Thomas,
>
> An extra logging can be enabled for QCBOR test cases:
> https://git.trustedfirmware.org/trusted-firmware-m.git/tree/test/suites/qcb…
>
> Could you repeat the test with enabled logs, just to know exactly
> which test cases are failing?
>
> The QCBOR library is used for attest token creation, but only a small
> part of the library which is actually used. The IEEE 754 part of QCBOR
> is unused in TF-M. So it is not affecting TF-M code, we can
> temporarily disable those test cases. It is not a blocking issue for
> IAR support.
>
> I put Laurence on cc he is the maintainer of QCBOR library, I think he
> will be interested in the issue.
>
> Tamas
>
> *From:*TF-M <tf-m-bounces(a)lists.trustedfirmware.org> *On Behalf Of
> *Thomas Törnblom via TF-M
> *Sent:* 04 February 2020 14:01
> *To:* tf-m(a)lists.trustedfirmware.org
> *Subject:* [TF-M] QCBOR, IEEE-754, RFC 7049 and Arm Run-time ABI issues
>
> The IAR port of TF-M is mostly done and all regression tests runs OK,
> with the exception of some of the QCBOR tests.
>
> I've analyzed the issue to be the NaN tests to not follow the Arm
> run-time ABI.
>
> The issue is with doubles where some of the tested NaN:s only have set
> bits in the lower 32 bits of the mantissa.
>
> From
> https://developer.arm.com/docs/ihi0043/e/run-time-abi-for-the-arm-architect…
> ---
>
> If NaNs are supported, it is only required to recognize, process, and
> convert those values with at least one bit set in the 20 most
> significant bits of the mantissa. Remaining bits should be zero and
> can be ignored. When a quiet NaN of one precision is converted to a
> quiet of the other precision, the most significant 20 bits of the
> mantissa must be preserved. Consequently:
>
> * A NaN can be recognized by processing the most significant or only
> word of the representation. The least significant word of a double
> can be ignored (it should be zero).
> * Each ABI-complying value has a single-precision representation,
> and a corresponding double-precision representation in which the
> least significant word is zero.
> * Each ABI-complying NaN value is converted between single- and
> double-precision in the same way that Arm VFP VCVT instructions
> convert the values.
>
> ---
>
> The IAR toolchain only checks the upper 32 bits for NaN / INF and the
> double precision NaN tests misinterprets some of the hand crafted
> NaN:s as INF.
>
> How should TF-M handle this?
>
> Thomas
>
> --
>
> *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(a)iar.com
> <mailto:thomas.tornblom@iar.com>Website: www.iar.com <http://www.iar.com>
> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>
>
> 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.
>
--
*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(a)iar.com <mailto:thomas.tornblom@iar.com>
Website: www.iar.com <http://www.iar.com>
Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>
Hi Thomas,
An extra logging can be enabled for QCBOR test cases:
https://git.trustedfirmware.org/trusted-firmware-m.git/tree/test/suites/qcb…
Could you repeat the test with enabled logs, just to know exactly which test cases are failing?
The QCBOR library is used for attest token creation, but only a small part of the library which is actually used. The IEEE 754 part of QCBOR is unused in TF-M. So it is not affecting TF-M code, we can temporarily disable those test cases. It is not a blocking issue for IAR support.
I put Laurence on cc he is the maintainer of QCBOR library, I think he will be interested in the issue.
Tamas
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M
Sent: 04 February 2020 14:01
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] QCBOR, IEEE-754, RFC 7049 and Arm Run-time ABI issues
The IAR port of TF-M is mostly done and all regression tests runs OK, with the exception of some of the QCBOR tests.
I've analyzed the issue to be the NaN tests to not follow the Arm run-time ABI.
The issue is with doubles where some of the tested NaN:s only have set bits in the lower 32 bits of the mantissa.
>From https://developer.arm.com/docs/ihi0043/e/run-time-abi-for-the-arm-architect…
---
If NaNs are supported, it is only required to recognize, process, and convert those values with at least one bit set in the 20 most significant bits of the mantissa. Remaining bits should be zero and can be ignored. When a quiet NaN of one precision is converted to a quiet of the other precision, the most significant 20 bits of the mantissa must be preserved. Consequently:
* A NaN can be recognized by processing the most significant or only word of the representation. The least significant word of a double can be ignored (it should be zero).
* Each ABI-complying value has a single-precision representation, and a corresponding double-precision representation in which the least significant word is zero.
* Each ABI-complying NaN value is converted between single- and double-precision in the same way that Arm VFP VCVT instructions convert the values.
---
The IAR toolchain only checks the upper 32 bits for NaN / INF and the double precision NaN tests misinterprets some of the hand crafted NaN:s as INF.
How should TF-M handle this?
Thomas
--
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(a)iar.com<mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com>
Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems>
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.
Hi all,
I have pushed for review patches to enable persistent keys in the TF-M Crypto service. With these changes, persistent keys will be stored by Mbed Crypto using the ITS APIs exposed by TF-M.
The reviews are here:
https://review.trustedfirmware.org/c/trusted-firmware-m/+/3252 (implementation)
https://review.trustedfirmware.org/c/trusted-firmware-m/+/3253 (tests)
Currently, merging of these patches is blocked as they depend on Mbed Crypto 2.0 (or greater), which adds support for the latest ITS 1.0.0 APIs exposed by TF-M. Integrating Mbed Crypto 2.0 with TF-M is a work in progress.
If anyone wants to test these patches in the meantime, it is possible to cherry pick the patch in the Mbed Crypto repo that adds support for ITS 1.0.0. With the Mbed Crypto repo checked-out at the "mbedcrypto-1.1.0" tag, do a "git cherry-pick bda5a2111" to cherry pick the relevant patch.
Kind regards,
Jamie
Hi,
TF-M Profile 1 initiative addressing TF-M footprint reduction to make TF-M usable on more constrained MCUs. As part of this activity attestation service is planned to be refactored as follows:
* Static token creation: Not use QCBOR and T_COSE libraries to token creation
* HMAC based token authentication: Rely only on symmetric crypto algorithms
These changes are optional, the current functionality (dynamic token creation + ECDSA based authentication) remains available and default setting in higher profiles (3).
A design proposal was created, feel free to review & comment:
https://review.trustedfirmware.org/c/trusted-firmware-m/+/3344
BR,
Tamas
The IAR port of TF-M is mostly done and all regression tests runs OK,
with the exception of some of the QCBOR tests.
I've analyzed the issue to be the NaN tests to not follow the Arm
run-time ABI.
The issue is with doubles where some of the tested NaN:s only have set
bits in the lower 32 bits of the mantissa.
>From
https://developer.arm.com/docs/ihi0043/e/run-time-abi-for-the-arm-architect…
---
If NaNs are supported, it is only required to recognize, process, and
convert those values with at least one bit set in the 20 most
significant bits of the mantissa. Remaining bits should be zero and can
be ignored. When a quiet NaN of one precision is converted to a quiet of
the other precision, the most significant 20 bits of the mantissa must
be preserved. Consequently:
* A NaN can be recognized by processing the most significant or only
word of the representation. The least significant word of a double
can be ignored (it should be zero).
* Each ABI-complying value has a single-precision representation, and
a corresponding double-precision representation in which the least
significant word is zero.
* Each ABI-complying NaN value is converted between single- and
double-precision in the same way that Arm VFP VCVT instructions
convert the values.
---
The IAR toolchain only checks the upper 32 bits for NaN / INF and the
double precision NaN tests misinterprets some of the hand crafted NaN:s
as INF.
How should TF-M handle this?
Thomas
--
*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(a)iar.com <mailto:thomas.tornblom@iar.com>
Website: www.iar.com <http://www.iar.com>
Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>
In CMSIS we are using a Test Framework that offers the flexibility to:
1. output to classic printf, but redirecting is on just a single place.
2. Record test output to memory (for devices that have not printf facility)
3. Output the test results in XML for nice formatting using browsers (we use this for filing test reports).
We have used this framework on various projects, across 4 different compilers, on many different targets (simulation, FPGA without UART, etc.).
The framework is for example here https://github.com/ARM-software/CMSIS-Driver_Validation/tree/master/Source. But we used it also for various other projects.
If there is interest, we could do some work to explain it better and make it scalable to TF-M.
Hi Robert,
I see two topics mixing together in this discussion:
1. Project configuration methods/strategy
2. Tooling for that
The CMSIS-Zone addresses both of the items somehow. Believe it would be beneficial if you could summaries the thoughts and bring this important topic for discussion on the upcoming Open Technical forum on Feb 6. This would be a good opportunity to present CMSIS-Zone and get a feedback from the community.
The best,
Anton
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Gyorgy Szing via TF-M
Sent: 03 February 2020 09:50
To: Robert Rostohar <Robert.Rostohar(a)arm.com>; tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Exporting flash_layout.h and region_defs.h
Hi Robert,
“It is a standalone utility that can be used also from command-line. “
The homepage says this is the command to run it “headless”:
eclipsec.exe -noSplash -consoleLog –launcher.suppressErrors -application com.arm.cmsis.zone.ui.headlessgen -azone FILENME.azone -ftl FTL_DIR -ftl_gen FTL_GEN_DIR
For me this means you still need Eclipse to be installed on your PC to run it and thus this is still and IDE extension just it has support being run headless.
There might be ways to run it without Eclipse, but this does not seem to be officially supported. This means there is expected to be sparse information on how-to-do this, no, or limited support. There is a risk in using this tool to generate extra work (need to work out what environment it needs, need to document it, need to test it to ensure proper operation, need to support issues with the environment, etc…).
This is not really helping us for now, hopefully this changes in the future.
/George
From: Robert Rostohar <Robert.Rostohar(a)arm.com<mailto:Robert.Rostohar@arm.com>>
Sent: 03 February 2020 09:27
To: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: RE: Exporting flash_layout.h and region_defs.h
Hi Gyorgy,
Yes, the memory map needs to be communicated to non-secure world and the existing headers are not the best way.
CMSIS-Zone is one possible tool that could help here and make it user friendly. It provides memory partitioning and also assignment of peripherals to secure or non-secure world.
It is a standalone utility that can be used also from command-line.
Best regards,
Robert
From: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>>
Sent: Monday 3 February 2020 09:05
To: Robert Rostohar <Robert.Rostohar(a)arm.com<mailto:Robert.Rostohar@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: RE: Exporting flash_layout.h and region_defs.h
Hi,
Looking at the big picture, the secure side is owning the memory map, so it seems to be inevitable to communicate this information to the non-secure world. There are many ways to do this, ranging from capturing the info in documentation to providing configuration to high-level memory layout definition tools. The build system could support multiple options, but the first implementation shall focus on portability.
Having a set of header files, which (as the tf-m build system already shows) make the needed information available for both the C program, the linker and the build system, seems to be a good fit to me. It might not be the most user friendly, but is highly accessible.
What those header files actually do contain is a different question. Sor security reasons it may be a good idea to remove all information not needed by the NS world. Luckily CMake has the needed features to solve this issue.
And when we are at the topic, we need to provide a solution for defining available peripherals to as the secure vs non-secure peripheral availability is also controlled by the secure-side.
There seems to be room for a tool independent of tf-m to help standardizing the format this information can be captured in, to help portability of this information and to enhance user-experience. Unfortunately CMSIS-Zone (as per this page https://arm-software.github.io/CMSIS_5/Zone/html/zTInstall.html ) is an IDE extension and thus it is hardly applicable in a command-line focused build environment.
/George
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Robert Rostohar via TF-M
Sent: 03 February 2020 08:15
To: TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org>
Subject: Re: [TF-M] Exporting flash_layout.h and region_defs.h
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(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Devaraj Ranganna via TF-M
Sent: Friday 31 January 2020 17:09
To: TF-M(a)lists.trustedfirmware.org<mailto: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.
