This event has been canceled.
TF-A Tech Forum
Thursday Dec 26, 2024 ⋅ 5pm – 6pm
Central European Time - Paris
We run an open technical forum call for anyone to participate and it is not
restricted to Trusted Firmware project members. It will operate under the
guidance of the TF TSC. Feel free to forward this invite to colleagues.
Invites are via the TF-A mailing list and also published on the Trusted
Firmware website. Details are here:
https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Trusted
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://linaro-org.zoom.us/my/trustedfirmware?pwd=VktXcm5MNUUyVVM4R0k3ZUtvdU84QT09
One tap mobile+16465588656,,9159704974# US (New
York)+16699009128,,9159704974# US (San Jose)Dial by your location +1
646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877
853 5247 US Toll-free 888 788 0099 US Toll-freeMeeting ID: 915 970
4974Find your local number: https://zoom.us/u/ad27hc6t7h
Guests
tf-a(a)lists.trustedfirmware.org
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee on the event.
Forwarding this invitation could allow any recipient to send a response to
the organizer, be added to the guest list, invite others regardless of
their own invitation status, or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
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>; 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; 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
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
From: Thangaraj, Senthil Nathan <SenthilNathan.Thangaraj(a)amd.com<mailto:SenthilNathan.Thangaraj@amd.com<mailto:SenthilNathan.Thangaraj@amd.com%3cmailto: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<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>>; 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>>>; Nagal, Amit <amit.nagal(a)amd.com<mailto:amit.nagal@amd.com<mailto:amit.nagal@amd.com%3cmailto:amit.nagal@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
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<mailto:Mark.Dykes@arm.com%3cmailto: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<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>>>
Cc: Jain, Ronak <ronak.jain(a)amd.com<mailto:ronak.jain@amd.com<mailto:ronak.jain@amd.com%3cmailto:ronak.jain@amd.com>>>; Nagal, Amit <amit.nagal(a)amd.com<mailto:amit.nagal@amd.com<mailto:amit.nagal@amd.com%3cmailto:amit.nagal@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
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<mailto:Olivier.Deprez@arm.com%3cmailto: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<mailto:Mark.Dykes@arm.com%3cmailto:Mark.Dykes@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>>>
Cc: Jain, Ronak <ronak.jain(a)amd.com<mailto:ronak.jain@amd.com<mailto:ronak.jain@amd.com%3cmailto:ronak.jain@amd.com>>>; Nagal, Amit <amit.nagal(a)amd.com<mailto:amit.nagal@amd.com<mailto:amit.nagal@amd.com%3cmailto:amit.nagal@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 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<mailto:tf-a-tests@lists.trustedfirmware.org%3cmailto: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<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>>>
Cc: Jain, Ronak <ronak.jain(a)amd.com<mailto:ronak.jain@amd.com<mailto:ronak.jain@amd.com%3cmailto:ronak.jain@amd.com>>>; Nagal, Amit <amit.nagal(a)amd.com<mailto:amit.nagal@amd.com<mailto:amit.nagal@amd.com%3cmailto:amit.nagal@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: [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<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>>
Cc: Jain, Ronak <ronak.jain(a)amd.com<mailto:ronak.jain@amd.com<mailto:ronak.jain@amd.com%3cmailto:ronak.jain@amd.com>>>; Nagal, Amit <amit.nagal(a)amd.com<mailto:amit.nagal@amd.com<mailto:amit.nagal@amd.com%3cmailto:amit.nagal@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
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<mailto:Mark.Dykes@arm.com%3cmailto:Mark.Dykes@arm.com%3cmailto: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<mailto:Olivier.Deprez@arm.com%3cmailto:Olivier.Deprez@arm.com%3cmailto: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<mailto:tf-a-tests@lists.trustedfirmware.org%3cmailto:tf-a-tests@lists.trustedfirmware.org%3cmailto: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<mailto:SenthilNathan.Thangaraj@amd.com%3cmailto:SenthilNathan.Thangaraj@amd.com%3cmailto: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<mailto:Olivier.Deprez@arm.com%3cmailto:Olivier.Deprez@arm.com%3cmailto: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<mailto:tf-a-tests@lists.trustedfirmware.org%3cmailto:tf-a-tests@lists.trustedfirmware.org%3cmailto: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<mailto:SenthilNathan.Thangaraj@amd.com%3cmailto:SenthilNathan.Thangaraj@amd.com%3cmailto: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<mailto:Mark.Dykes@arm.com%3cmailto:Mark.Dykes@arm.com%3cmailto: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<mailto:tf-a-tests@lists.trustedfirmware.org%3cmailto:tf-a-tests@lists.trustedfirmware.org%3cmailto: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<mailto:tf-a-tests@lists.trustedfirmware.org%3cmailto:tf-a-tests@lists.trustedfirmware.org%3cmailto: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<mailto:tf-a-tests@lists.trustedfirmware.org%3cmailto:tf-a-tests@lists.trustedfirmware.org%3cmailto: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<mailto:tf-a-tests@lists.trustedfirmware.org%3cmailto:tf-a-tests@lists.trustedfirmware.org%3cmailto: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<mailto:tf-a-tests-leave@lists.trustedfirmware.org%3cmailto:tf-a-tests-leave@lists.trustedfirmware.org%3cmailto: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<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>
This event has been canceled with a note:
"Hi, Cancelling as no topic proposed. Regards, Olivier. "
TF-A Tech Forum
Thursday Dec 12, 2024 ⋅ 5pm – 6pm
Central European Time - Paris
We run an open technical forum call for anyone to participate and it is not
restricted to Trusted Firmware project members. It will operate under the
guidance of the TF TSC. Feel free to forward this invite to colleagues.
Invites are via the TF-A mailing list and also published on the Trusted
Firmware website. Details are here:
https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Trusted
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://linaro-org.zoom.us/my/trustedfirmware?pwd=VktXcm5MNUUyVVM4R0k3ZUtvdU84QT09
One tap mobile+16465588656,,9159704974# US (New
York)+16699009128,,9159704974# US (San Jose)Dial by your location +1
646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877
853 5247 US Toll-free 888 788 0099 US Toll-freeMeeting ID: 915 970
4974Find your local number: https://zoom.us/u/ad27hc6t7h
Guests
tf-a(a)lists.trustedfirmware.org
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee on the event.
Forwarding this invitation could allow any recipient to send a response to
the organizer, be added to the guest list, invite others regardless of
their own invitation status, or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
Hi,
I recently uploaded the patch (https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/33536) to add qti platform support for qcs615. The patch is fully isolated and doesn't touch any common code and doesn't get included in any other platform compilation.
On enabling basic CI, I see some failures which are unrelated to my patch.
I wonder what the next step should be. If somebody can help me, it will be greatly appreciated.
Thanks
Amarinder
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 Max,
> Can we say this presentation (2022) is there and ready to use?
Yes, there are multiple measured boot and attestation schemes are implemented in TF-A and Trusted Services. What to use is depends on your use case and your system capability:
- A class core only
- A+M system where the M core is in a secure enclave
> By the way, you mentioned that attestation is not handled in TF-a (EL3), but the below EL3 handler handles it (RMM_ATTEST_GET_PLAT_TOKEN). Does it just send the request to the "Trusted Service" you were referencing?
No, they are different.
The available options/schemes:
* -If you have a single A class core and you want something similar to psa_initial_attest_get_token() then read this:
https://trusted-services.readthedocs.io/en/latest/services/attest-service-d…
Here the token is created by a secure service running in SEL0/1. EL3 only responsible for making the world switch (S<->NS). This is callable from Linux user space, with the libs and kernel driver pointed out by George.
* What you mentioned above (RMM_ATTEST_GET_PLAT_TOKEN) is basically the CCA attestation scheme, where there are two halves tokens. It is targeting the RME capable systems which otherwise have A+M cores. One half of the token is produced by the M class secure enclave(HES) the other half by the RMM running in REL2 on the A core. There is a hash link between the half tokens.
Please elaborate your use case then I can help more!
Regards,
Tamas
From: Gyorgy Szing <Gyorgy.Szing(a)arm.com>
Sent: Monday, December 2, 2024 11:43 AM
To: Max Adam <maxadamcamb(a)gmail.com>; Tamas Ban <Tamas.Ban(a)arm.com>
Subject: Re: [TF-A] Interaction with TF-a from NS World
Hi,
"By the way, you mentioned that attestation is not handled in TF-a (EL3),"
Sorry, my bad. Since you mentioned PSA I got the impression you are after PSA Initial Attestation, and that is out of scope for TF-A.
Tamas: Can you please respond to the RMM related attestation question?
/George
On 2024-12-02, 11:38, "Max Adam" <maxadamcamb(a)gmail.com<mailto:maxadamcamb@gmail.com>> wrote:
Hi Gyorgy,
Thank you for the detailed comment. It is really helpful, especially this link seems good to chase: https://git.yoctoproject.org/meta-arm/about/documentation/trusted-services.…
Basically, I was following this link from @Tamas.ban@arm.com<mailto:Tamas.ban@arm.com>; "CCA attestation and measured both"
https://www.trustedfirmware.org/docs/Attestation_and_Measured_Boot.pdf
Can we say this presentation (2022) is there and ready to use?
By the way, you mentioned that attestation is not handled in TF-a (EL3), but the below EL3 handler handles it (RMM_ATTEST_GET_PLAT_TOKEN). Does it just send the request to the "Trusted Service" you were referencing?
Error! Filename not specified.
Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>>, 2 Ara 2024 Pzt, 09:29 tarihinde şunu yazdı:
Hi Max,
Please check this picture [1]. It shows the exception levels on an aarch64 platforms, and typical components executing at each exception level.
TF-A is a Secure Monitor implementation. It is the most privileged component, and its main goal is to route calls between the NWd and SWd. Each call to SWd must go through this component. E.g. if an "aarch64 App" wishes to use a service provided by a Trusted Service, a call has to be made into EL1 (e.g. Linux Kernel), then if a Hypervisor is present to EL2, then to the Monitor at EL3 (TF-A), then to optional S-EL2 (e.g. Hafnium), S-EL1 (e.g. OP_TEE) and finally to S-EL0.
TF-A does not implement the PSA APIs.
OP-TEE is a Trusted OS, and a reference implementation of the Global Platforms standards [2]. PSA is not part of GP, and AFAIK there is no TA implementing PSA APIs.
The PSA reference implementation for Cortex-A is developed in the Trusted Services project. The project implements all services required for PSA certification (Crypto, ITS, PS, Attestation) plus a few non-psa ones like Firmware Update Service or UEFI Variable service. We developed a Linux kernel driver called tstee (up-stream since v6.10) , and two shared libraries which can be used by linux user-space applications to access the services. Libts implements service discovery and the TS RPC components, and "libtspsa" carries easy to use PSA client implementations (basically the C PSA API).
Trusted Services follows the Firmware Framework for A-Profile standard (FF-A) which defines a protocol to be used between exception levels and a runtime model. PSA services are deployed to S-EL0 Secure Partitions and need a Secure Partition Manager implementation executing at a higher exception levels. The reference SPMD implementation is part of the TF-A project, the S-EL2 reference SPMC is Hafnium [5], and the S-EL1 reference implementation is OP-TEE SPMC [6]. (Only one SPMC implementation can be present on a system.)
A major difference between the Cortex-M and the Cortex-A ecosystem is the level of diversity. While a Cortex-M stack is typically implemented using components from one or maximum a few stakeholders, a Cortex-A stack is built from components owned by a vast set of owners. As a result, integration of a Cortex-A software stack is much more complex. There are multiple integration systems targeting the problem like Buildroot and Yocto. Trusted Services supports two integration systems currently. The OP-TEE integration system, which is a gnumake and Buildroot based solution (see [7]) and Yocto where the meta-arm layer [8] hosts TS recipes. Please find some TS specific meta-arm documentation here: [9]
For more help and information, about PSA on Cortex-A and TS feel free to drop an email to the TS mailing list [10], and/or to me.
/George
1: https://documentation-service.arm.com/static/63a065c41d698c4dc521cb1b
2: https://globalplatform.org/about-globalplatform/
3: https://trusted-services.readthedocs.io/en/stable/overview/index.html
4: https://developer.arm.com/architectures/Firmware%20Framework%20for%20A-Prof…
5: https://hafnium.readthedocs.io/en/latest/secure-partition-manager/index.html
6: https://optee.readthedocs.io/en/latest/architecture/spmc.html
7: https://github.com/OP-TEE/build
8: https://git.yoctoproject.org/meta-arm
9: https://git.yoctoproject.org/meta-arm/about/documentation/trusted-services.…
10: https://lists.trustedfirmware.org/mailman3/lists/trusted-services.lists.tru…
On 2024-12-01, 21:14, "Max Adam via TF-A" <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> wrote:
Hello All,
I am coming from the TF-m domain, and now I am struggling with TF-a as I am not a Linux expert.
I am just looking for the interactions with TF-a, such as getting psa attestation token etc.
How can I find example these interactions from NS World (Linux) or lower privilege Secure World Executions such as OP-TEE or OP-TEE TAs?
I suppose there shall be drivers and APIs provided by TF-a?
Thanks
Max
Hello All,
I am coming from the TF-m domain, and now I am struggling with TF-a as I am
not a Linux expert.
I am just looking for the interactions with TF-a, such as getting psa
attestation token etc.
How can I find example these interactions from NS World (Linux) or lower
privilege Secure World Executions such as OP-TEE or OP-TEE TAs?
I suppose there shall be drivers and APIs provided by TF-a?
Thanks
Max
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