Hi Ross, following changes were merged which help building on Arm and integrating to Yocto. Let us know how it goes. Thanks.

Hi @yuezhiran, I believe it's valid for this function to return 0. The bl1_plat_handle_post_image_load function is overridable by the platform, but we do not provide a mechanism for the platform to communicate the "acceptable" image IDs to the caller. We cannot therefore return an error if we receive an image ID that has no post-load process, because it may be called for any image (the FWU process does this here).

Ok, thanks a lot.

Have you tried a more recent release? v2.6 is our latest tagged release or try tip of tree?

I am using Avenger96 and Buildroot and ran into similar issue.

Hi
As you mentioned, req_states will be NULL only if pwrlvl is not valid. However, in my opinion, many checks have been done earlier to the invocation of the function to make sure pwrlvl is valid. See lines 246 and 428 in lib/psci/psci_common.c file. Can you tell if you have noticed any issue in your platform with PSCI library?

Thanks a lot.

A code coverage solution has been developed and is being tested before being rolled out in the production CI.

Thanks for your reply. So is there any way to calculate the coverage of TF-A(functions or codes)?

Noted. OpenSSL 3 not yet supported.

To be added to arm-cortex-m.cfg:

manually cut compile_commands.json only for interface files:

This issue is related to platform hardware limitations. so close it.

It is related with psa arch test issue, so close it.

Has been fixed.

SSE-300 platform is deprecated now. So will close this issue currently.
However, AN547 maybe have same issue if AN547 is supported in PSA Arch test. Put a note here.

The fix has been merged. Close the issue.

FYI: @noonfom @Anton-TF

I found the bug causing both worlds scenario to randomly fail: is wrong handling of telnet connection with the model causing some message loss; a fix in on-going.
I'm also having a look to get the right telnet port number from the model.
Will update the ticket with the new developments.

Do you have a chance to know the context of when the secure fault is happening?

https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/12379

Tests: https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/11880
GCM driver: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/12275

Original refactoring patch (merged first, could not add the topic tag anymore): https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/12221