Cmake warnings when building on sdk2.6

[Cla]

When building with nordic sdk 2.6 and zephyr 3.5 we get the following cmake warnings. How should they be interpreted?

CMake Warning:
Manually-specified variables were not used by the project:

CRYPTO_KEY_DERIVATION_MODULE_ENABLED
CRYPTO_RNG_MODULE_ENABLED
ITS_NUM_ASSETS
MBEDTLS_PSA_CRYPTO_USER_CONFIG_FILE
PYTHON_PREFER

[Einar Thorsrud]

Hi,

The CMake warning is gerneric and basicaly means that (as far as CMake knows), the listed variables are not used / have no effect. Some of these configs are deprecated (like PYTHON_PREFER), so maybe you have an old project where you set these before and that has not been migrated?

If these are configs you set yourself (and that are unused), you can update your Kconfig fiels (like prj.conf). Some look like configs it is not likely you would set though, like MBEDTLS_PSA_CRYPTO_USER_CONFIG_FILE, which normally points to a user generated file.

I have not seen any other examples of this, so in order to be more specific I think we would need to know more about your project and configuration.

[Cla]

Hi Einar

Thanks for the quick response. We are mainly concerned about this as far as it could indicate a misconfiguration on our part. Basically we would like to confirm, that it is safe to ignore those warnings.

For example:

https://github.com/nrfconnect/sdk-nrf/blob/main/modules/trusted-firmware-m/CMakeLists.txt#L216 sets PYTHON_PREFER

-> but it is deprecated it seems

https://github.com/nrfconnect/sdk-nrf/blob/main/modules/trusted-firmware-m/CMakeLists.txt#L264 sets ITS_NUM_ASSETS

-> why is it ignored/unused? Are we sure, that CONFIG_ITS_NUM_ASSETS is used correctly or is the default used by accident?

Similarly with the other options...

[Einar Thorsrud]

Hi,

Cla said:

why is it ignored/unused?

I think we need to know more about your project and build files to say that, as I have not been able to reproduce it myself, nor found other reports of this. Ar you able to share details about that and perhaps your full build log?

Cla said:

Are we sure, that CONFIG_ITS_NUM_ASSETS is used correctly or is the default used by accident?

As I have not reproduced this I dear not say. (I am a bit suprised by the fererence to CONFIG_ITS_NUM_ASSETS and not CONFIG_TFM_ITS_NUM_ASSETS).

[Cla]

Einar Thorsrud said:

As I have not reproduced this I dear not say.

To reproduce use:

west.yml

manifest:
  remotes:
    - name: ncs
      url-base: https://github.com/nrfconnect
  projects:
    - name: nrf
      repo-path: sdk-nrf
      remote: ncs
      revision: v2.6.0
      import:
        name-allowlist:
          - mcuboot
          - nrfxlib
          - cmock
          - unity
          - mbedtls
          - qcbor
    - name: trusted-firmware-m
      repo-path: sdk-trusted-firmware-m
      remote: ncs
      revision: v2.0.0-ncs1
      path: modules/tee/tf-m/trusted-firmware-m
    - name: zephyr
      remote: ncs
      repo-path: sdk-zephyr
      path: zephyr
      revision: v3.5.99-ncs1
      import:
        name-allowlist:
          - TraceRecorderSource
          - canopennode
          - cmsis
          - edtt
          - fatfs
          - fff
          - hal_nordic
          - hal_st
          - libmetal
          - littlefs
          - loramac-node
          - lvgl
          - lz4
          - mcumgr
          - mipi-sys-t
          - nanopb
          - net-tools
          - nrf_hw_models
          - open-amp
          - openthread
          - segger
          - tinycbor
          - tinycrypt

CMakeLists.txt

cmake_minimum_required(VERSION 3.13.1)
find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE})
project(main)
target_sources(app PRIVATE main.c)

main.c

#include <zephyr/logging/log.h>
LOG_MODULE_REGISTER(test_log, 4);
int main() {
    LOG_INF("hello world");
    return 0;
}

prj.conf

CONFIG_LOG=y
CONFIG_ENTROPY_GENERATOR=y
CONFIG_BUILD_WITH_TFM=y
CONFIG_TFM_PROFILE_TYPE_LARGE=y
CONFIG_TFM_CRYPTO_RNG_MODULE_ENABLED=y
CONFIG_TFM_ITS_NUM_ASSETS=50
CONFIG_TFM_ITS_NUM_ASSETS_OVERRIDE=y

Can you reproduce it with above setup?

[Cla]

build using `west build -b nrf9160dk_nrf9160_ns`

[Einar Thorsrud]

Hi,

Thanks. I see the same on my end. We are working on cleaning this up (see this pull request), but the warnings can safely be ignored.