- User Since
- Apr 11 2018, 2:02 AM (151 w, 11 m)
Dec 30 2020
A hotfix is under review: https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/7753
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.
Dec 4 2020
Nov 5 2020
May 11 2020
May 7 2020
Apr 22 2020
Feb 18 2020
Feb 10 2020
I add @chrisb to take a look since he is the designer. :)
Jan 22 2020
Jan 21 2020
Jan 13 2020
Jan 10 2020
Patch is uploaded to https://review.trustedfirmware.org/c/trusted-firmware-m/+/3107.
The root cause is:
- When building SPRTL, arch type is fetched from GNUARM cmake file since SPRTL CMake file is included with add_subdirectory() instead of include().
- The CM0+ arch type should be "armv6s-m". However, it is set to "armv6-m" in GNUARM cmake file, which stands for CM0. CM0 doesn't support SVC. Thus the build failed.
- Previously, the psa_client.c and` psa_service.c` were not in SPRTL folder. When building the both files, cpu type is fetched which is correct.
Dec 23 2019
Dec 18 2019
https://review.trustedfirmware.org/q/topic:%22dualcpu-multi-client-call%22+(status:open%20OR%20status:merged) implement multiple calls feature.
https://review.trustedfirmware.org/q/topic:%22dualcpu-test-framework%22+(status:open%20OR%20status:merged) implement a test framework for dual-cpu to verify multiple calls feature.
Dec 17 2019
Dec 13 2019
The patch set is submit to https://review.trustedfirmware.org/q/topic:%22remove-deprecated-test%22+(status:open%20OR%20status:merged) for review.
Dec 12 2019
The change to CI scripts is merged.
Dec 11 2019
Patch set has been uploaded to https://review.trustedfirmware.org/q/topic:%22template_plat_files%22+(status:open%20OR%20status:merged) for review.
CI should be updated to remove the tracking of deprecated test cases, before the patch set is uploaded.
The patch to modify CI scripts is under review on https://review.trustedfirmware.org/c/ci/tf-m-ci-scripts/+/2745.
Dec 5 2019
Nov 18 2019
Nov 13 2019
Nov 8 2019
Oct 21 2019
Oct 9 2019
Sep 27 2019
Sep 26 2019
Sep 25 2019
Sep 24 2019
Sep 23 2019
Sep 20 2019
Yeah, we have been such a quick pace for a while. There are still some major PSoC 6 feature coming in next 2 weeks. So I guess there will be a more stable code base in mid-OCt.
Sep 19 2019
Hi Thomas, tfm-twin-cpu is a dedicated project tag for multi-core feature development with special schedule, task plan and target, which have been determined.
Please select other tags. Sorry for any inconvenience.
Sep 6 2019
Aug 20 2019
Changes to build environment after rebasing/merging
- master branch switches to use mbed-crypto *1.1.0* since https://review.trustedfirmware.org/c/trusted-firmware-m/+/1562. After rebasing/merging, mbed-crypto should be updated to 1.1.0 from 1.0.0.
- CMSIS 5.5
- master branch changes to use CMSIS 5.5 since https://review.trustedfirmware.org/c/trusted-firmware-m/+/1421.
- TF-M can co-work with both 5.2 and 5.5. But after the CMSIS is updated to 5.5, it is required to manually to fetch the CMSIS RTOS v2 binaries via git-lfs
Aug 19 2019
The conflicts in source code include but not limited to the following list
Aug 16 2019
Aug 12 2019
Aug 6 2019
Propose a patch https://review.trustedfirmware.org/c/trusted-firmware-m/+/1718 to split memory check process from other common secure APIs. Thus single Armv8-M and multi-core scenario can implement own process.
Jul 29 2019
Hi @KenLSoft, I'm doing the memory checking functionalities on feature-twincpu. Do you expect me to fix it on feature-twincpu and merge it back to master or directly on master branch?
Jul 24 2019
Jul 18 2019
Patch https://review.trustedfirmware.org/c/trusted-firmware-m/+/1588 from Alamy can fix the failure in tfm_sst_init() and some SST test cases.
Some regression SST test cases still fail. Need further debugging.
Jul 17 2019
Hi Alamy, I'm not sure I triggered the same issue as you did but I got the same error log. According to my debugging result, the regression was stuck because the tfm_sst_init() failed. As a result, signal value kept as 0x0 since it was not modified by any event. It means that signal == 0x0 is result of SST initialization failure, instead of the cause of abort as we previously met.