Hi all,
There is a change open for review that adds configuration of FPU-related registers to the architecture-abstraction layer in TF-M, and removes this same configuration from platform support files. The reasoning for this is that these registers are defined by the Arm architecture, so FPU config can be unified for all platforms with the same architecture.
For Armv8-M, this also includes configuration to ensure that information is not leaked in FPU registers to NSPE when the SPE uses the FPU, and to permit the NSPE to access the FPU.
By default, TF-M will still be built without the FPU used in the SPE.
You can review the changes at:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5405 Arch: Add function to configure coprocessors
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5406 Platform: Remove platform-specific FPU config
It would be especially helpful if platform owners could check that they are happy with FPU config being moved out of the platform support files.
Kind regards,
Jamie
Hi Michel,
Some of the configurations on ST platform building is broken.
Please see the details in the following ticket:
https://developer.trustedfirmware.org/T808
Would you please have a look.
Thanks.
Best Regards,
Kevin
Hello,
The next Technical Forum is planned on Thursday, September 3 at 15:00-16:00 UTC (US time zone).
Please reply on this email with your proposals for agenda topics.
Recording and slides of previous meetings are here:
https://www.trustedfirmware.org/meetings/tf-m-technical-forum/
Best regards,
Anton Komlev
Hi Thomas,
Sorry if I misunderstand your problem. Does it mean that diverse compilers require different core config flags?
Best regards,
Hu Ziji
________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: Tuesday, August 25, 2020 7:39 PM
To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org>
Subject: [TF-M] New build system with IAR
I've started looking at the new build system, and it looks like a nice improvement.
I have a problem, that likely has a simple solution, although I'm not sure which.
I've looked at the AN521 target, and the preload.cmake file is included very early from the root CMakeLists.txt
The first line of preload.cmake is:
---
set(CMAKE_SYSTEM_PROCESSOR cortex-m33+nodsp)
---
For IAR that line should be:
---
set(CMAKE_SYSTEM_PROCESSOR Cortex-M33.no_dsp)
---
I need to discriminate between the toolchains already there, but I haven't figured out what the best way would be to do that. Not much is setup at this moment in the run.
Ideas?
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>
Hi,
CMAKE_SYSTEM_PROCESSOR identifies the CPU the build targets. If this string is passed to the compiler as a command line flag, that seems to be an error to me.
Also I have the feeling that this value should be more hardware specific. A Cortex-M33 CPU has many configuration options to be set when it is put into a system, and different set of options may need different compiler switches. All this complexity might not be needed in the build-system and it could be better to hide it.
I suggest naming the CMAKE_SYSTEM_PROCESSOR after the "chip" (i.e. AN521). The compiler specific files can map this name to the appropriate set of compiler options, and the compiler will set the "feature test macros" described in [1]. Source code can use these macros to configure itself properly. In the build system only features having an effect on CMake files shall be visible. (I.e. if a feature needs a different file to be compiled in.)
[1] https://developer.arm.com/documentation/101028/0011/Feature-test-macros?lan…
/George
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M
Sent: 25 August 2020 15:56
To: David Hu <David.Hu(a)arm.com>; tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] New build system with IAR
Hi David,
Apparently yes.
Here are the valid M33 choices for IAR:
---
thomasto@ubuntu-20:~/tf-m1/trusted-firmware-m$ iccarm --cpu list|grep -i m33
Cortex-M33
Cortex-M33.no_dsp
Cortex-M33.fp
Cortex-M33.fp.no_dsp
Cortex-M33.no_se
Cortex-M33.no_dsp.no_se
Cortex-M33.fp.no_se
Cortex-M33.fp.no_dsp.no_se
---
Cheers,
Thomas
Den 2020-08-25 kl. 15:49, skrev David Hu:
Hi Thomas,
Sorry if I misunderstand your problem. Does it mean that diverse compilers require different core config flags?
Best regards,
Hu Ziji
________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org><mailto:tf-m-bounces@lists.trustedfirmware.org> on behalf of Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org><mailto:tf-m@lists.trustedfirmware.org>
Sent: Tuesday, August 25, 2020 7:39 PM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org><mailto:tf-m@lists.trustedfirmware.org>
Subject: [TF-M] New build system with IAR
I've started looking at the new build system, and it looks like a nice improvement.
I have a problem, that likely has a simple solution, although I'm not sure which.
I've looked at the AN521 target, and the preload.cmake file is included very early from the root CMakeLists.txt
The first line of preload.cmake is:
---
set(CMAKE_SYSTEM_PROCESSOR cortex-m33+nodsp)
---
For IAR that line should be:
---
set(CMAKE_SYSTEM_PROCESSOR Cortex-M33.no_dsp)
---
I need to discriminate between the toolchains already there, but I haven't figured out what the best way would be to do that. Not much is setup at this moment in the run.
Ideas?
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>
--
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>
Just an update to this,
I have merged the patch which upgrades to the latest mbedTLS tag. The PSA Arch initial attestation test suite fails to build after this merge due to width change of `ecc_curve_t` type. The issue is reported here in PSA Arch test github project : https://github.com/ARM-software/psa-arch-tests/pull/232
The patch for changing the ITS_MAX_ASSET_SIZE is still outstanding and I hope to merge it after a week.
Best Regards
Soby Mathew
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Soby Mathew via TF-M
Sent: 11 August 2020 16:24
To: TF-M mailing list <tf-m(a)lists.trustedfirmware.org>
Subject: [TF-M] Patch to upgrade crypto service to use latest mbedTLS tag (v2.23.0)
Hi Everyone
The following patch updates the crypto service in TF-M to use the latest mbedTLS tag v2.23.0. All reviews for the same will be much appreciated.
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5252/1
With this update, additional PSA APIs psa_hash_compute() and psa_hash_compare() are now supported.
There is also another patch for platforms to update the ITS_MAX_ASSET_SIZE when testing with PSA Crypto API compliance test as one of the tests require a larger size: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5253/1 . Could the platform owners review the same and let me know whether the size changes are OK ?
With the above patches, the API compliance remains the same as v1.0 Beta 3 and the PSA Crypto compliance test suite gives the below results (as tested on AN521) :
************ Crypto Suite Report **********
TOTAL TESTS : 61
TOTAL PASSED : 42
TOTAL SIM ERROR : 0
TOTAL FAILED : 17
TOTAL SKIPPED : 2
******************************************
Best Regards
Soby Mathes
Thanks Andrew for the update. Just to confirm that AN521 is not affected.
Best Regards
Soby Mathew
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrew Murray via TF-M
Sent: 20 August 2020 08:04
To: tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] Deprecate AN539 platform
Hi Thomas :)
Thanks for that note about the AN521.
I've just checked and I was mistaken - it is in fact the AN521 that I am using (rather than the AN539).
I therefore have no objection to the deprecation.
Sorry about wasting your time :(
Andrew ;)
--
Andrew Murray
indie Semiconductor |Technical Director | MCU Architectures & Security
---------- Forwarded message ----------
From: "Thomas Törnblom" <thomas.tornblom(a)iar.com<mailto:thomas.tornblom@iar.com>>
To: <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Cc:
Bcc:
Date: Thu, 20 Aug 2020 08:51:34 +0200
Subject: Re: [TF-M] Deprecate AN539 platform
AN521 is also mps2+/m33.
Hi Thomas :)
Thanks for that note about the AN521.
I've just checked and I was mistaken - it is in fact the AN521 that I am
using (rather than the AN539).
*I therefore have no objection to the deprecation*.
Sorry about wasting your time :(
Andrew ;)
*--*
*Andrew Murray*
*indie Semiconductor |Technical Director | MCU Architectures & Security*
---------- Forwarded message ----------
From: "Thomas Törnblom" <thomas.tornblom(a)iar.com>
To: <tf-m(a)lists.trustedfirmware.org>
Cc:
Bcc:
Date: Thu, 20 Aug 2020 08:51:34 +0200
Subject: Re: [TF-M] Deprecate AN539 platform
AN521 is also mps2+/m33.
For some reason that I've not been able to track down, using -DBL2=False
on the cmake command line causes ASM_FLAGS to have duplicated debug
flags and defines.
It does not happen to C_FLAGS and it doesn't happen with -DBL2=True.
I've worked around the issue in
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5365, but
a cleaner solution would be to avoid this in the first place.
I would appreciate if someone with more cmake experience could have a go
at this.
It causes build failures with IAR, and ARMCLANG and GNUARM doesn't care
about the duplicates.
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>
AN521 is also mps2+/m33.
Den 2020-08-20 kl. 08:48, skrev Andrew Murray via TF-M:
> Hi Soby ;)
>
> I'm currently using an MPS2+ board with the AN539 system to experiment
> with TF-M code for a new M33-based, IC design. Does "deprecating the
> AN539 platform" effectively mean deprecating TF-M support for the
> MPS2+ FPGA platform entirely? In other words: is AN539 the only
> example subsystem for the MPS2+ board that supports the M33 and TF-M?
> If it is, then I'd like to object (for what that's worth!)
>
> (Feel free to try to persuade me of the merits of an alternative
> prototyping platform.)
>
> Andrew ;)
>
> /--/
>
> /Andrew Murray/
>
> /indie Semiconductor |Technical Director | MCU Architectures & Security/
>
> //
>
>
>
> ...
> From: Soby Mathew <Soby.Mathew(a)arm.com <mailto:Soby.Mathew@arm.com>>
> To: TF-M mailing list <tf-m(a)lists.trustedfirmware.org
> <mailto:tf-m@lists.trustedfirmware.org>>
> Cc:
> Bcc:
> Date: Mon, 17 Aug 2020 14:11:36 +0000
> Subject: [TF-M] Deprecate AN539 platform
>
> Hi Everyone,
>
> As mentioned in
> https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/contr…,
> we would like to propose the deprecation of AN539 MPS2 platform and
> remove the same from TF-M master after next release. As per the
> process, this proposal will be open for discussion for a period of 4
> weeks and if there are no major objections, the platform will be
> marked as deprecated.
>
> Thanks & Regards
>
> Soby Mathew
>
>
--
*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>
