I will run the GCC version later to check if there are more warnings. Will collect all the warnings and fix them in one shot later.

Makes sense :)
Here is the GCC version output:

$arm-zephyr-eabi-gcc --version
arm-zephyr-eabi-gcc (crosstool-NG 1.24.0.212_d7da3a9) 10.2.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

It looks like your compiler is bit more stricter than mine :)
It won't take too much to effort to fix those warnings I guess.

Can you share the Compiler information please?

Hi Martin, this *dual-cpu* design is dedicated for the platforms which consist of a non-secure core and a secure core. The secure core is protected from the non-secure core by system physical isolation. PSoC 64 is an example port of this *dual-cpu* implementation.

Don't know where to ask this, current TF-M design allows only for one secure cpu and one non-secure?
Why not have SPE and NSPE on both cores, as would be possible on mps2/an521 e.g. (dual M-33 with TrustZone). Could TF-M be modified to allow for such a behavior in the current version?
Thankful for any answers!

Improved by https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9451

Great suggestion. Will add one in build configuration check soon.

I see. It would be good to have an error message in that case.

Profile Medium selects IPC model by default. TF-M IPC model disables audit log service since audit log doesn't implement IPC model interface yet.
Please see: https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/config/tfm_ipc_config_default.cmake

TF-M audit log service doesn't implement IPC model interface. Therefore it is not enabled by default in IPC model.
IPC model default configuration disables TF-M audit log. Please see: https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/config/tfm_ipc_config_default.cmake

Hi Olivier,

Raghu as you are originator for this ask; can you state more about the requirements as to the why we'd really need to do so?

Fix is merged to integration and master. (https://git.trustedfirmware.org/TS/trusted-services.git/commit/?h=refs/heads/main&id=840696b9ac1ba6aa9ccd024ca9dc3b4be12bf837)

Submitted for review at https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/9431

With a recent version of QEMU (i.e. 4.x), it should be enough just to use this to run TF-M on QEMU for AN521:

Fix is on review here: https://review.trustedfirmware.org/c/TS/trusted-services/+/9379

The fix is merged: https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/8178

That's not currently supported.

I think it would be reasonable if Hafnium implements this feature when there is an explicit request for it from a Trusted OS or SP vendor. In the meantime, Hafnium returning INVALID_PARAMETERS sounds like a reasonable approach to me. It implies that the ACK test can be ignored. What do you reckon?

FWIW, agree with Olivier's analysis.

That's a very interesting definition of reproducible.

Blocked by https://developer.trustedfirmware.org/T901

After the initial investigation I found two possible approaches to the task:

Yes, we include a prebuilt toolchain so that the builds are reproducible. It's a copy of the Android prebuilt toolchain (from https://android.googlesource.com/platform/prebuilts/clang/host/linux-x86/), which I'm afraid doesn't seem to include aarch64 binaries at the moment.

In particular this is about specifying the offset field in the endpoint memory access descriptor.

The possible envisioned scenario is related to booting TF-A+UEFI and support for authenticated variables.

Revert patch:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9142

Workaround from CI to skip the Clang + FF + Debug for Musca B1:
https://review.trustedfirmware.org/c/ci/tf-m-ci-scripts/+/9286

Fix merged as daf2efdaa78.

For more context see https://review.trustedfirmware.org/c/TS/trusted-services/+/8310/comment/5e4373b3_998e475f/

Fix is available here: https://review.trustedfirmware.org/c/TS/trusted-services/+/9046

This was introduced by change: d80f856adf59.
That change makes deployments targeting the "arm-linux" environment accept non Linux specific GCC binaries like "aarch64-none-elf-gcc". Since these GCC builds are not bundled with a standard library built with Linux support, compilation errors arise due to missing Linux kernel headers.