Lines Matching refs:code
19 environment. In the current TF-M code base, both firmware components use the
23 firmware component. As a result of this workflow, the same code is placed in the
24 flash twice. For example, the code for the SHA-256 algorithm is included in
25 MCUboot, but the exact same code is duplicated in the SPE cryptography
27 and the SPE, because both are part of the PRoT code and run in the secure
28 domain. So, in theory, the code of the common cryptographic algorithms could be
30 code footprint, because the cryptographic algorithms are usually flash hungry.
41 space is how to share code between independently linked XIP applications that
43 function and global data memory addresses. In this case, the code is not
45 that can perform code relocation. Also, the lack of an MMU makes the address
46 space flat, constant and not reconfigurable at runtime by privileged code.
54 without corrupting bootloader functionality. However, with code sharing between
56 variables used by the shared code must either retain their value or must be
57 reinitialised during low level startup of the runtime firmware. The startup code
64 The bootloader is sometimes implemented as ROM code (BL1) or stored in a region
66 bootloader is immutable code and thus implements a part of the Root of Trust
67 anchor in the device, which is trusted implicitly. The shared code is primarily
69 stage. Not all of the bootloader code is reused by the runtime SPE, only some
72 Simplified steps of building with code sharing enabled:
85 .. code-block:: bash
115 call a non-shared function in SPE code through a global function pointer.
128 - Mark the global variables in the source code with special attribute
131 RAM memory layout in MCUboot with code sharing enabled:
133 .. code-block:: bash
147 RAM memory layout in SPE with code sharing enabled:
149 .. code-block:: bash
186 `lib/ext/mbedcrypto/0002-Enable-crypto-code-sharing-between-independent-binar.patch`
188 The patch needs to be manually applied in the Mbed TLS repo, if code sharing is
196 objectives. However, there is no standard way, which means that the code sharing
223 - `target_link_shared_code()`: Link shared code to the SPE and resolve symbol
234 - Link shared code to SPE: Add the filtered output of `-symdefs` to the SPE
243 - Strip unshared code from MCUboot: `arm-none-eabi-strip`
246 - Link shared code to SPE: Add `-Wl -R <SHARED_STRIPPED_CODE.axf>` to the
258 Version: TF-Mv1.2.0 + code sharing patches
294 level startup code in the SPE does not initialise the shared variables, which
297 If a bug is discovered in the shared code, it cannot be fixed with a firmware
298 upgrade, if the bootloader code is immutable. If this is the case, disabling
299 code sharing might be a solution, as the new runtime firmware could contain the
300 fixed code instead of relying on the unfixed shared code. However, this would
301 increase code footprint.
304 version of the shared code. Then new code cannot rely on the shared version.
305 The changed code and all the other shared code where it is referenced from must
313 The artifacts of the shared code extraction steps must be preserved so as to
314 remain available if new SPE firmware (that relies on shared code) is built and
319 How to use code sharing?
321 Considering the above, code sharing is an optional feature, which is disabled
324 - `TFM_CODE_SHARING`: Set to `ON` to enable code sharing.
328 specific code (e.g. device drivers) that could be shared. The shared
329 cryptography code consists mainly of the SHA-256 algorithm, the `bignum` library
333 Sharing code between the SPE and an external project is possible, even if
336 code with the SPE. The same artifacts must be created like the case of MCUboot:
343 component, only contains the shared code. It is used by the linker when
348 The artifacts of the shared code extraction steps must be preserved to be
351 When an external project is sharing code with the SPE, the `SHARED_CODE_PATH`
357 This design focuses only on sharing the cryptography code. However, other code
362 - Image metadata parsing code