Hi Bohdan
Thank you for the notes - very helpful. I will address it in the next update, or your contribution will be appreciated too.
Just a note that MuscaB1 SE (Secure enclave) is about depreciation but no plans to deprecate Musca-B1 itself.
Cheers, Anton
From: Bohdan.Hunko@infineon.com Bohdan.Hunko@infineon.com Sent: Wednesday, August 3, 2022 12:49 PM To: Sebastian.Boe@nordicsemi.no; Anton Komlev Anton.Komlev@arm.com; tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: RE: Documentation improvements
Hi everyone,
Lately I have been reading Code sharing between independently linked XIP binarieshttps://tf-m-user-guide.trustedfirmware.org/technical_references/design_docs/code_sharing.html and there are quite a lot of problems with it. I think it will be nice to update it as part of docs updates.
Here is the list of the problems I have found:
1. lib/ext/mbedcrypto/0005-Enable-crypto-code-sharing-between-independent-binar.patch now has different name now 2. bl2/src/shared_symbol_template.txt was moved to bl2/bl2_shared_symbols.txt 3. compiler_create_shared_code() and compiler_link_shared_code() were renamed to target_share_symbols() and target_link_shared_code() respectively. More over they were renamed for GCC and Clang but were not renamed for IAR. So both docs and code needs to be updated. 4. Memory footprint reduction table is broken (ConfigProfile-M column is not rendered properly due to mistake in .rst file) 5. There are a lot of references to Musca B1 board (e.g. size measurements), but as Musca B1 is getting deprecated may be it make sense to change those references to be some other platform that supports code sharing?
Regards, Bohdan Hunko
Cypress Semiconductor Ukraine Engineer CSUKR CSS ICW SW FW Mobile: +38099 50 19 714 Bohdan.Hunko@infineon.commailto:Bohdan.Hunko@infineon.com
From: Bøe, Sebastian via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: Thursday, 17 February 2022 14:39 To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org; Anton Komlev <Anton.Komlev@arm.commailto:Anton.Komlev@arm.com> Cc: nd <nd@arm.commailto:nd@arm.com> Subject: [TF-M] Re: Documentation improvements
Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safehttps://intranet-content.infineon.com/explore/aboutinfineon/rules/informationsecurity/ug/SocialEngineering/Pages/SocialEngineeringElements_en.aspx.
There is a lot of good documentation in RFC form (the design docs).
But as I understand it these docs are not updated after the design has been implemented and undergoes changes.
I think that upon completion of a design, the design docs need to be reworked into a format that resembles a reference manual and kept updated.
Please correct me if I am wrong though, this has just been my impression from the documentation. ________________________________ From: Anton Komlev via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: Thursday, February 17, 2022 1:27 PM To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd@arm.commailto:nd@arm.com> Subject: [TF-M] Documentation improvements
Hello,
The project documentation will never be ideal and we are continuing improving it.
Let me ask you for reply to this email with the pain points you have experienced or suggestions for improvements to be considered in this phase.
Your direct contribution with docs articles will be much appreciated too. For example: TF-M debugging technics and experience would be very helpful.
Thank you in advance,
Anton