Just when you think you have nailed everfything down, you decide to
start with a fresh clone and stuff don't build anymore ;)
See: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6766
I have now gone over and tried building everything that has IAR support
and here are my findings.
I have used the following patches:
https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/5978https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6766
I have built for the following targets:
musca_a
mps2/an519
mps2/an521
mps2/an539
mps2/sse-200_aws
mps3/an524
cypress/psoc64
nxp/lpcxpresso55s69 (-DBL2=False as bl2 support appears to have been
added recently to this target)
stm/nucleo_l552ze_q
stm/stm32l562e_dk
The mps2/fvp_sse300 requires a compiler with support for the M55, and
the IAR compiler with support for this is not yet released.
I have run tests on the following targets:
musca_a
mps2/an519
mps2/an521
mps2/an539
The cypress/psoc64 board I have appears to be obsolete now and I could
not flash the secure image to it.
The nuvoton/m2351 appears to have IAR support, but it appears untested
as it gives linking errors for the bl2 and NS startup files.
There are some old and new warnings for type issues and some other minor
things.
The QCBOR NaN tests are still failing, see:
https://developer.trustedfirmware.org/T700
This really is an issue where the ARM ABI and IEEE 754 are incompatible
and we are following the ARM ABI. In reality neither ARMCLANG nor GNUARM
are fully ARM ABI compliant as they are not ignoring the relevant bits.
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 Antonio,
There is currently an issue filed in Zephyr to add a new sample application
that will make it easy to run the PSA API tests via Zephyr, but it we're
currently working on finalizing higher priority changes before the 1.2 code
freeze later this week:
https://github.com/zephyrproject-rtos/zephyr/issues/29476
So, there isn't an 'easy' way to build these tests in Zephyr today out of
the box using Zephyr as the RTOS on the NS side, unless you want to have a
go at it yourself in the short term while we try to make sure Zephyr is
ready for the changes in T-M 1.2.
Best regards,
Kevin
On Mon, 2 Nov 2020 at 10:29, Antonio Ken IANNILLO via TF-M <
tf-m(a)lists.trustedfirmware.org> wrote:
> Hi all,
>
> I wanted to use some other RTOS in the NS side while testing tf-m.
>
> Is there a simple way to use the Zephyr kernel or FreeRTOS in the
> tf-m-test (-DTEST_S=ON, -DTEST_NS=ON) instead of the default RTX?
>
>
>
> Best,
>
> --
>
> *Antonio Ken Iannillo*
>
> Research Scientist – SEDAN group
>
> SnT – Interdisciplinary Centre for Security, Reliability and Trust
>
> UNIVERSITÉ DU LUXEMBOURG
>
>
>
> CAMPUS KIRCHBERG
> 29, avenue John F. Kennedy
> L-1855 Luxembourg Kirchberg
> T +352 46 66 44 9660
>
>
>
> Join the conversation
>
> News <https://wwwen.uni.lu/snt/news_events> | Twitter
> <https://twitter.com/SnT_uni_lu> | Linkedin
> <https://www.linkedin.com/school/snt-lu/>
>
> www.uni.lu/snt
> --
> TF-M mailing list
> TF-M(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-m
>
I've verified that reverting the tf-m-tests patch fixes the build failures
that Chris outlined.
Cheers,
Mal
On Mon, Nov 2, 2020 at 6:16 PM David Hu via TF-M <
tf-m(a)lists.trustedfirmware.org> wrote:
> Hi Chris,
>
>
>
> Sorry for the build failure. A patch is merged into tf-m-tests but its
> peer ones in TF-M haven’t been approved yet.
>
> I have temporarily reverted that tf-m-tests patch. Please have another try.
>
>
>
> Best regards,
>
> Hu Ziji
>
>
>
> *From:* TF-M <tf-m-bounces(a)lists.trustedfirmware.org> * On Behalf Of *Christopher
> Brand via TF-M
> *Sent:* Tuesday, November 3, 2020 1:54 AM
> *To:* tf-m(a)lists.trustedfirmware.org
> *Subject:* [TF-M] cmake error
>
>
>
> I just fetched the latest master
> (1655ef5120e99c62782575d0a8b3707ebfc2148e), and I’m now getting a cmake
> error:
>
> $ cmake -S . -B build_GNUARM_Relwithdebinfo '-GUnix Makefiles'
> -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake
> -DCMAKE_BUILD_TYPE=Relwithdebinfo -DTEST_NS=ON -DTEST_S=ON -DTFM_IRQ_TEST=ON
>
> […]
>
> CMake Error at
> build_GNUARM_Relwithdebinfo/lib/ext/tfm_test_repo-src/app/CMakeLists.txt:17
> (tfm_toolchain_reload_compiler):
>
> Unknown CMake command "tfm_toolchain_reload_compiler".
>
>
>
> Looks like tf-tests commit c41f3a078713b17b5654851329d63bcc0672874b
> introduced calls to tfm_toolchain_reload_compiler(), which I don’t see
> declared anywhere.
>
>
>
> I can work around it by using a local checkout of tf-m-tests at HEAD~.
>
>
>
> Chris Brand
>
> Sr Prin Software Engr, MCD: WIRELESS
>
>
>
> Cypress Semiconductor Corp.
>
> An Infineon Technologies Company
>
> #320-13700 International Place, Richmond, British Columbia V6V 2X8 Canada
>
> www.infineon.comwww.cypress.com
>
>
>
>
> This message and any attachments may contain confidential information from
> Cypress or its subsidiaries. If it has been received in error, please
> advise the sender and immediately delete this message.
> --
> TF-M mailing list
> TF-M(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-m
>
Hi Chris,
Sorry for the build failure. A patch is merged into tf-m-tests but its peer ones in TF-M haven't been approved yet.
I have temporarily reverted that tf-m-tests patch. Please have another try.
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Christopher Brand via TF-M
Sent: Tuesday, November 3, 2020 1:54 AM
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] cmake error
I just fetched the latest master (1655ef5120e99c62782575d0a8b3707ebfc2148e), and I'm now getting a cmake error:
$ cmake -S . -B build_GNUARM_Relwithdebinfo '-GUnix Makefiles' -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Relwithdebinfo -DTEST_NS=ON -DTEST_S=ON -DTFM_IRQ_TEST=ON
[...]
CMake Error at build_GNUARM_Relwithdebinfo/lib/ext/tfm_test_repo-src/app/CMakeLists.txt:17 (tfm_toolchain_reload_compiler):
Unknown CMake command "tfm_toolchain_reload_compiler".
Looks like tf-tests commit c41f3a078713b17b5654851329d63bcc0672874b introduced calls to tfm_toolchain_reload_compiler(), which I don't see declared anywhere.
I can work around it by using a local checkout of tf-m-tests at HEAD~.
Chris Brand
Sr Prin Software Engr, MCD: WIRELESS
Cypress Semiconductor Corp.
An Infineon Technologies Company
#320-13700 International Place, Richmond, British Columbia V6V 2X8 Canada
www.infineon.com<http://www.infineon.com> www.cypress.com<http://www.cypress.com>
This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.
Hi All,
Gentle reminder about the Mbed TLS workshop tomorrow (Tuesday, November 3rd) from 2 to 6pm GMT.
See agenda and zoom link here - https://www.trustedfirmware.org/meetings/mbed-tls-workshop/
Thanks,
Shebu
-----Original Appointment-----
From: Trusted Firmware Public Meetings <linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com>
Sent: Friday, October 23, 2020 12:32 AM
To: Trusted Firmware Public Meetings; Shebu Varghese Kuriakose; mbed-tls(a)lists.trustedfirmware.org; Don Harbin; psa-crypto(a)lists.trustedfirmware.org; Dave Rodgman
Subject: Mbed TLS Virtual Workshop
When: Tuesday, November 3, 2020 2:00 PM-6:00 PM (UTC+00:00) Dublin, Edinburgh, Lisbon, London.
Where: Zoom: https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT…
You have been invited to the following event.
Mbed TLS Virtual Workshop
When
Tue Nov 3, 2020 7am – 11am Mountain Standard Time - Phoenix
Where
Zoom: https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT… (map<https://www.google.com/maps/search/Zoom:+https:%2F%2Flinaro-org.zoom.us%2Fj…>)
Calendar
shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com>
Who
•
Don Harbin - creator
•
shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com>
•
mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org>
•
psa-crypto(a)lists.trustedfirmware.org<mailto:psa-crypto@lists.trustedfirmware.org>
•
dave.rodgman(a)arm.com<mailto:dave.rodgman@arm.com>
more details »<https://www.google.com/calendar/event?action=VIEW&eid=NHVvY2FxY2o4Njk3MWZkd…>
Hi,
Trustedfirmware.org community project would like to invite you to the Mbed TLS Virtual Workshop.
The purpose of the workshop is to bring together the Mbed TLS community including maintainers, contributors and users to discuss
* The future direction of the project and
* Ways to improve community collaboration
Here is the agenda for the workshop.
Topic Time (in GMT)
Welcome 2.00 - 2.10pm
Constant-time code 2.10 – 2.30pm
Processes - how does work get scheduled? 2.30 – 2.50pm
PSA Crypto APIs 2.50 – 3.20pm
PSA Crypto for Silicon Labs Wireless
MCUs - Why, What, Where and When 3.20 – 3.50pm
Break
Roadmap, TLS1.3 Update 4.10 – 4.30pm
Mbed TLS 3.0 Plans, Scope 4.30 – 5.00pm
How do I contribute my first review
and be an effective Mbed TLS reviewer 5.00 – 5.30pm
Regards,
Don Harbin
Trusted Firmware Community Manager
==============Zoom details below:====================
Trusted Firmware is inviting you to a scheduled Zoom meeting.
Topic: Mbed TLS Virtual Workshop
Time: Nov 3, 2020 02:00 PM Greenwich Mean Time
Join Zoom Meeting
https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT…<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9531520…>
Meeting ID: 953 1520 0315
Passcode: 143755
One tap mobile
+16699009128,,95315200315# US (San Jose)
+12532158782,,95315200315# US (Tacoma)
Dial by your location
+1 669 900 9128 US (San Jose)
+1 253 215 8782 US (Tacoma)
+1 346 248 7799 US (Houston)
+1 646 558 8656 US (New York)
+1 301 715 8592 US (Germantown)
+1 312 626 6799 US (Chicago)
888 788 0099 US Toll-free
877 853 5247 US Toll-free
Meeting ID: 953 1520 0315
Find your local number: https://linaro-org.zoom.us/u/apL3hgti4<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fu%2FapL3hgt…>
Going (shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com>)? Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NHVvY2FxY2o4Njk3MWZkd…>
Invitation from Google Calendar<https://www.google.com/calendar/>
You are receiving this courtesy email at the account shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com> because you are an attendee of this event.
To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.
Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn More<https://support.google.com/calendar/answer/37135#forwarding>.
I just fetched the latest master (1655ef5120e99c62782575d0a8b3707ebfc2148e), and I'm now getting a cmake error:
$ cmake -S . -B build_GNUARM_Relwithdebinfo '-GUnix Makefiles' -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Relwithdebinfo -DTEST_NS=ON -DTEST_S=ON -DTFM_IRQ_TEST=ON
[...]
CMake Error at build_GNUARM_Relwithdebinfo/lib/ext/tfm_test_repo-src/app/CMakeLists.txt:17 (tfm_toolchain_reload_compiler):
Unknown CMake command "tfm_toolchain_reload_compiler".
Looks like tf-tests commit c41f3a078713b17b5654851329d63bcc0672874b introduced calls to tfm_toolchain_reload_compiler(), which I don't see declared anywhere.
I can work around it by using a local checkout of tf-m-tests at HEAD~.
Chris Brand
Sr Prin Software Engr, MCD: WIRELESS
Cypress Semiconductor Corp.
An Infineon Technologies Company
#320-13700 International Place, Richmond, British Columbia V6V 2X8 Canada
www.infineon.com<http://www.infineon.com> www.cypress.com<http://www.cypress.com>
This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.
Hi All,
This is a reminder and heads up that TF-Mv1.2 release is planned for the end of November and TF-M code repository is aimed for freeze on Nov 4th (Wed), tagged by TF-Mv1.2-RC1 for testing. Availability of the tag will be notified via this mailing list.
Thanks,
Anton
Hi all,
I wanted to use some other RTOS in the NS side while testing tf-m.
Is there a simple way to use the Zephyr kernel or FreeRTOS in the tf-m-test (-DTEST_S=ON, -DTEST_NS=ON) instead of the default RTX?
Best,
--
Antonio Ken Iannillo
Research Scientist – SEDAN group
SnT – Interdisciplinary Centre for Security, Reliability and Trust
UNIVERSITÉ DU LUXEMBOURG
CAMPUS KIRCHBERG
29, avenue John F. Kennedy
L-1855 Luxembourg Kirchberg
T +352 46 66 44 9660
Join the conversation
News | Twitter | Linkedin
www.uni.lu/snt
Hi all,
As the isolation level 3 PoC targets for AN521 and MUSCA_B1 only at the first stage, two level-3-specific linker script files are created for these two platforms.
And the common linker scripts are not changed now.
This would avoid affecting the platforms who do not support isolation level 3 with a big changed linker script.
The patch for specific linker scripts can be found here:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6717
Best Regards,
Kevin
From: Kevin Peng
Sent: Wednesday, October 21, 2020 5:27 PM
To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Subject: RE: Feature branch 'feature-isolation-level3' is created for related patches merging
Hi all,
We've finished the PoC of isolation level 3 along with the new TFM HAL on the feature branch.
And now we are migrating the patches to master branch by cherry-picking, squashing and refining.
Here are the several topics ongoing parallel:
* Linker script changes for isolation L3<https://review.trustedfirmware.org/q/topic:%22linker_script_isolation%22+(s…>
* Isolation HAL API<https://review.trustedfirmware.org/q/topic:%22isolation_api_implementation%…>
* SPM log<https://review.trustedfirmware.org/q/topic:%22SPM_LOG%22+(status:open%20OR%…>
* SP log<https://review.trustedfirmware.org/q/topic:%22tfm_sp_log%22+(status:open%20…>
And the HAL API docs:
* Docs: Design of the TF-M isolation HAL<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4829>
More patches will be coming soon, will keep you update-to-date.
Please help on reviews, thanks.
Best Regards,
Kevin
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M
Sent: Wednesday, September 9, 2020 3:21 PM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: [TF-M] Feature branch 'feature-isolation-level3' is created for related patches merging
Hi,
A new branch created for two repos 'TF-M/tf-m-tests' and 'TF-M/trusted-firmware-m', this feature branch is for isolation related patches merging.
The POC patches would come in following days, first platform would be AN521. If you want to try this branch, please:
IMPORTANT:
Checkout 'feature-isoaltion-level3' branch for both 'TF-M/tf-m-tests' and 'TF-M/trusted-firmware-m'.
BR
/Ken
Hi Everyone
This is a heads to notify that we have some patches to upgrade to mbedtls-2.24 tag and we hope to merge them today. The patches can be found here:
https://review.trustedfirmware.org/q/topic:%22mbedtls-2.24%22+(status:open%…
Please be aware that there is a change in tf-m-tests as well which means that if the build system is setup to download latest master of tf-m-tests, you need to update TF-M to latest master as well for the build to succeed. This is not ideal workflow, but we are thinking about some system to avoid this kind of problems.
Best Regards
Soby Mathew
An update on this:
The platform has been deprecated and is scheduled for removal from upstream after TFvMv1.2 release. Patches to warn about deprecation of this platform have been merged https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6516
Best Regards
Soby Mathew
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Soby Mathew via TF-M
Sent: 17 August 2020 15:12
To: TF-M mailing list <tf-m(a)lists.trustedfirmware.org>
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
Hi,
I think this effort should be done together with other tf.org projects using the same technology (Sphinx). Can you pls sync up with the TF-A team?
Related to the details:
* I suggest referring to the RTD style guide [1] instead of Python. The text is much smaller, does not cover topics we don’t need and your points 1-5 are aligned. Point 6 is conflicting as RTD allows 6 levels.
* I disagree on 11. “A drawing is worth 1e3 words”, and hiding these at the end is not a good practice.
* 12: do we really need this? How often are people doing such things?
* 13 is ok 😊
* 14: might be too strict. What if a term is over used and may have a different meaning is some sections (i.e. platform, host, etc...).
[1] https://documentation-style-guide-sphinx.readthedocs.io/en/latest/style-gui…
/George
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Minos Galanakis via TF-M
Sent: 30 June 2020 16:23
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] [RFC] TF-M Documentation Contribution Format
Hi,
As the project matures, and the community grows, I would like to revive an old discussion and suggest that we set
some guidelines for contributing to the project's documentation.
I would like to propose that we establish a minimal sub-set of rules, based on the
official Python guidelines<https://devguide.python.org/documenting/#style-guide> which is the most widely used notation. This offers compatibility with
existing tools for proofing and producing said documentation.
The following rules should be considered:
1. H1 document title headers should be expressed by # with over-line (rows on top and bottom) of the text
2. Only ONE H1 header should allowed per document, ideally placed on top of the page.
3. H2 headers should be expressed by * with over-line
4. H2 header's text should be UNIQUE in per document basis
5. H3 headers should be expressed by a row of '='
6. H4 headers should be expressed by a row of '-'
7. H3 and H4 headers have no limitation about naming. They can have similar names on the same document, as long as they have different parents.
8. H5 headers should be expressed by a row of '^'
9. H5 headers will be rendered in document body but not in menus on the navigation bar.
10. Do not use more than 5 level of heading
11. When writing guide, which are expected to be able to be readable by command line tools, it would be best practice to add long complicated tables, and UML diagrams in the bottom of the page and using internal references(auto-label). Please refer to the `tfm_sw_requirement.rst<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/getti…>` as an example
12. No special formatting should be allowed in Headers ( code, underline, strike-through etc )
13. Long URLs and external references should be placed at the bottom of the page and referenced in the body of the document
14. New introduced terms and abbreviations should be added to Glossary and directly linked by the `:term:` notation across all documents using it.
When something new, which is not covered is required, the rule should be first to follow the any reference to of an existing document, and the Python Documentation rules otherwise.
Please let me know if you have any questions/objection or proposals or new rules you would like to consider. Any feedback is more than welcome.
Minos
Hi Anton,
I would like to give an overview about the code sharing feature.
Tamas
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Shawn Shan via TF-M
Sent: 2020. október 26., hétfő 3:30
To: Anton Komlev <Anton.Komlev(a)arm.com>; tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] TF-M Technical Forum call – October 29
Hi Anton,
I would like to briefly introduce the update of TF-M log system, about 20 minutes.
Best regards,
Shawn
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M
Sent: Friday, October 23, 2020 5:56 PM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: [TF-M] TF-M Technical Forum call – October 29
Hello,
The next Technical Forum is planned on Thursday, October 29 (for 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
Hi,
Reminder the isolation design document which will be merged before code freeze, too:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4730
Thanks.
/Ken
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Peng via TF-M
Sent: Friday, October 23, 2020 5:32 PM
To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Feature branch 'feature-isolation-level3' is created for related patches merging
Another topic added:
New isolation implementation<https://review.trustedfirmware.org/q/topic:%22isolation-implement%22+(statu…> based on the isolation APIs.
We are opening for new review comments before the end of October to catch the TF-M v1.2 release code freeze.
Best Regards,
Kevin
From: Kevin Peng
Sent: Wednesday, October 21, 2020 5:27 PM
To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Subject: RE: Feature branch 'feature-isolation-level3' is created for related patches merging
Hi all,
We've finished the PoC of isolation level 3 along with the new TFM HAL on the feature branch.
And now we are migrating the patches to master branch by cherry-picking, squashing and refining.
Here are the several topics ongoing parallel:
* Linker script changes for isolation L3<https://review.trustedfirmware.org/q/topic:%22linker_script_isolation%22+(s…>
* Isolation HAL API<https://review.trustedfirmware.org/q/topic:%22isolation_api_implementation%…>
* SPM log<https://review.trustedfirmware.org/q/topic:%22SPM_LOG%22+(status:open%20OR%…>
* SP log<https://review.trustedfirmware.org/q/topic:%22tfm_sp_log%22+(status:open%20…>
And the HAL API docs:
* Docs: Design of the TF-M isolation HAL<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4829>
More patches will be coming soon, will keep you update-to-date.
Please help on reviews, thanks.
Best Regards,
Kevin
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M
Sent: Wednesday, September 9, 2020 3:21 PM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: [TF-M] Feature branch 'feature-isolation-level3' is created for related patches merging
Hi,
A new branch created for two repos 'TF-M/tf-m-tests' and 'TF-M/trusted-firmware-m', this feature branch is for isolation related patches merging.
The POC patches would come in following days, first platform would be AN521. If you want to try this branch, please:
IMPORTANT:
Checkout 'feature-isoaltion-level3' branch for both 'TF-M/tf-m-tests' and 'TF-M/trusted-firmware-m'.
BR
/Ken
Hi Anton,
I would like to briefly introduce the update of TF-M log system, about 20 minutes.
Best regards,
Shawn
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M
Sent: Friday, October 23, 2020 5:56 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] TF-M Technical Forum call – October 29
Hello,
The next Technical Forum is planned on Thursday, October 29 (for 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
You have been invited to the following event.
Title: TF-M Tech forum
This is an open forum for anyone to participate and it is not restricted to
Trusted Firmware project members. It will operate under the guidance of the
TF TSC.Feel free to forward it to colleagues.Details of previous meetings
are
here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/==…
Info====Trusted Firmware is inviting you to a scheduled Zoom meeting.Topic:
TF-M Tech forum - US Time Zone FriendlyTime: Oct 29, 2020 03:00 PM
Greenwich Mean Time Every 4 weeks on Thu, until
Mar 18, 2021, 6 occurrence(s) Oct 29, 2020 03:00
PM Nov 26, 2020 03:00 PM
Dec 24, 2020 03:00 PM Jan 21, 2021 03:00
PM Feb 18, 2021 03:00 PM
Mar 18, 2021 03:00 PMPlease download and import the following
iCalendar (.ics) files to your calendar system.Weekly:
https://linaro-org.zoom.us/meeting/tJEocOmvpz4tHtYu0Wvn2fOsG91u0kv_ECPd/ics…
Zoom
Meetinghttps://linaro-org.zoom.us/j/95570795742?pwd=N21YWHJpUjZyS3Fzd0tkOG9hanpidz09Meeting
ID: 955 7079 5742Passcode: 177658One tap mobile+12532158782,,95570795742#
US (Tacoma)+13462487799,,95570795742# US (Houston)Dial by your
location +1 253 215 8782 US (Tacoma)
+1 346 248 7799 US (Houston)
+1 669 900 9128 US (San Jose) +1 301 715
8592 US (Germantown) +1 312 626 6799 US
(Chicago) +1 646 558 8656 US (New York)
877 853 5247 US Toll-free
888 788 0099 US Toll-freeMeeting ID: 955 7079 5742Find your local number:
https://linaro-org.zoom.us/u/abx3I7IoRq
When: Every 4 weeks from 8am to 9am on Thursday from Thu Oct 29 to Fri Mar
26, 2021 Mountain Standard Time - Phoenix
Where:
https://linaro-org.zoom.us/j/95570795742?pwd=N21YWHJpUjZyS3Fzd0tkOG9hanpidz…
Calendar: tf-m(a)lists.trustedfirmware.org
Who:
* Don Harbin - creator
* tf-m(a)lists.trustedfirmware.org
* anton.komlev(a)arm.com
Event details:
https://www.google.com/calendar/event?action=VIEW&eid=NjQzcnZwcmEwNnV2cGoxN…
Invitation from Google Calendar: https://www.google.com/calendar/
You are receiving this courtesy email at the account
tf-m(a)lists.trustedfirmware.org because you are an attendee of this event.
To stop receiving future updates for this event, decline this event.
Alternatively you can sign up for a Google account at
https://www.google.com/calendar/ and control your notification settings for
your entire calendar.
Forwarding this invitation could allow any recipient to send a response to
the organizer and be added to the guest list, or invite others regardless
of their own invitation status, or to modify your RSVP. Learn more at
https://support.google.com/calendar/answer/37135#forwarding
You have been invited to the following event.
Title: TF-M Tech forum
About TF-M Tech forum:This is an open forum for anyone to participate and
it is not restricted to Trusted Firmware project members. It will operate
under the guidance of the TF TSC.Feel free to forward it to
colleagues.Details of previous meetings are
here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/==…Topic:
TF-M Tech forum - Asia Time Zone FriendlyTime: Nov 12, 2020 07:00 AM
Greenwich Mean Time Every 4 weeks on Thu, until
Mar 4, 2021, 5 occurrence(s) Nov 12, 2020 07:00
AM Dec 10, 2020 07:00 AM
Jan 7, 2021 07:00 AM Feb 4, 2021 07:00
AM Mar 4, 2021 07:00 AMPlease download and
import the following iCalendar (.ics) files to your calendar system.Weekly:
https://linaro-org.zoom.us/meeting/tJYodOyvpz8jGNEc_1ykVap8Zg6oTLqZZSeJ/ics…
Zoom
Meetinghttps://linaro-org.zoom.us/j/92535794925?pwd=TTl0cmo4R2hTNm8wcHo1M3ZKdjlnUT09Meeting
ID: 925 3579 4925Passcode: 414410One tap mobile+12532158782,,92535794925#
US (Tacoma)+13462487799,,92535794925# US (Houston)Dial by your
location +1 253 215 8782 US (Tacoma)
+1 346 248 7799 US (Houston)
+1 669 900 9128 US (San Jose) +1 301 715
8592 US (Germantown) +1 312 626 6799 US
(Chicago) +1 646 558 8656 US (New York)
888 788 0099 US Toll-free
877 853 5247 US Toll-freeMeeting ID: 925 3579 4925Find your local number:
https://linaro-org.zoom.us/u/aesS64I7GW
When: Every 4 weeks from 12am to 1am on Thursday from Thu Nov 12 to Fri May
28, 2021 Mountain Standard Time - Phoenix
Where:
https://linaro-org.zoom.us/j/92535794925?pwd=TTl0cmo4R2hTNm8wcHo1M3ZKdjlnUT…
Calendar: tf-m(a)lists.trustedfirmware.org
Who:
* Don Harbin - creator
* tf-m(a)lists.trustedfirmware.org
* anton.komlev(a)arm.com
Event details:
https://www.google.com/calendar/event?action=VIEW&eid=NTAyYXB1M2xsYzJ2MzU3M…
Invitation from Google Calendar: https://www.google.com/calendar/
You are receiving this courtesy email at the account
tf-m(a)lists.trustedfirmware.org because you are an attendee of this event.
To stop receiving future updates for this event, decline this event.
Alternatively you can sign up for a Google account at
https://www.google.com/calendar/ and control your notification settings for
your entire calendar.
Forwarding this invitation could allow any recipient to send a response to
the organizer and be added to the guest list, or invite others regardless
of their own invitation status, or to modify your RSVP. Learn more at
https://support.google.com/calendar/answer/37135#forwarding
Hello,
The next Technical Forum is planned on Thursday, October 29 (for 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
Hi all,
We've finished the PoC of isolation level 3 along with the new TFM HAL on the feature branch.
And now we are migrating the patches to master branch by cherry-picking, squashing and refining.
Here are the several topics ongoing parallel:
* Linker script changes for isolation L3<https://review.trustedfirmware.org/q/topic:%22linker_script_isolation%22+(s…>
* Isolation HAL API<https://review.trustedfirmware.org/q/topic:%22isolation_api_implementation%…>
* SPM log<https://review.trustedfirmware.org/q/topic:%22SPM_LOG%22+(status:open%20OR%…>
* SP log<https://review.trustedfirmware.org/q/topic:%22tfm_sp_log%22+(status:open%20…>
And the HAL API docs:
* Docs: Design of the TF-M isolation HAL<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4829>
More patches will be coming soon, will keep you update-to-date.
Please help on reviews, thanks.
Best Regards,
Kevin
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M
Sent: Wednesday, September 9, 2020 3:21 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] Feature branch 'feature-isolation-level3' is created for related patches merging
Hi,
A new branch created for two repos 'TF-M/tf-m-tests' and 'TF-M/trusted-firmware-m', this feature branch is for isolation related patches merging.
The POC patches would come in following days, first platform would be AN521. If you want to try this branch, please:
IMPORTANT:
Checkout 'feature-isoaltion-level3' branch for both 'TF-M/tf-m-tests' and 'TF-M/trusted-firmware-m'.
BR
/Ken
Hi,
Thank Tamas for the scenario, this is a good example.
There were some queries and initial investigations before, which shows that some users want to protect the implementation of their services, and check if there are mechanisms to help on that. I think isolation level 3 is applicable to this scenario.
/Ken
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Tamas Ban via TF-M
Sent: Wednesday, October 21, 2020 7:26 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Feature branch 'feature-isolation-level3' is created for related patches merging
Hi Andrej,
the following scenario comes to my mind:
* There is a product where secure services from different vendors are merged together and these are together make up the ARoT code.
* There is a vendor who has a novel algorithm what he wants to protect against reverse engineering.
* Image is delivered to the device in encrypted format. But on the device it is decrypted when moved to primary slot.
* This secure partition needs the L3 isolation to be hidden from the other secure services within ARoT code.
Tamas
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Andrej Butok via TF-M
Sent: 2020. október 21., szerda 11:53
To: Kevin Peng <Kevin.Peng(a)arm.com<mailto:Kevin.Peng@arm.com>>
Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: Re: [TF-M] Feature branch 'feature-isolation-level3' is created for related patches merging
Hi Kevin,
Do you know any real (not academic) MCU application where L3 isolation is required?
People ask, but I have nothing to tell. Even for L2 is difficult to find something, for most of cases L1 is enough.
Thanks,
Andrej
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Kevin Peng via TF-M
Sent: Wednesday, October 21, 2020 11:27 AM
To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Subject: Re: [TF-M] Feature branch 'feature-isolation-level3' is created for related patches merging
Hi all,
We've finished the PoC of isolation level 3 along with the new TFM HAL on the feature branch.
And now we are migrating the patches to master branch by cherry-picking, squashing and refining.
Here are the several topics ongoing parallel:
* Linker script changes for isolation L3<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>
* Isolation HAL API<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>
* SPM log<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>
* SP log<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>
And the HAL API docs:
* Docs: Design of the TF-M isolation HAL<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>
More patches will be coming soon, will keep you update-to-date.
Please help on reviews, thanks.
Best Regards,
Kevin
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M
Sent: Wednesday, September 9, 2020 3:21 PM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: [TF-M] Feature branch 'feature-isolation-level3' is created for related patches merging
Hi,
A new branch created for two repos 'TF-M/tf-m-tests' and 'TF-M/trusted-firmware-m', this feature branch is for isolation related patches merging.
The POC patches would come in following days, first platform would be AN521. If you want to try this branch, please:
IMPORTANT:
Checkout 'feature-isoaltion-level3' branch for both 'TF-M/tf-m-tests' and 'TF-M/trusted-firmware-m'.
BR
/Ken
Hi Andrej,
the following scenario comes to my mind:
* There is a product where secure services from different vendors are merged together and these are together make up the ARoT code.
* There is a vendor who has a novel algorithm what he wants to protect against reverse engineering.
* Image is delivered to the device in encrypted format. But on the device it is decrypted when moved to primary slot.
* This secure partition needs the L3 isolation to be hidden from the other secure services within ARoT code.
Tamas
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M
Sent: 2020. október 21., szerda 11:53
To: Kevin Peng <Kevin.Peng(a)arm.com>
Cc: tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] Feature branch 'feature-isolation-level3' is created for related patches merging
Hi Kevin,
Do you know any real (not academic) MCU application where L3 isolation is required?
People ask, but I have nothing to tell. Even for L2 is difficult to find something, for most of cases L1 is enough.
Thanks,
Andrej
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Kevin Peng via TF-M
Sent: Wednesday, October 21, 2020 11:27 AM
To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Subject: Re: [TF-M] Feature branch 'feature-isolation-level3' is created for related patches merging
Hi all,
We've finished the PoC of isolation level 3 along with the new TFM HAL on the feature branch.
And now we are migrating the patches to master branch by cherry-picking, squashing and refining.
Here are the several topics ongoing parallel:
* Linker script changes for isolation L3<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>
* Isolation HAL API<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>
* SPM log<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>
* SP log<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>
And the HAL API docs:
* Docs: Design of the TF-M isolation HAL<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>
More patches will be coming soon, will keep you update-to-date.
Please help on reviews, thanks.
Best Regards,
Kevin
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M
Sent: Wednesday, September 9, 2020 3:21 PM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: [TF-M] Feature branch 'feature-isolation-level3' is created for related patches merging
Hi,
A new branch created for two repos 'TF-M/tf-m-tests' and 'TF-M/trusted-firmware-m', this feature branch is for isolation related patches merging.
The POC patches would come in following days, first platform would be AN521. If you want to try this branch, please:
IMPORTANT:
Checkout 'feature-isoaltion-level3' branch for both 'TF-M/tf-m-tests' and 'TF-M/trusted-firmware-m'.
BR
/Ken
Hi Kevin,
Do you know any real (not academic) MCU application where L3 isolation is required?
People ask, but I have nothing to tell. Even for L2 is difficult to find something, for most of cases L1 is enough.
Thanks,
Andrej
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Peng via TF-M
Sent: Wednesday, October 21, 2020 11:27 AM
To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org>
Subject: Re: [TF-M] Feature branch 'feature-isolation-level3' is created for related patches merging
Hi all,
We've finished the PoC of isolation level 3 along with the new TFM HAL on the feature branch.
And now we are migrating the patches to master branch by cherry-picking, squashing and refining.
Here are the several topics ongoing parallel:
* Linker script changes for isolation L3<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>
* Isolation HAL API<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>
* SPM log<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>
* SP log<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>
And the HAL API docs:
* Docs: Design of the TF-M isolation HAL<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>
More patches will be coming soon, will keep you update-to-date.
Please help on reviews, thanks.
Best Regards,
Kevin
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M
Sent: Wednesday, September 9, 2020 3:21 PM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: [TF-M] Feature branch 'feature-isolation-level3' is created for related patches merging
Hi,
A new branch created for two repos 'TF-M/tf-m-tests' and 'TF-M/trusted-firmware-m', this feature branch is for isolation related patches merging.
The POC patches would come in following days, first platform would be AN521. If you want to try this branch, please:
IMPORTANT:
Checkout 'feature-isoaltion-level3' branch for both 'TF-M/tf-m-tests' and 'TF-M/trusted-firmware-m'.
BR
/Ken
Hi Chris,
I've raised a ticket https://github.com/ARM-software/psa-arch-tests/issues/239 on PSA Arch test github repo. It will be fixed by PSA Arch test team later.
We will follow the fix status. Thanks again for reporting this issue.
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M
Sent: Tuesday, October 20, 2020 11:05 AM
To: Christopher Brand <chris.brand(a)cypress.com>
Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] Another build issue
Hi Chris,
I agree with you. It looks like PSA arch test doesn't check the correct clone destination.
According to https://github.com/ARM-software/psa-arch-tests/blob/master/api-tests/CMakeL…, PSA arch test checks whether psa_qcbor exists.
However, the actual clone destination of psa_qcbor folder is under CMAKE_CURRENT_BINARY_DIR as https://github.com/ARM-software/psa-arch-tests/blob/master/api-tests/CMakeL… sets.
Therefore, I guess this issue will be triggered as long as CMake script execution is in the different directory as binary folder is.
I changed the destination to ${CMAKE_CURRENT_BINARY_DIR}/${PSA_TARGET_QCBOR} in check step and it looks like the issue is fixed.
IMOO, the quick workaround is to entirely remove the build directory.
I will discuss with Raef to determine a final solution.
Thanks a lot for reporting this issue!
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Christopher Brand via TF-M
Sent: Tuesday, October 20, 2020 5:57 AM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: [TF-M] Another build issue
This one is a failure when re-configuring the build (even though the configuration is the same):
$ mkdir build_GNUARM_Release
$ cmake -S . -B build_GNUARM_Release -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Release -DTEST_PSA_API=INITIAL_ATTESTATION
(lots of output - eventually succeeds)
$ cmake -S . -B build_GNUARM_Release -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Release -DTEST_PSA_API=INITIAL_ATTESTATION
(less output, eventually fails)
fatal: destination path 'psa_qcbor' already exists and is not an empty directory.
CMake Error at build_GNUARM_Release/lib/ext/psa_arch_tests-src/api-tests/CMakeLists.txt:324 (message):
git clone failed for https://github.com/laurencelundblade/QCBOR.git
I suspect that this might be due to the PSA stuff, rather than TFM per se, but it manifests when building TFM...
Chris Brand
Sr Prin Software Engr, MCD: WIRELESS
Cypress Semiconductor Corp.
An Infineon Technologies Company
#320-13700 International Place, Richmond, British Columbia V6V 2X8 Canada
www.infineon.com<http://www.infineon.com> www.cypress.com<http://www.cypress.com>
This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.
Hi Anton
If it's not possible to avoid a file generation now, it's good to have pre-generated files for a most typical configuration (l2, IPC etc.).
As I mentioned before, ideally to use TFM as a real component/framework without generation of any source code.
BUT If you believe, this requirement breaks a TFM concept, just tell us.
Thanks,
Andrej
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M
Sent: Tuesday, October 20, 2020 9:27 AM
To: tf-m(a)lists.trustedfirmware.org
Cc: tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] Generated files location
Hi Andrej,
Essentially, do you mean to move the files back to code tree and synch them with templates manually as it was ?
Cheers,
Anton
From: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.com>>
Sent: 19 October 2020 16:15
To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>>
Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: RE: Generated files location
Hi Anton,
Another option:
3. Avoid the mandatory on-the-fly generation.
Try to make TFM a component/framework, which is configurable by compile & run time parameters.
Thanks,
Andrej
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M
Sent: Monday, October 19, 2020 5:00 PM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: [TF-M] Generated files location
Hi,
Some source files in TF-M are templated and generated inside /<build_dir>/generated/ on the fly as a part of build process. This guaranty consistency between templates and generated but might make a trouble for IDE, where not all source files exist at the first run.
I see 2 options for solution:
1. Explicitly generate those files via cmake as a part of IDE project creation (1 time action)
2. Relay on CMSIS Pack for IDE, where generated files must be presents
Any alternative thoughts?
Anton
Hi Anton,
Another option:
3. Avoid the mandatory on-the-fly generation.
Try to make TFM a component/framework, which is configurable by compile & run time parameters.
Thanks,
Andrej
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M
Sent: Monday, October 19, 2020 5:00 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] Generated files location
Hi,
Some source files in TF-M are templated and generated inside /<build_dir>/generated/ on the fly as a part of build process. This guaranty consistency between templates and generated but might make a trouble for IDE, where not all source files exist at the first run.
I see 2 options for solution:
1. Explicitly generate those files via cmake as a part of IDE project creation (1 time action)
2. Relay on CMSIS Pack for IDE, where generated files must be presents
Any alternative thoughts?
Anton