Thanks to the creator for writing the post, it was quite necessary for me and liked it. I wrote a note on the https://essaysservicesreviews.com/ about this. I will be happy if you read it and accept it. Thank you for your concern.
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.
Thu, Nov 19
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.
Wed, Nov 18
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.
Fri, Nov 6
Sep 27 2020
Aug 28 2020
Aug 27 2020
Aug 26 2020
Aug 12 2020
Aug 10 2020
Jul 22 2020
Jul 2 2020
Jun 26 2020
Jun 23 2020
Thanks for your comments and clarification. I should have updated this ticket with the information provided in the mail list, in order to keep them in sync.
Jun 19 2020
I noticed this as well, and I was on the verge of submitting a patch until I looked into it further and decided that the current default is justifiable.
Jun 3 2020
May 28 2020
May 11 2020
May 10 2020
Yes, you are right ID_AA64PFR0_EL1 must be used. Thanks for spotting this!
May 9 2020
Apr 18 2020
Mar 31 2020
OK. Regarding naming suggestions, I like func_noabi/endfunc_noabi the most. The reason why I am discounting asmfunc/endasmfunc is because a function implemented in assembly language might still respect the ABI.
I suggest we start with func_noabi/endfunc_noabi and continue the discussion on the patch on Gerrit. Unfortunately, this ticketing system does not have the same visibility as Gerrit or the mailing list and not everyone subscribe to these.
Mar 27 2020
Ok, In order to safe iterations.
I plan to suggest a new macro which does the followin
- creates a new section - as func does
- sets the alginment - as func does
- sets the type
- together with the counterpart end??? is sets the .size
. Proposals for names
- func_noabi/endfunc_noabi - a non-abi conformant function
- asmfunc/endasmfunc - a assembly routine/function
- sym/endsym - short, but the name does not imply that it actually creates a block of code/own section
Mar 25 2020
Current gerrit proposal to fix this can be found in https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3749 (and related preceding commits).