1:orphan:
2
3***********
4Version 1.0
5***********
6
7New Features
8============
9-  First major release.
10
11-  A Secure FW with support for PSA Level 1 and 2 isolation on Armv8-M
12   using TrustZone extension and Dual-core Cortex-M config.
13
14-  The PSA Firmware Framework (PSA FF)/Dev API interfaces exposed by the
15   Secure FW to NS side.
16
17-  A secure FW model with NS application example.
18
19-  Secure services running within this SPE
20
21    -  Secure Storage Service (PSA Protected Storage API - 1.0.0)
22    -  Attestation (PSA Attestation API 1.0.0)
23    -  Crypto Service (PSA API 1.0-beta-3)
24    -  TF-M Audit Log
25    -  Platform Service
26    -  Internal Trusted Storage (PSA API 1.0.0)
27
28-  PSA IPC support
29
30-  Support for Armv8-M mainline and baseline and Dual-core Cortex-M systems.
31
32-  Testcases running baremetal and with RTX to test the functionality.
33
34-  BL2 bootloader for image authentication based on SHA256 and RSA-3072
35   digital signature.
36
37-  Build system based on CMake, supporting ARMCLANG and GNU Arm.
38
39-  Support for integrated CryptoCell-312 cryptographic hardware accelerator
40   on Musca-B1 platform.
41
42-  Meets requirements for Updatable RoT for PSA Functional API, Level 1 and
43   Level 2 Certifications in the feature list.
44
45Platforms supported
46===================
47Current release has been tested on:
48
49    - Cortex M33 based SSE-200 system:
50
51        - `FPGA image loaded on MPS2 board (AN521).
52          <https://developer.arm.com/Tools%20and%20Software/MPS2%20Plus%20FPGA%20Prototyping%20Board>`__
53        - `Fast model FVP_MPS2_AEMv8M (AN521).
54          <https://developer.arm.com/documentation/107925/1129/Fast-Models-trace-components/ARM-AEMv8M?lang=en>`__
55        - `Musca-A test chip board.
56          <https://developer.arm.com/documentation/101107/0000/?lang=en>`__
57        - `Musca-B1 test chip board.
58          <https://developer.arm.com/documentation/110409/0100/?lang=en>`__
59        - `Musca-S1 test chip board.
60          <https://developer.arm.com/documentation/110387/0100/?lang=en>`__
61        - `FPGA image loaded on MPS3 board (AN524).
62          <https://developer.arm.com/documentation/107789/0100/?lang=en>`__
63        - `Arm DesignStart FPGA on AWS Cloud.
64          <https://developer.arm.com/docs/101965/0102/arm-designstart-fpga-on-cloud-arm-ds-getting-started>`__
65
66    - Cortex M23 based IoT Kit system:
67
68       - `FPGA image loaded on MPS2 board.
69         <https://developer.arm.com/products/system-design/development-boards/cortex-m-prototyping-systems/mps2>`__
70
71Other supported platforms:
72
73    - Dual Core Cortex-M system:
74
75        - `Cypress PSoc64.
76          <https://www.cypress.com/documentation/product-brochures/cypress-psoc-64-secure-microcontrollers>`__
77
78Platform Limitations
79====================
80- The PSA Arch Tests need to be split into several binaries to load onto
81  Musca-A board because of low memory available to the NS world to use.
82
83- The Regression tests on MPS3 AN524 FPGA takes about 40 minutes to complete.
84  This is because AN524 uses QSPI Flash for runtime memory as the RAM is small.
85  The slow speed of QSPI device causes the tests to run slowly.
86
87- Warm reset of eFlash is not permitted on Musca-B1 due to HW bug :
88  https://developer.arm.com/documentation/110409/0100/Musca-B1-warm-reset-of-eFlash
89  As TF-M is executed in place from eFlash on Musca-B1, there is good chance
90  that a warm reset of the board will have unexpected (even non-deterministic)
91  effects on code execution. Hence the PSA Arch FF tests, which rely of warm
92  reset of Musca-B1 were executed on RAM FS using "-DSST_RAM_FS=ON" config.
93
94Known issues
95============
96Some open issues exist and will not be fixed in this release.
97
98.. list-table::
99
100  *  - AN521 FVP soft reset via AIRCR does not reset MPC / PPC / MPU and will
101       cause boot failure. This is known issue for AN521 FVP. This will cause
102       the system to not boot after a warm reset during PSA Arch FF testing.
103     - Issue : https://developer.trustedfirmware.org/T692
104
105  *  - PSA Arch Crypto tests have several known failures.
106     - See this link for detailed analysis of the failures : https://github.com/ARM-software/psa-arch-tests/blob/master/api-tests/docs/test_failure_analysis.md
107
108  *  - There are 2 additional failures for PSA-Arch Crypto tests with CC-312
109       other than the known failures. This is due to limitation of CC-312
110       implementation as it does not support MD_NONE hashing mode causing the
111       additional failures.
112     - The issue details are captured here : https://developer.trustedfirmware.org/T691
113
114  *  - PS test case 2002 and 1002 does not fail on Musca-B1 flash when
115       run for second time without erasing flash. The WRITE_ONCE assets created
116       by SST module should not be updatable but after reboot, the update seems
117       to happen and is not expected. This issue will happen on any platform
118       using persistent storage for SST.
119     - Issue created : https://developer.trustedfirmware.org/T693
120
121  *  - Boot up fails if there is unexpected data in flash on Musca-A. The boot
122       is successful and the tests pass if all the associated (SST/ITS/NV
123       Counter) flash areas are erased.
124     - Issue created : https://developer.trustedfirmware.org/T694
125
126  *  - If the flash is not erased, boot fails on Musca-B1 when SST
127       is using flash for Minsizerel config.
128     - Issue created : https://developer.trustedfirmware.org/T695
129
130  *  - When SST/ITS are using Flash on Musca-B1, PSA Arch FF test fails due
131       to known warm reset limitation in the platform. But after the failure,
132       Musca-B1 boot fails to boot. This could be related to general issues of
133       the SST module when Flash data is inconsistent.
134     - Issue created : https://developer.trustedfirmware.org/T696
135
136  *  - The eflash driver on Musca-B1 can return random failures hence
137       triggering random failures during PSA Arch ITS and PSA Arch PS tests.
138       This happens when ITS/SST is configured to use flash.
139     - Issue created : https://developer.trustedfirmware.org/T697
140
141  *  - Release build of PSA Arch Crypto tests have a different number of tests
142       when built for AN521 FVP. This is an issue in the PSA Arch Crypto tests.
143     - Issue created for PSA Arch Tests project : https://github.com/ARM-software/psa-arch-tests/issues/169
144
145--------------
146
147*Copyright (c) 2020, Arm Limited. All rights reserved.*
148