Best regards,

Bartlomiej

Hi Florek,

The `dependencies` in manifest is used by TF-M SPM to check the access permissions. For example, when your new SP asks for a secure service from Crypto SP, TF-M SPM will check if your SP explicitly sets Crypto SP as its dependency. Otherwise, TF-M SPM will reject the secure request from your SP.

The load sequence of SPs in TF-M, however, is a bit vague. The ordering is usually decided by the priority of SPs.

The higher a SP’s priority is, the earlier it is scheduled/initialized. Meanwhile, IIUC, the ordering of SPs in the same priority is not specified.

Crypto SP’s priority is set to NORMAL by default.

Please can you try to set your SP priority to LOW in its manifest?
  "priority": "LOW",

Best regards,

David

Hi,

Thank you for your fast answers. You have correctly understood the sequence.

I haven't used tfm_hal_post_partition_init_hook. I will look for it. Can you point me in the right direction?

I already have dependencies in manifest on TFM_CRYPTO, but it doesn't change order.

  "dependencies": [

    "TFM_CRYPTO"

  ]

I injected config file expanding CRYPTO_ENGINE_BUF_SIZE,  but I feel error I got is misleading, because crypto partition was not initialized.

set_property(TARGET zephyr_property_target

        APPEND PROPERTY TFM_CMAKE_OPTIONS

        -DPROJECT_CONFIG_HEADER_FILE=${CMAKE_CURRENT_SOURCE_DIR}/new_sp/config/config_tfm.h

)

Some logs with injected data:

[DBG][NEW] Starting new secure partition

[INF][NEW] version v1.18.0-dirty

[DBG][mbedcrypto] 2:0

[DBG][mbedcrypto] 1:0

[DBG][mbedcrypto] 3:-141

[DBG][NEW] Something went wrong: 9 : CRYPTO_FAILURE

Creating an empty ITS flash layout.

Creating an empty PS flash layout.

[INF][PS] Encryption alg: 0x5500200

[INF][Crypto] Provision entropy seed...

[INF][Crypto] Provision entropy seed... complete.

[DBG][Crypto] Init Mbed TLS 3.6.0...

[DBG][Crypto] Init Mbed TLS 3.6.0... complete.

[DBG][mbedcrypto] 2:0

[DBG][mbedcrypto] 1:0

[DBG][mbedcrypto] 3:0

[DBG][mbedcrypto] 4:0

I'm using PSA hash multi-part operation: psa_hash_setup, psa_hash_update, psa_hash_finish.

It is true that my partition requires crypto for proper initialization. That is why I'm looking for getting correct sequence or asynchronous approach.

Best regards,

Bartlomiej

From: Antonio De Angelis <Antonio.DeAngelis@arm.com>
Sent: Monday, June 2, 2025 1:47 PM
To: tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.org>; Florek, Bartlomiej <bartlomiej.florek@assaabloy.com>; Nicola Mazzucato <Nicola.Mazzucato@arm.com>; nd <nd@arm.com>
Subject: [EXT] Re: Order of starting Secure Partitions

CAUTION: This email is external. Do not click links or attachments that are unexpected or from unknown senders. If unsure, click the Report Phishing Button in Outlook.

Hi,

The partitions would have to have a list of dependencies, so if your partition requires something from the Crypto one, the Crypto must in the list of deps of your partition and it will be initialised first.

Having said that, I believe the PSA_ERROR_INSUFFICIENT_MEMORY is being returned at some point by the API as Mbed TLS underneath might try to allocate some memory on the static allocator. The allocator is a buffer that is statically allocated in the TF-M Crypto partition and you can control its size by changing CRYPTO_ENGINE_BUF_SIZE at build time, the default is in:

❯ cat config_engine_buf.h

/*

 * Copyright (c) 2023, Arm Limited. All rights reserved.

 *

 * SPDX-License-Identifier: BSD-3-Clause

 *

 */

#ifndef __CONFIG_ENGINE_BUF_H__

#define __CONFIG_ENGINE_BUF_H__

/*

 * CRYPTO_ENGINE_BUF_SIZE is decided by multiple components configs.

 * CRYPTO_ENGINE_BUF_SIZE can be overridden below by other component configs.

 * It must be guaranteed that this header file is included at last before CRYPTO_ENGINE_BUF_SIZE

 * is referred in crypto_library.c.

 * Otherwise, crypto_library.c may include an incorrect definition value.

 */

/* The CC312 needs at least 0x4000 of heap size to work properly */

#if defined(CRYPTO_HW_ACCELERATOR_CC312) && (CRYPTO_ENGINE_BUF_SIZE < 0x4000)

#pragma message("CRYPTO_ENGINE_BUF_SIZE is redefined to 0x4000.")

#undef  CRYPTO_ENGINE_BUF_SIZE

#define CRYPTO_ENGINE_BUF_SIZE                 0x4000

#endif

#endif /* __CONFIG_ENGINE_BUF_H__ */

Different TF-M profiles might override this size with smaller (or bigger) sizes.

Hope this helps.

Thanks,

Antonio

From: Nicola Mazzucato via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Monday, June 02, 2025 12:07
To: tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.org>; Florek, Bartlomiej <bartlomiej.florek@assaabloy.com>
Subject: [TF-M] Re: Order of starting Secure Partitions

Hi Bartlomiej,

I am not sure I understood exactly the sequence you need to perform in your case, but have you perhaps tried to use the 

"tfm_hal_post_partition_init_hook"?

In principle, you need to have the runtime initialization fully completed before you can require a secure service operation.

Does your new partition need some crypto operations to initialize itself correctly? Which crypto api have you used exactly?

Best regards,

Nicola

Hello,

I'm trying to fit a new Secure Partition into Trusted Firmware - M environment. The current working environment consists of Zephyr RTOS 3.7 + TF-M  2.1.0 running under QEMU on MPS2 AN521 platform. General skeleton is in place - manifest with dependencies on TFM_CRYPTO, interface, IPC and handling communication.

However, I have problems with using the PSA Crypto from the aforementioned new Service. I need a hash function, so I thought I'd use PSA Crypto API. The problem is that either the hash function or the initialization function (psa_crypto_init) is returning error (PSA_ERROR_INSUFFICIENT_MEMORY). I discovered that logs show PSA Crypto partition is loading after mine.

This problem occurs in the entry_point function.

Is it possible to change the order of partitions loading or is there different mechanism advised to synchronize partition loading?

Thank you in advance for your suggestions.

Best regards,