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
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>
Dear all,
While I was working on the PSoC64 platform, I hit the *psa_key_id_t* type
mismatch problem.
The patch - *98ab441e096f *enables
*MBEDTLS_PSA_CRYPTO_KEY_FILE_ID_ENCODES_OWNER*
Which in terms to use the *psa_key_id_t* *structure* (psa_key_file_id_t) in
<mbed-crypto/mbedtls>/include/psa/*crypto_platform.h*
Interestingly, psa_key_id_t is also defined in <tf-m>/interface/include/psa/
*crypto_types.h*, as a uint32_t.
So, I do the following testing
I could compile the master HEAD no problem
*66ee5c8861* (HEAD, origin/master, origin/HEAD) Tools: update iat-verifier
README and samples
I assume the psa_key_id_t should be a *structure* (from
mbed-crypto/mbedtls), I applied the patch below
--- a/interface/include/psa/crypto_types.h
+++ b/interface/include/psa/crypto_types.h
@@ -211,6 +211,8 @@ typedef uint8_t psa_key_persistence_t;
*/
typedef uint32_t psa_key_location_t;+#if
!defined(MBEDTLS_PSA_CRYPTO_KEY_FILE_ID_ENCODES_OWNER)+#error Should
not compile this
/** Encoding of identifiers of persistent keys.
*
* - Applications may freely choose key identifiers in the range
@@ -222,6 +224,7 @@ typedef uint32_t psa_key_location_t;
*/
typedef uint32_t psa_key_id_t;
#define PSA_KEY_ID_INIT 0+#endif
Then, I notice that there are still many files that use *uint32_t*
psa_key_id_t in the TF-M source tree.
a) It's good (lucky?) that TF-M seems to cut it cleanly so it doesn't run
into problems (well, it happens on PSoC64, or I won't notice it).
b) It's bad that psa_key_id_t in TF-M has two different types.
I'm not going to argue what's correct/wrong. Maybe this kind of coding
could be a feature in the future. I just go with it. But I found no
information to define the boundary of the two types under the <tf-m>/docs/
directory. I would like to know where the boundary is, in TF-M.
In other words, *Which part of the code should use the structure definition
from mbedtls/mbed-crypto; which part of the code should use uint32_t ?*
In my work, the problem happens when it passes psa_key_id_t as a parameter,
the parent & child functions see it differently (HardFault, in my case,
memory violation to other parameters).
e.g.: func_a.c (structure), func_b.c (uint32_t).
func_b.h ---- the type changes when it's included by func_a.c and/or
func_b.c
Regards,
Alamy
So I see the CI system runs checkpatch, but I don't see any mention of checkpatch under the "docs" directory, or in any of the gerrit reviews, or even on the mailing list. The output in the CI system, as far as I can see, is not particularly useful (I followed the link posted on my review to https://ci.trustedfirmware.org/blue/organizations/jenkins/tf-m-static/detai… but could find anything indicating what issue was actually found).
Is there any documentation on how we can run checkptach manually? Or on how to see what the CI version is actually complaining about? Should I just be ignoring the CI checkpatch errors?
Thanks,
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,
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
