The build is good!

Above patch has been abandoned, as it is not important at the current stage.

A hotfix is under review: https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/7753

Verified that it passed the compiling & running tests, with the reverted patch.
Thank you for the quick response/fix~

Apparently, the patch didn't work for GCC. Sorry about that.
It has been reverted for the time being:
https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/7651

Confirm the issue is fixed.

A patch to fix this issue: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7708

Previously, memory access check was only performed in TF-M SPM. Therefore multi-core memory access check checks whether current execution is in Handler mode.
Memory access check is allowed only in Handler mode.

On a close look, the TFM_IPC_TEST_1007 seems to suggest a panic (reset).

/* The system should panic in psa_call. If runs here, the test fails. */
ret->val = TEST_FAILED;

However, after the reset, the system doesn't pass TFM_IPC_TEST_1007 and continue on to next test.
Instead, it starts over from the beginning (e.g.: PROTECTED_STORAGE test suite), and hence, in a infinite reset loop.

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

Hello,
Here are 2 commits to introduce the support of external flash for secondary slot
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7412
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7413

Hi,
A developer submitted a patch which closely relates to this issue. Please give your feedback here: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/7314

Don checking on LinkedIn options at Shebu's request. Looking to create a project that readers can subscribe to.

Agreed to move forward. I approved Kyle to merge the change. Also discussed with Joakim who is working out getting OP TEE public meetings into the calendar.

The ticket I created last month for Calendar on the website.
Can document a go or no-go decision here.

Hi,
Please use personal email and git configs/identity to push the patch to trustedfirmware.org. Few developers from the tf-a community have done this. Here is a link to contribution guidelines:

Thanks for your reply. It is difficult to submit code to community or Gerrit using company's account and system. So, I wonder whether it's permitted to upload by providing modifications or “git send-email” with patches.

The whole problem has boiled down to a flash write issue and it has been worked around by c32710c7fc8514dd0d072a01549e23a94278ee17.

Verified with https://github.com/zephyrproject-rtos/zephyr/pull/30226

This issue is now fixed and can be closed

Hi Li,

Hi,
Yeah, looks like such a large system with numerous clusters will run into an issue with the current limitation of "lock_index" being "unsigned char". Please go ahead and submit a patch for review:

Yes, The power domain topology of the system can be described as 8 sockets, each socket with 10 clusters and each cluster with 8 cores. We just consider a system like this might face the constraint mentioned above, and we must modify the declaration of lock_index to solve this problem. Feature, more and more interconnected system, with numerous cpus, might face the same problem.

Hi,
The struct "non_cpu_pwr_domain_node" represents a non-leaf power domain in an SoC such as a logical cluster. As you mentioned, the lock_index declaration with "unsigned char" limits such non-cpu power domains to 64. I believe it doesn't restrict the number of CPUs in a system to be <= 64. Do you currently face an issue with PSCI implementation due to the above constraint? Can you advise what is the power domain topology of your system? I think the lock_index can be expanded using "unsigned int" if needed.

Patch fixed and merged

Fixed by merge of https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6604