Hi all, I suggest we move this discussion back to the mailing list so we can track the progression a bit more easily.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Yesterday
Thu, Feb 25
Wed, Feb 24
Proposal sent in email to board and voted Yes. This has since been superceded by a fixed-size deve team. Can close this issue.
Tue, Feb 23
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.
Mon, Feb 22
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
Sun, Feb 21
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.
Fri, Feb 19
Vote: <Varun Wadekar> (<Tegra>): <disapprove>
Thu, Feb 18
Mon, Feb 15
Mon, Feb 8
Wed, Feb 3
Jan 28 2021
Jan 27 2021
Jan 26 2021
Jan 23 2021
Jan 18 2021
Jan 14 2021
Jan 8 2021
Jan 2 2021
Dec 31 2020
Dec 30 2020
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
Dec 24 2020
Dec 23 2020
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
Dec 22 2020
Confirm the issue is fixed.
Dec 21 2020
A patch to fix this issue: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7708
Dec 18 2020
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.
Dec 15 2020
Dec 14 2020
Dec 9 2020
Dec 8 2020
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
Dec 7 2020
Dec 4 2020
Dec 3 2020
Dec 2 2020
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.
Dec 1 2020
The ticket I created last month for Calendar on the website.
Can document a go or no-go decision here.
Nov 30 2020
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:
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 26 2020
The whole problem has boiled down to a flash write issue and it has been worked around by c32710c7fc8514dd0d072a01549e23a94278ee17.
Nov 25 2020
Verified with https://github.com/zephyrproject-rtos/zephyr/pull/30226
This issue is now fixed and can be closed