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 binaries 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:

lib/ext/mbedcrypto/0005-Enable-crypto-code-sharing-between-independent-binar.patch now has different name now
bl2/src/shared_symbol_template.txt was moved to bl2/bl2_shared_symbols.txt
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.
Memory footprint reduction table is broken (ConfigProfile-M column is not rendered properly due to mistake in .rst file)
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.com

From: Bøe, Sebastian via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Thursday, 17 February 2022 14:39
To: tf-m@lists.trustedfirmware.org; Anton Komlev <Anton.Komlev@arm.com>
Cc: nd <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 safe.

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.org>
Sent: Thursday, February 17, 2022 1:27 PM
To: tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.org>
Cc: nd <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