Preliminary change showing passing TF-M regression available here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/2391
Oct 31 2019
Oct 23 2019
Assigned to @davidwang for futher tracking and follow up.
Aug 8 2019
Aug 5 2019
Aug 2 2019
Changes for this issue:
Jul 31 2019
Jul 26 2019
Patch for this is available here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1661
Jul 25 2019
Jul 24 2019
Hi @qixiang , could you help debugging? Most probably the faulty commit is blocked in an fault handler, it would be good to know which instruction causes the fault to be triggered to speed up analysis from developer's point of view.
Jul 23 2019
This will be completed by an additional refactoring to use abstracted OS interface when possible (i.e. os_wrapper_*) to be done by @kevin-peng-hao . Please use this ticket to keep track of the additional change.
Jul 19 2019
One additional change for this that I missed on the first patch (thanks @matetothpal ): https://review.trustedfirmware.org/c/trusted-firmware-m/+/1594/
Jul 17 2019
Jul 16 2019
As explained above, this is not an issue as if a user project needs to include for some reason more than one implementation of the same PSA crypto interface, it's up to the user to provide a separation of the include trees.
Jul 15 2019
There is no conflict anywhere in the header names of the TF-M project. Your use case is to have both Mbed Crypto and TF-M as part of the same IDE project, at that point is up to you to provide a clear separation of the different include trees of Mbed Crypto and TF-M, and not rely on the fact that having the same names they will have same contents, as they are two different implementations of the same interface, coming from two different projects and not distributed together (i.e. they have different paths by design).
Not sure what is your use case, but I don't see how it's possible to compile Mbed Crypto and TF-M Crypto as part of the same application without doing symbol renaming of one of the two, given that they export the same symbol names. So I assume you have some way of renaming the symbols of either of the two before compilation, or excluding one of the two at link time.
The expected use case is that an application will have to use a single implementation of the PSA Crypto interface at a time, so there won't be any conflict. In this case the module of the application will just "#include psa/crypto.h" as main header.
the only common difference in the headers is the different license used by the headers distributed by TF-M and the ones distributed by Mbed Crypto.
Change for this is available here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1562
Jul 12 2019
HI @qixiang , the option to build with the debug version of Mbed Crypto or Mbed TLS is presented in our documentation just for the sake of completeness, but it's not something that we actively guarantee (i.e. we can't guarantee that the debug version of the mbedcrypto/mbedtls library will fit on all our platforms, due to different requirements in size). The option should be left as default and overriden only on those platforms that can afford it, and only on designed debug sessions. In my experience so far with the Crypto service, there is no need to debug the mbedcrypto/mbedtls libraries, as that would be out of scope for a TF-M deployment. Please let me know if you have questions or doubts about this.
Jul 11 2019
Jul 10 2019
Jul 9 2019
Jul 5 2019
Possible refactoring available here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1460
Jul 4 2019
We have discussed this matter and we would like to propose a solution which might be feasible for you.
Jul 3 2019
Jun 28 2019
Additional change: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1420/
Jun 25 2019
Patch for this issue: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1409
Jun 23 2019
Change for this ticket: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1389
Jun 20 2019
Patch for this: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1373
Jun 19 2019
Jun 17 2019
Jun 14 2019
Change associated to this is here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1260
Hi Thomas, I see you mention a failure with GNUARM 7.3.1 with some build config. Can you please provide instructions on how to reproduce the build failure? As you say the failure happens with the mainline as well, that shouldn't happen and I am not seeing the failure either. Would like to try to reproduce it here if it's a genuine issue.
Jun 10 2019
This call involves a Thread -> Handler mode request on every service call to check if we are in pre-RTOS stage. I think this will introduce a non-negligible penalty; in most of the cases, we expect this call to happen when the RTOS has been loaded.
For the osKernelGetState() overhead in tfm_ns_lock_dispatch(...), I think it can be replaced by just checking ns_lock.init.
Strictly speaking, the files in interface/src are a possible implementation of the interface described in interface/include. Your integration can provide a different implementation of tfm_ns_lock_dispatch(...) based on your requirements, without the need to upstream your change. But if you think that your change can be useful for a wider audience, yes, please create a change where you modify tfm_ns_lock_dispatch(...) using CMSIS-RTOS2 APIs to check for pre-rtos stage and we'll get that reviewed.
Jun 7 2019
Thanks for summarising the three options.
Jun 6 2019
Just to be clear, as there has been some confusion between get_init_state() and get_lock_state (particularly on my side :) ), I think that the get_init_state(...) doesn't need to be exported as probably the same result can be obtained by proper usage of CMSIS-RTOS2 API's (or equivalent API's, based on the NS side scenario). Regarding the get_lock_state(...), I will comment on the other thread. T378
I agree in principle with the idea, but I have a comment regarding the implementation.
Change for this ticket is available here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1223
May 30 2019
Additional patch is required for Musca A to make sure that the quantity of RAM assigned to the SPE in the region_defs.h header is increased for IPC mode build even if the tests are not build, as RAM requirements for IPC are higher than the current default limit of 64 KB. Patch for this is available here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1184
May 25 2019
May 24 2019
Additional patch: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1147
May 18 2019
This needs to be merged, it has been open for months and the issue is being reported by Summer as well.
May 14 2019
Pacthes for this work are as follows:
Task which fixes this issue is here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1076
Change which completes this issue is here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1073
Change which fixes this issue is here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1079
May 13 2019
May 9 2019
This has been merged and I am able to run Regression in IPC mode, so this ticket can be closed.
Fix for this style issue is available here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1019
It turns out that it's a configuration option which can be overriden in our custom CSS file.
May 8 2019
The fix for this issue is available here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1011
May 7 2019
Fix for this is available here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1001/