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.

Test results:
FPGA:

Hi all, I suggest we move this discussion back to the mailing list so we can track the progression a bit more easily.

Proposal sent in email to board and voted Yes. This has since been superceded by a fixed-size deve team. Can close this issue.

Vote: Jens Wiklander (qemu and OP-TEE Dispatcher): disapprove
I too have concerns with adding more tags to the the subject of the commit message.

We have had some contact with some other TF.org projects but was not aware of the Mbed TLS project had its own solution already. Its already acknowledged we should to look for a common solution across projects. This discussion is part of that engaging. We do need to make a decision at some point.

Hi, I agree with @danh-arm. We should try to come up with a unified guidance, if possible. I think we will have a better idea of the path forward, once most of the maintainers respond. Personally, I would be open to merging both approaches to get the best of both worlds.

I think tags in the subject of the commit message are problematic in general. Since commits are expected to capture "logical unit of change", the granularity of tags and commit scope often mismatches. While not mandated in the "Contributors Guide" sections, some commits indeed use tags already (i.e. libc, spmd, docs, etc..). What if a "logical unit of change" affects multiple components (i.e. a fix affects both libc and spmd)?

Hi, I just want to make you aware that the Mbed TLS project has a different, home-rolled solution to this problem:
https://github.com/ARMmbed/mbedtls/blob/development/ChangeLog.d/00README.md

Yes, I have found that 50 chars is not enough to describe commits many times. Adding a tag would mean sacrificing space. But I am open to adding this tag to the commit message instead of the header. We already plan to add tags to the message anyways?

I think this is generally a good move. The transition period will be ugly and unavoidable but we should reap the benefits of it long term. I do agree with Varun's concern about using tags in the headers but it is a trade-off we will have to make for the benefits standard commits offers.
Varun, is the format <conventional commit tag>:<plat> or <submodule>:<short message> not sufficient? I dont think we want to pack too much into the header any way in terms of what the commit is doing.

Vote: <Varun Wadekar> (<Tegra>): <disapprove>

https://review.trustedfirmware.org/c/hafnium/hafnium/+/8243