Hi All,
The next release of the Firmware-A bundle of projects tagged v2.12 has an expected code freeze date of Nov, 8th 2024.
Refer to the release cadence section from TF-A documentation (https://trustedfirmware-a.readthedocs.io/en/latest/about/release-informatio…).
Closing out the release takes around 6-10 working days after the code freeze.
v2.12 release preparation tasks start from now.
We want to ensure that planned feature patches for the release are submitted in good time for the review process to conclude.
As a kind recommendation and a matter of sharing CI resources, please launch CI jobs with care e.g.:
-For simple platform, docs changes, or one liners, use Allow-CI+1 label (no need for a full Allow-CI+2 run).
-For large patch stacks use Allow-CI+2 at top of the patch stack (and if required few individual Allow+CI+1 labels in the middle of the patch stack).
-Carefully analyze results and fix the change if required, before launching new jobs on the same change.
-If after issuing a Allow-CI+1 or Allow-CI+2 label a Build start notice is not added as a gerrit comment on the patch right away please be patient as under heavy load CI jobs can be queued and in extreme conditions it can be over an hour before the Build start notice is issued. Issuing another Allow-CI+1 or Allow-CI+2 label will just result in an additional job being queued.
--
Thanks,
Govindraj R
Hi All,
The next release of the Firmware-A bundle of projects tagged v2.13 has an expected code freeze date of May, 2nd 2025.
In order to accommodate the Linaro connect event occurring during the week of May 12th we may extend the release completion date up until the week of May 26th.
v2.13 release preparation tasks start from now.
We want to ensure that planned feature patches for the release are submitted in good time for the review process to conclude.
As a kind recommendation and a matter of sharing CI resources, please launch CI jobs with care e.g.:
-For simple platform, docs changes, or one liners, use Allow-CI+1 label (no need for a full Allow-CI+2 run).
-For large patch stacks use Allow-CI+2 at top of the patch stack (and if required few individual Allow+CI+1 labels in the middle of the patch stack).
-Carefully analyze results and fix the change if required, before launching new jobs on the same change.
-If after issuing a Allow-CI+1 or Allow-CI+2 label a Build start notice is not added as a gerrit comment on the patch right away please be patient as under heavy load CI jobs can be queued and in extreme conditions it can be over an hour before the Build start notice is issued. Issuing another Allow-CI+1 or Allow-CI+2 label will just result in an additional job being queued.
Regards,
Olivier.
Hi All,
We are pleased to announce the formal release of Trusted Firmware-A version 2.13 bundle of project deliverables.
This includes Trusted Firmware-A, Trusted Firmware-A Tests, Hafnium, TF-RMM, Trusted Services, and TF-A OpenCI scripts/jobs components.
These went live on May, 22nd 2025.
Please find references to tags and change logs at the end of this email.
Many thanks to the trustedfirmware.org community for the active engagement in delivering this release!
Notable features of the release version 2.13 are as follows:
TF-A/EL3
* Alto CPU support
*
Architecture feature support for PMUv3p9. PAUTH_LR and SPE_FDS.
* Refactor PSCI to let each CPU core initialise its own context, allowing TF-A to natively handle asymmetric configurations
*
PSCI Powerdown abandon feature support
*
SMCCC_FEATURE_AVAILABILITY support based on SMCCC v1.5 specification
* Firmware Handoff
* Library enhancements to add more TE types in library
* All BL interfaces for FVP are now migrated to use Transfer List along in different boot scenarios (RESET_TO_BL1/BL2/BL31)
*
TC platform is now using Transfer List for booting
* HOB creation Library (from edk2) is now hosted in TF-A
* New Platforms: mt8189, mt8196, qcs615, RK3576, AM62L
Boot flow
* Feature Additions
* Added discrete TPM support in BL1/BL2 for the RPi3 platform.
*
Support for MbedTLS PSA Crypto with ROMLIB on FVP.
*
Redesigned PSA Crypto Key ID management to avoid repeated key creation/destruction.
*
Test Additions
*
Support for MbedTLS PSA Crypto with ROMLIB on FVP.
*
Added basic boot test for TF-RMM with TF-A and TFTF (Realm Payload) in Jenkins CI.
*
Integrated DRTM ACS test suite into TF-A Jenkins CI.
*
Added missing test configuration for ROTPK in register on FVP platform.
*
Build System
*
Refactored ROTPK key/hash generation to auto-generate required files during build.
*
mbedTLS Improvements
*
Migrated to mbedTLS version 3.6.3.
Errata/Security mitigations (CPU/GIC)
*
CVE-2024-5660, CVE-2024-7881
* Cortex-A510, Cortex-A715, Cortex-X4, Cortex-X925, Neoverse V3
Hafnium/SPM (S-EL2)
* FF-A v1.2 completed: indirect messaging with service UUIDs.
* FF-A v1.3 early adoption: Update to FFA_MEM_PERM_GET ABIs.
* StMM integration: provide HOB structure as boot information.
* Power management update:
* Bootstrapped secondary vCPUs on secondary cores power on flows.
* SP's subscription to the power off event.
* SP loading: SP artefacts can be bundled in a TL format. I.e SP binary and SP manifest (DTB).
* Resuming ECs for interrupt handling assisted by NWd Scheduler when the SP is in waiting state, with sri-interrupts-policy field in the SP manifest.
TF-RMM (R-EL2)
* Deprivileging RMM code via EL0 App support
*
Added some support for some RMMv1.1 APIs - "RMI_DEV_MEM_(UN)MAP", support for device granules in "RMI_GRANULE_DELEGATE" and "RMI_GRANULE_UNDELEGATE".
*
Additional hardening of RMM via compiler flags `-fstack-protector-strong`, '-Wextra', '-Wstrict-overflow', '-D_FORTIFY_SOURCE=2' and '-Wnull-dereference'.
*
New platform support for RD-V3-R1 and RD-V3-R1-Cfg1 FVPs.
*
Dynamic discovery of PCIE Root complex topology and device memory from the Boot manifest.
Trusted Services (v1.2.0)
* Introduced the fTPM SP. The implementation is experimental.
*
Introduce the new Arm Reference Design-1 AE platform targeting the Automotive segment. It features
high-performance Arm Neoverse V3AE Application Processor compute system, Arm Cortex-R82AE based Safety Island, and
a Runtime Security Engine (RSE) for enhanced security.
*
Updated the se-proxy deployment and added support for the Firmware Update Proxy service. The FWU Proxy implements a Platform Security Firmware Update for the A-profile Arm Architecture<https://developer.arm.com/documentation/den0118/latest/> compliant FWU Agent which runs a PSA Certified Firmware Update API 1.0<https://arm-software.github.io/psa-api/fwu/1.0/> compliant client as its backend.
TF-A Tests
* Enhancements to fuzzing tests (EL3 vendor specific SMC, SDEI, FF-A interface, capability for randomized fuzzing inputs)
* Functionality test
* Firmware Handoff : AArch32 tests and event log testing
* SMCCC_ARCH_FEATURE_AVAILABILITY
* RAS system registers, FPMR, SCTLR2, THE and D128
* validate psci_is_last_cpu_to_idle_at_pwrlvl
* SPM/FF-A : HOB generation, PPI timer interrupts, v1.2 RXTX headers
* RMM: Tests introduced for majority of features developed in RMM
* Platform Support
* Versal NET
* Versal
* Neoverse-RD
Release tags across repositories:
https://git.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/+/r…https://git.trustedfirmware.org/plugins/gitiles/TF-A/tf-a-tests/+/refs/tags…https://git.trustedfirmware.org/plugins/gitiles/ci/tf-a-ci-scripts/+/refs/t…https://git.trustedfirmware.org/plugins/gitiles/ci/tf-a-job-configs/+/refs/…https://git.trustedfirmware.org/plugins/gitiles/hafnium/hafnium.git/+/refs/…https://git.trustedfirmware.org/plugins/gitiles/ci/hafnium-ci-scripts/+/ref…https://git.trustedfirmware.org/plugins/gitiles/ci/hafnium-job-configs/+/re…https://git.trustedfirmware.org/plugins/gitiles/TF-RMM/tf-rmm/+/refs/tags/t…https://git.trustedfirmware.org/plugins/gitiles/TS/trusted-services/+/refs/…
Change logs:
https://trustedfirmware-a.readthedocs.io/en/v2.13.0/change-log.html#id1https://trustedfirmware-a-tests.readthedocs.io/en/v2.13.0/change-log.html#v…https://hafnium.readthedocs.io/en/v2.13.0/change-log.html#v2-13https://tf-rmm.readthedocs.io/en/latest/about/change-log.html#v0-7-0https://trusted-services.readthedocs.io/en/stable/project/change-log.html#v…
Regards,
Olivier.
Hi Maheedhar,
Previously, the RXPX check was still being performed, but its result was simply ignored. This patch changes that behavior by enforcing failures when the check doesn't pass.
There are two scenarios where the RXPX check is applied: one under EM_NOT_AFFECTED and the other under EM_HIGHER_EL_MITIGATION.
*
In the EM_NOT_AFFECTED case, the CPU revision should fall outside the erratum’s affected range.
*
In the EM_HIGHER_EL_MITIGATION case, where mitigation has been applied at a higher exception level, the CPU revision should be within the affected range.
The RXPX check validates both of these expectations. If it fails in either case, it typically indicates a mismatch between the ABI test case and the actual errata check logic.
If a CPU revision falls outside the test case range but is categorized under EM_HIGHER_EL_MITIGATION, that should be treated as a failure.
If you're seeing a situation that doesn't align with these conditions and could share some more info—I'd be happy to take a look,
Regards,
Arvind
Bollapalli, Maheedhar Sai wrote:
> [AMD Official Use Only - AMD Internal Distribution Only]
> Hi TF-A-Tests team,
> We are observing EM-ABI tests failures with latest Tf-a-tests upstream code where-in CPU revision is retrieved and RXPX range is compared based on the errata list per
> CPU core and if the CPU revision is outside of the errata revision range test case is deemed as failure, which doesn't seem to be appropriate.
> Patch change that marked RXPX out of range as failure.
> Change that marks range check as test failure:
> https://review.trustedfirmware.org/plugins/gitiles/TF-A/tf-a-tests/+/refs/he...
> Patch: https://review.trustedfirmware.org/plugins/gitiles/TF-A/tf-a-tests/+/5668f34...
> Regards,
> Maheedhar.
[AMD Official Use Only - AMD Internal Distribution Only]
Hi TF-A-Tests team,
We are observing EM-ABI tests failures with latest Tf-a-tests upstream code where-in CPU revision is retrieved and RXPX range is compared based on the errata list per
CPU core and if the CPU revision is outside of the errata revision range test case is deemed as failure, which doesn't seem to be appropriate.
Patch change that marked RXPX out of range as failure.
Change that marks range check as test failure:
https://review.trustedfirmware.org/plugins/gitiles/TF-A/tf-a-tests/+/refs/h…
Patch: https://review.trustedfirmware.org/plugins/gitiles/TF-A/tf-a-tests/+/5668f3…
Regards,
Maheedhar.
Hi Tf-a-tests team,
We have a query regarding TF-A test especially hot-plug request on a CPU with invalid entry-point address, where zero is passed as invalid address. Could you please let us know why address 0x0 is invalid address here ? Please refer to below code path for reference.
https://review.trustedfirmware.org/plugins/gitiles/TF-A/tf-a-tests/+/refs/h…
Regards,
Maheedhar.
Hi Amit,
https://ci.trustedfirmware.org/view/TF-A/job/tf-a-ci-coverage-gateway/ is the Jenkins Coverage job run weekly and Mark Dykes can provide you with pointers to the scripts etc that are used in this job and the jenkins job source as well as he authored most of this job and hopefully can provide guidance on how to run locally.
ATM only boot and TF-A Test runs are used to generate these numbers as mentioned below. As mentioned we have very limited set of cpputest based unit tests and I don’t believe they are integrated into the Code Coverage system and even if they were don’t expect them to have a big impact on the Code Coverage numbers.
Joanna
From: Nagal, Amit <amit.nagal(a)amd.com>
Date: Tuesday, 17 December 2024 at 07:20
To: Joanna Farley <Joanna.Farley(a)arm.com>, Gyorgy Szing <Gyorgy.Szing(a)arm.com>, Mark Dykes <Mark.Dykes(a)arm.com>, Thangaraj, Senthil Nathan <SenthilNathan.Thangaraj(a)amd.com>, Olivier Deprez <Olivier.Deprez(a)arm.com>, tf-a-tests(a)lists.trustedfirmware.org <tf-a-tests(a)lists.trustedfirmware.org>, tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>
Cc: Jain, Ronak <ronak.jain(a)amd.com>, Simek, Michal <michal.simek(a)amd.com>
Subject: RE: Query regarding the test coverage thru tf-a-tests
Hi Joana,
Thanks for information .
Additionally, do we have any documentation detailing all the build/run flows to generate coverage report based on whatever cpputest based unit tests are implemented today
for TF-A at https://review.trustedfirmware.org/plugins/gitiles/TF-A/tf-a-unit-tests/+/r… .
and whether these build/run flows is available for public usage.
Regards
Amit
From: Joanna Farley <Joanna.Farley(a)arm.com>
Sent: Monday, December 16, 2024 4:57 PM
To: Nagal, Amit <amit.nagal(a)amd.com>; Gyorgy Szing <Gyorgy.Szing(a)arm.com>; Mark Dykes <Mark.Dykes(a)arm.com>; Thangaraj, Senthil Nathan <SenthilNathan.Thangaraj(a)amd.com>; Olivier Deprez <Olivier.Deprez(a)arm.com>; tf-a-tests(a)lists.trustedfirmware.org; tf-a(a)lists.trustedfirmware.org
Cc: Jain, Ronak <ronak.jain(a)amd.com>; Simek, Michal <michal.simek(a)amd.com>
Subject: Re: Query regarding the test coverage thru tf-a-tests
Hi Amit,
Code Coverage is only available on the FVP platform as the FVP model has capabilities that allow us with a FVP plug-in to gather debug information that allow us to calculate code coverage numbers. This is why there are no physical platform code coverage figures.
Basically anything run on the model we can gather code coverage figures for (booting, testing etc). The numbers referenced in the link are generated primarily from the TF-A Tests https://trustedfirmware-a-tests.readthedocs.io/en/latest/index.html which are more functional tests rather than formal Unit tests. TF-A has some unit tests but they are minimal at this time. The TF-A Tests framework in many ways covers many of the test criteria Unit tests can cover although are more positive test focused.
TF-A Tests can and has been ported to a few physical platforms but getting code coverage numbers you would need to develop a code coverage solution for your hardware platform.
The Code Coverage solution Arm have produced for FVP’s is described here https://www.trustedfirmware.org/docs/TracebasedCodeCoverageTooling.pdf its feasible to extend this to a physical platform but its not been explored by the authors of this tooling which is available here https://gitlab.arm.com/tooling/qa-tools/-/tree/master/coverage-tool
Hope this helps.
Joanna
From: Nagal, Amit <amit.nagal(a)amd.com<mailto:amit.nagal@amd.com>>
Date: Monday, 16 December 2024 at 09:02
To: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>>, Mark Dykes <Mark.Dykes(a)arm.com<mailto:Mark.Dykes@arm.com>>, Thangaraj, Senthil Nathan <SenthilNathan.Thangaraj(a)amd.com<mailto:SenthilNathan.Thangaraj@amd.com>>, Olivier Deprez <Olivier.Deprez(a)arm.com<mailto:Olivier.Deprez@arm.com>>, tf-a-tests(a)lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org> <tf-a-tests(a)lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org>>, Joanna Farley <Joanna.Farley(a)arm.com<mailto:Joanna.Farley@arm.com>>, tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>>
Cc: Jain, Ronak <ronak.jain(a)amd.com<mailto:ronak.jain@amd.com>>, Simek, Michal <michal.simek(a)amd.com<mailto:michal.simek@amd.com>>
Subject: RE: Query regarding the test coverage thru tf-a-tests
Hi ,
I am referring to the code coverage as below :
https://ci-builds.trustedfirmware.org/static-files/htxSEy4sEOQXtuGetFtzHqAm…
I see a lot of files from non plat code getting covered with code coverage .
can somebody help me with further information :
1. Where are cputests related unit test scripts hosted for non plat files like bl31_main.c ?
2. can we use the unit test & code coverage infra for other platforms say AMD-Xilinx?
3. How is the code coverage achieved for assembly .S files like bl31_entrypoint.S ?
Regards
Amit
From: Nagal, Amit
Sent: Wednesday, December 11, 2024 1:23 PM
To: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>>; Mark Dykes <Mark.Dykes(a)arm.com<mailto:Mark.Dykes@arm.com>>; Thangaraj, Senthil Nathan <SenthilNathan.Thangaraj(a)amd.com<mailto:SenthilNathan.Thangaraj@amd.com>>; Olivier Deprez <Olivier.Deprez(a)arm.com<mailto:Olivier.Deprez@arm.com>>; tf-a-tests(a)lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org>; Joanna Farley <Joanna.Farley(a)arm.com<mailto:Joanna.Farley@arm.com>>
Cc: Jain, Ronak <ronak.jain(a)amd.com<mailto:ronak.jain@amd.com>>; Simek, Michal <michal.simek(a)amd.com<mailto:michal.simek@amd.com>>
Subject: RE: Query regarding the test coverage thru tf-a-tests
Hi Everyone,
I see very limited number of unit tests cpp files hosted at https://git.trustedfirmware.org/plugins/gitiles/TF-A/tf-a-unit-tests/+/refs…
Do we have more unit tests implemented for TF-A and available publicly anywhere ?
Regards
Amit
From: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>>
Sent: Wednesday, November 20, 2024 2:44 PM
To: Nagal, Amit <amit.nagal(a)amd.com<mailto:amit.nagal@amd.com>>; Mark Dykes <Mark.Dykes(a)arm.com<mailto:Mark.Dykes@arm.com>>; Thangaraj, Senthil Nathan <SenthilNathan.Thangaraj(a)amd.com<mailto:SenthilNathan.Thangaraj@amd.com>>; Olivier Deprez <Olivier.Deprez(a)arm.com<mailto:Olivier.Deprez@arm.com>>; tf-a-tests(a)lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org>; Joanna Farley <Joanna.Farley(a)arm.com<mailto:Joanna.Farley@arm.com>>
Cc: Jain, Ronak <ronak.jain(a)amd.com<mailto:ronak.jain@amd.com>>; Simek, Michal <michal.simek(a)amd.com<mailto:michal.simek@amd.com>>
Subject: Re: Query regarding the test coverage thru tf-a-tests
Hi Amit,
“can this be utilized to perform unit testing for platforms other than fvp”
Unit-tests executables are running on the “build host” which often is the X86 based PC of the developer (or a CI worker). UT is favoring low cost and sacrificing some level of test correctness. It assumes the compiled C code is fully portable and works the same on all platforms. Moreover, it focuses on C function correctness, and checks if a specific function works as designed. Verifying higher level operation is out of scope (e.g. function implements any feature correctly or is behaving correctly when called by other functions in the system). In turn the complexity of embedded development is removed (managing the target, updating the firmware, using a JTAG interface for debugging, etc…), and the resource constraints of the embedded target is not present.
The code coverage executed on the fvp platform is a system test, it exercises the product on an emulated target. It verifies the correctness of the code as it executes like it will in a real-world scenario. This is a higher value test, but it is much more expensive in terms of time and complexity than UT.
“Is c-picker tool available inside arm still as of now ?”
No, it is public, although it is a bit hidden. It lives on the c-picker branch to the Trusted Services repository (see [1) Similarly, Firmware Test Builder lives on the fwtb branch (see 2).
This branch is independent of TS code and contains only the two tools. We have plans to move each to dedicated repositories, but I don’t know when I will have the time to do this.
(FWTB and c-picker was developed by my team (TS) and is used and maintained by both projects. Before the TS project was started, we were working on TF-A. I can help with the tools, but I am not familiar to TF-A specifics like, how the tools are integrated to TF-A or which parts of TF-A are covered by UT cases.)
1: https://review.trustedfirmware.org/plugins/gitiles/TS/trusted-services/+/re…
2: https://review.trustedfirmware.org/plugins/gitiles/TS/trusted-services/+/re…
/George
On 2024-11-20, 06:05, "Nagal, Amit via TF-A-Tests" <tf-a-tests(a)lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org>> wrote:
Hi Mark,
From unit test prospective , I saw this document https://www.trustedfirmware.org/docs/TF-A-UnitLevelTesting.pdf.
can this be utilized to perform unit testing for platforms other than fvp ?
Is c-picker tool available inside arm still as of now ?
Regards
Amit
From: Mark Dykes <Mark.Dykes(a)arm.com<mailto:Mark.Dykes@arm.com>>
Sent: Tuesday, October 29, 2024 9:20 PM
To: Nagal, Amit <amit.nagal(a)amd.com<mailto:amit.nagal@amd.com>>; Thangaraj, Senthil Nathan <SenthilNathan.Thangaraj(a)amd.com<mailto:SenthilNathan.Thangaraj@amd.com>>; Olivier Deprez <Olivier.Deprez(a)arm.com<mailto:Olivier.Deprez@arm.com>>; tf-a-tests(a)lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org>; Joanna Farley <Joanna.Farley(a)arm.com<mailto:Joanna.Farley@arm.com>>
Cc: Jain, Ronak <ronak.jain(a)amd.com<mailto:ronak.jain@amd.com>>; Simek, Michal <michal.simek(a)amd.com<mailto:michal.simek@amd.com>>
Subject: Re: Query regarding the test coverage thru tf-a-tests
Amit,
It appears I was incorrect in getting coverage outside of the flows we have internally. I apologize for the confusion...
Mark
________________________________
From: Nagal, Amit <amit.nagal(a)amd.com<mailto:amit.nagal@amd.com<mailto:amit.nagal@amd.com%3cmailto:amit.nagal@amd.com>>>
Sent: Friday, October 25, 2024 12:07 AM
To: Thangaraj, Senthil Nathan <SenthilNathan.Thangaraj(a)amd.com<mailto:SenthilNathan.Thangaraj@amd.com<mailto:SenthilNathan.Thangaraj@amd.com%3cmailto:SenthilNathan.Thangaraj@amd.com>>>; Mark Dykes <Mark.Dykes(a)arm.com<mailto:Mark.Dykes@arm.com<mailto:Mark.Dykes@arm.com%3cmailto:Mark.Dykes@arm.com>>>; Olivier Deprez <Olivier.Deprez(a)arm.com<mailto:Olivier.Deprez@arm.com<mailto:Olivier.Deprez@arm.com%3cmailto:Olivier.Deprez@arm.com>>>; tf-a-tests(a)lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org%3cmailto:tf-a-tests@lists.trustedfirmware.org>> <tf-a-tests(a)lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org%3cmailto:tf-a-tests@lists.trustedfirmware.org>>>; Joanna Farley <Joanna.Farley(a)arm.com<mailto:Joanna.Farley@arm.com<mailto:Joanna.Farley@arm.com%3cmailto:Joanna.Farley@arm.com>>>
Cc: Jain, Ronak <ronak.jain(a)amd.com<mailto:ronak.jain@amd.com<mailto:ronak.jain@amd.com%3cmailto:ronak.jain@amd.com>>>; Simek, Michal <michal.simek(a)amd.com<mailto:michal.simek@amd.com<mailto:michal.simek@amd.com%3cmailto:michal.simek@amd.com>>>
Subject: RE: Query regarding the test coverage thru tf-a-tests
Hi @Mark Dykes<mailto:Mark.Dykes@arm.com> ,
Can you please share insights about how to get coverage information using manual tests run for FVP platform .
That will help us to atleast get the coverage information for non platform code ( we are interested for bl31) .
Regards
Amit
Hi Mark,
From unit test prospective , I saw this document https://www.trustedfirmware.org/docs/TF-A-UnitLevelTesting.pdf.
can this be utilized to perform unit testing for platforms other than fvp ?
Is c-picker tool available inside arm still as of now ?
Regards
Amit
From: Mark Dykes <Mark.Dykes(a)arm.com>
Sent: Tuesday, October 29, 2024 9:20 PM
To: Nagal, Amit <amit.nagal(a)amd.com>; Thangaraj, Senthil Nathan <SenthilNathan.Thangaraj(a)amd.com>; Olivier Deprez <Olivier.Deprez(a)arm.com>; tf-a-tests(a)lists.trustedfirmware.org; Joanna Farley <Joanna.Farley(a)arm.com>
Cc: Jain, Ronak <ronak.jain(a)amd.com>; Simek, Michal <michal.simek(a)amd.com>
Subject: Re: Query regarding the test coverage thru tf-a-tests
Amit,
It appears I was incorrect in getting coverage outside of the flows we have internally. I apologize for the confusion...
Mark
________________________________
From: Nagal, Amit <amit.nagal(a)amd.com<mailto:amit.nagal@amd.com>>
Sent: Friday, October 25, 2024 12:07 AM
To: Thangaraj, Senthil Nathan <SenthilNathan.Thangaraj(a)amd.com<mailto:SenthilNathan.Thangaraj@amd.com>>; Mark Dykes <Mark.Dykes(a)arm.com<mailto:Mark.Dykes@arm.com>>; Olivier Deprez <Olivier.Deprez(a)arm.com<mailto:Olivier.Deprez@arm.com>>; tf-a-tests(a)lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org> <tf-a-tests(a)lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org>>; Joanna Farley <Joanna.Farley(a)arm.com<mailto:Joanna.Farley@arm.com>>
Cc: Jain, Ronak <ronak.jain(a)amd.com<mailto:ronak.jain@amd.com>>; Simek, Michal <michal.simek(a)amd.com<mailto:michal.simek@amd.com>>
Subject: RE: Query regarding the test coverage thru tf-a-tests
Hi @Mark Dykes<mailto:Mark.Dykes@arm.com> ,
Can you please share insights about how to get coverage information using manual tests run for FVP platform .
That will help us to atleast get the coverage information for non platform code ( we are interested for bl31) .
Regards
Amit
From: Thangaraj, Senthil Nathan <SenthilNathan.Thangaraj(a)amd.com<mailto:SenthilNathan.Thangaraj@amd.com>>
Sent: Tuesday, September 10, 2024 12:23 AM
To: Mark Dykes <Mark.Dykes(a)arm.com<mailto:Mark.Dykes@arm.com>>; Olivier Deprez <Olivier.Deprez(a)arm.com<mailto:Olivier.Deprez@arm.com>>; tf-a-tests(a)lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org>; joanna.farley(a)arm.com<mailto:joanna.farley@arm.com>
Cc: Jain, Ronak <ronak.jain(a)amd.com<mailto:ronak.jain@amd.com>>; Nagal, Amit <amit.nagal(a)amd.com<mailto:amit.nagal@amd.com>>; Simek, Michal <michal.simek(a)amd.com<mailto:michal.simek@amd.com>>
Subject: RE: Query regarding the test coverage thru tf-a-tests
Thank you Joanna and Mark, for your insights and response.
I wasn’t aware that these tests are running on a Virtual Platform and that’s how the coverage is being measured. I’ll look into this further, decide how we want to integrate it into our project, and get back to you.
I appreciate your help and support here.
Best regards,
Senthil
From: Mark Dykes <Mark.Dykes(a)arm.com<mailto:Mark.Dykes@arm.com>>
Sent: Wednesday, August 28, 2024 9:03 AM
To: Olivier Deprez <Olivier.Deprez(a)arm.com<mailto:Olivier.Deprez@arm.com>>; tf-a-tests(a)lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org>; Thangaraj, Senthil Nathan <SenthilNathan.Thangaraj(a)amd.com<mailto:SenthilNathan.Thangaraj@amd.com>>
Cc: Jain, Ronak <ronak.jain(a)amd.com<mailto:ronak.jain@amd.com>>; Nagal, Amit <amit.nagal(a)amd.com<mailto:amit.nagal@amd.com>>; Simek, Michal <michal.simek(a)amd.com<mailto:michal.simek@amd.com>>
Subject: RE: Query regarding the test coverage thru tf-a-tests
Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
Senthil,
I do have a way to get coverage for manual test runs using FVP if that helps. I can assist if needed….
Mark
From: Olivier Deprez <Olivier.Deprez(a)arm.com<mailto:Olivier.Deprez@arm.com>>
Sent: Wednesday, August 28, 2024 12:53 AM
To: Mark Dykes <Mark.Dykes(a)arm.com<mailto:Mark.Dykes@arm.com>>; tf-a-tests(a)lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org>; Thangaraj, Senthil Nathan <SenthilNathan.Thangaraj(a)amd.com<mailto:SenthilNathan.Thangaraj@amd.com>>
Cc: Jain, Ronak <ronak.jain(a)amd.com<mailto:ronak.jain@amd.com>>; Nagal, Amit <amit.nagal(a)amd.com<mailto:amit.nagal@amd.com>>; Simek, Michal <michal.simek(a)amd.com<mailto:michal.simek@amd.com>>
Subject: Re: Query regarding the test coverage thru tf-a-tests
Hi Senthil,
* Is there a way to get code coverage for manual test runs?
Sorry, I'm not aware of such capability.
As you say code coverage implies use of CI scripting that isn't possible to reproduce locally out of the box (afaik).
Regards,
Olivier.
________________________________
From: Thangaraj, Senthil Nathan via TF-A-Tests <tf-a-tests(a)lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org>>
Sent: 26 August 2024 23:58
To: Mark Dykes <Mark.Dykes(a)arm.com<mailto:Mark.Dykes@arm.com>>; Olivier Deprez <Olivier.Deprez(a)arm.com<mailto:Olivier.Deprez@arm.com>>; tf-a-tests(a)lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org> <tf-a-tests(a)lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org>>
Cc: Jain, Ronak <ronak.jain(a)amd.com<mailto:ronak.jain@amd.com>>; Nagal, Amit <amit.nagal(a)amd.com<mailto:amit.nagal@amd.com>>; Simek, Michal <michal.simek(a)amd.com<mailto:michal.simek@amd.com>>
Subject: [Tf-a-tests] Re: Query regarding the test coverage thru tf-a-tests
Hi Mark and Oliver,
A gentle reminder on the below request.
Thanks,
Senthil
From: Thangaraj, Senthil Nathan
Sent: Tuesday, August 20, 2024 3:44 PM
To: Mark Dykes <Mark.Dykes(a)arm.com<mailto:Mark.Dykes@arm.com>>; Olivier Deprez <Olivier.Deprez(a)arm.com<mailto:Olivier.Deprez@arm.com>>; tf-a-tests(a)lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org>
Cc: Jain, Ronak <ronak.jain(a)amd.com<mailto:ronak.jain@amd.com>>; Nagal, Amit <amit.nagal(a)amd.com<mailto:amit.nagal@amd.com>>; Simek, Michal <michal.simek(a)amd.com<mailto:michal.simek@amd.com>>
Subject: RE: Query regarding the test coverage thru tf-a-tests
Thanks a lot Mark and Oliver for your inputs and pointers.
All of these seem to be more closely integrated with the CI/CD builds. Is there a way to get code coverage for manual test runs? Specifically, I'm looking to get coverage results after loading and executing all the tests from a developer build (e.g., using a binary like tftf.bin).
Best regards,
Senthil
From: Mark Dykes <Mark.Dykes(a)arm.com<mailto:Mark.Dykes@arm.com<mailto:Mark.Dykes@arm.com%3cmailto:Mark.Dykes@arm.com>>>
Sent: Tuesday, August 20, 2024 3:16 PM
To: Olivier Deprez <Olivier.Deprez(a)arm.com<mailto:Olivier.Deprez@arm.com<mailto:Olivier.Deprez@arm.com%3cmailto:Olivier.Deprez@arm.com>>>; tf-a-tests(a)lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org%3cmailto:tf-a-tests@lists.trustedfirmware.org>>; Thangaraj, Senthil Nathan <SenthilNathan.Thangaraj(a)amd.com<mailto:SenthilNathan.Thangaraj@amd.com<mailto:SenthilNathan.Thangaraj@amd.com%3cmailto:SenthilNathan.Thangaraj@amd.com>>>
Subject: RE: Query regarding the test coverage thru tf-a-tests
Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
All,
This link is more current. The overall coverage numbers are not being reported due to an issue that is being worked on now. However you can see the individual coverage metrics if you click on a particular config where is says "success". The next page will have the link "Build Artifacts" at the top and so click that to the next where you will see the directory "trace_report". Click this and you will see a list of contents one of which should be index.html. If you click this you will see the individual coverage report for that config(test).
tf-a-ci-coverage-gateway #72 [Jenkins] (trustedfirmware.org)<https://ci.trustedfirmware.org/job/tf-a-ci-coverage-gateway/72/>
Let me know if you have questions...
Mark
From: Olivier Deprez <Olivier.Deprez(a)arm.com<mailto:Olivier.Deprez@arm.com<mailto:Olivier.Deprez@arm.com%3cmailto:Olivier.Deprez@arm.com>>>
Sent: Tuesday, August 20, 2024 2:27 AM
To: tf-a-tests(a)lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org%3cmailto:tf-a-tests@lists.trustedfirmware.org>>; Thangaraj, Senthil Nathan <SenthilNathan.Thangaraj(a)amd.com<mailto:SenthilNathan.Thangaraj@amd.com<mailto:SenthilNathan.Thangaraj@amd.com%3cmailto:SenthilNathan.Thangaraj@amd.com>>>; Mark Dykes <Mark.Dykes(a)arm.com<mailto:Mark.Dykes@arm.com<mailto:Mark.Dykes@arm.com%3cmailto:Mark.Dykes@arm.com>>>
Subject: Re: Query regarding the test coverage thru tf-a-tests
Hi,
You can refer to this job showing code coverage results aggregation from multiple test configurations:
https://ci.trustedfirmware.org/job/tf-a-ci-coverage-gateway/67/https://ci-builds.trustedfirmware.org/static-files/IK1tucCNXFdhS4AAQth8N7zW…
I don't think there is a test level granularity. @Mark Dykes<mailto:Mark.Dykes@arm.com> may know better.
Regards,
Olivier.
________________________________
From: Thangaraj, Senthil Nathan via TF-A-Tests <tf-a-tests(a)lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org%3cmailto:tf-a-tests@lists.trustedfirmware.org>>>
Sent: 20 August 2024 08:40
To: tf-a-tests(a)lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org%3cmailto:tf-a-tests@lists.trustedfirmware.org>> <tf-a-tests(a)lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org%3cmailto:tf-a-tests@lists.trustedfirmware.org>>>
Subject: [Tf-a-tests] Query regarding the test coverage thru tf-a-tests
Dear TF-A team,
I have a query regarding the TF-A test. Specifically, I would like to know if there is a method to find out the code coverage for a specific test or for all the tests in current run?
Your direction in this regard will be really appreciated.
Thank you,
Senthil
--
TF-A-Tests mailing list -- tf-a-tests(a)lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org%3cmailto:tf-a-tests@lists.trustedfirmware.org>>
To unsubscribe send an email to tf-a-tests-leave(a)lists.trustedfirmware.org<mailto:tf-a-tests-leave@lists.trustedfirmware.org<mailto:tf-a-tests-leave@lists.trustedfirmware.org%3cmailto:tf-a-tests-leave@lists.trustedfirmware.org>>
--
TF-A-Tests mailing list -- tf-a-tests(a)lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org>
To unsubscribe send an email to tf-a-tests-leave(a)lists.trustedfirmware.org<mailto:tf-a-tests-leave@lists.trustedfirmware.org>
Hi,
As a follow up to the Firmware-A v2.12 release [1], we are pleased to share the shrinkwrap tool [2]
configurations have been updated to consume latest firmware/upstream ingredients using following tags:
TF-A: v2.12.0
TF-a-tests: v2.12.0
Hafnium: v2.12.0
TF-RMM: tf-rmm-v0.6.0
CCA EDK2: 3223_arm_cca_rmm_v1.0_rel0_v3
linux: cca-full/v5+v7
kvmtool: cca/v3
An additional merge request is in queue for kvm-unit-tests update to cca/rmm-v1.0-rel0 tag.
Shrinkwrap is a convenient tool for building a fully integrated Arm CCA SW stack running on
the Base AEM FVP platform. In particular this is the tool of choice for RMM development to
reproduce a 3 or 4 worlds RME based environment.
Regards,
Olivier.
[1] https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.…
[2] https://shrinkwrap.docs.arm.com/en/latest/
Hi Everyone,
In order to facilitate development for Device Assignment tests for RME-DA, we have added MbedTLS repo as a submodule dependency to tf-a-tests. The merge commit can be found here : https://review.trustedfirmware.org/plugins/gitiles/TF-A/tf-a-tests/+/3e72cd…
The patch is done in such a way that existing build of TF-A-Tests or Test run is not affected due to the additional dependency. Only tests which depend on MbedTLS will be affected in that they will either be skipped or fail at runtime due to the missing dependency. Also, the change allows to use the config `MBEDTLS_DIR` to point to a MbedTLS directory outside the tf-a-tests source tree. This aligns with the TF-A mechanism for MbedTLS dependancy in case the submodule mechanism is not preferred.
We expect existing CI and testing infrastructure to be unaffected by this change. Please let us know if you have any comments.
Best Regards
Soby Mathew
