Hi all, I suggest we move this discussion back to the mailing list so we can track the progression a bit more easily.
Tue, Mar 30
Mar 15 2021
Feb 25 2021
Feb 23 2021
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.
Feb 22 2021
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:
Feb 21 2021
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.
Feb 19 2021
Vote: <Varun Wadekar> (<Tegra>): <disapprove>
Dec 2 2020
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
Nov 30 2020
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:
Nov 28 2020
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.
Nov 19 2020
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.
Nov 18 2020
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.
Nov 6 2020
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).
I can try end of the week. Thanks.
Mar 20 2020
Corrected with the following commit that has just been merged:
Mar 19 2020
This makes sense to me. Would you mind preparing a patch that removes the func macro on el3_exit and post it on review.trustedfirmware.org ?
Mar 17 2020
I took the patch and put it into gerrit. Due to a lack of name or email address I used mine. Happy to change that once I learn about the real identity of "armlabs".
Mar 12 2020
Hi Andrew, yes the change looks fine.
If this generally looks okay I'm happy to follow https://developer.trustedfirmware.org/w/tf_a/gerrit-getting-started/ and push this for review according to the TF-A workflow.
Again, this is for now staged via Pete's tree and you can view the pull request here - https://github.com/pbatard/arm-trusted-firmware/pull/2
Mar 6 2020
This has been fixed in https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2789.
Mar 3 2020
Mar 2 2020
Feb 24 2020
I will send the patches shortly
Feb 15 2020
Feb 5 2020
Feb 1 2020
Hi sunxi h6,
Jan 29 2020
Jan 21 2020
Jan 14 2020
Nerver mind :) Glad if it works now. Cheers, Olivier.
Closing the issue as the RSA Key size support has now been merged.
The TF-A now has support for RSA-3K in Cryptocell variant.
I am sorry guys.
I need to apologize to all who have helped me with this issue.
Cryptocell key sizes are different. You have different key sizes and i have different, Here we need to move on because all these are different and if you just not share it with a perfect essayhave project then move and start to find something else.
Jan 13 2020
The log seems to show additional options versus the regular TF-A build:
-march=armv8-a -O2 -pipe -fstack-protector-strong -fno-plt
Jan 10 2020
Okay, here's the log.
Jan 9 2020
I installed manjaro-arm on an rpi3 and cloned TF-A commit 0348ee49135c