- TF-A - lists.trustedfirmware.org

Canceled event: TF-A Tech Forum @ Thu Dec 26, 2024 5pm - 6pm (GMT+1) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

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

5 months, 2 weeks

1
0
0 0

Re: Query regarding the test coverage thru tf-a-tests

by Nagal, Amit

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>

5 months, 3 weeks

2
4
0 0

Canceled event with note: TF-A Tech Forum @ Thu Dec 12, 2024 5pm - 6pm (GMT+1) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

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

5 months, 3 weeks

1
0
0 0

Unable to merge gerrit#33536

by Amarinder Singh Sethi (QUIC)

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

5 months, 4 weeks

2
2
0 0

Trusted Firmware-A LTS v2.8.26 Release Announcement

by ci_notify＠trustedfirmware.org

Hello, Trusted Firmware-A LTS version 2.8.26 is now available. This release contains the following patches: a449c1360 build(npm): bump word-wrap from 1.2.3 to 1.2.4 [1] ceb400895 build(npm): update Node.js and all packages [2] 0abe5d571 build(deps): bump braces [3] 3de9d3abd chore(deps): bump micromatch [4] [1] https://review.trustedfirmware.org/q/I9a383e6d6ae907858028980eadccfa2070f42… [2] https://review.trustedfirmware.org/q/[1, "always", "Change-Id:"], /* Warning */ [3] https://review.trustedfirmware.org/q/I7e2a543a3bc67d426a69fc25f93b878c9b5a3… [4] https://review.trustedfirmware.org/q/I783a6838616c570a41a5a0f58db3e6430c43c… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.8.26/change-log.html Thanks, TF-A LTS team

6 months

1
0
0 0

Trusted Firmware-A LTS v2.10.10 Release Announcement

by ci_notify＠trustedfirmware.org

Hello, Trusted Firmware-A LTS version 2.10.10 is now available. This release contains the following patches: 3ea256c36 build(deps): bump pip from 23.1.2 to 23.3 [1] f8a06a0f8 build(deps): bump urllib3 from 2.0.2 to 2.2.2 [2] 93ad43e79 build(deps): bump jinja2 from 3.1.2 to 3.1.4 [3] ebf6430a0 build(deps): bump idna from 3.4 to 3.7 [4] c5d2a030a build(deps): bump braces [5] 6c6e986bf build(npm): update Node.js and all packages [6] 395ef3534 chore(deps): bump micromatch [7] c9f3fb582 build(deps): bump setuptools in the pip group across 1 directory [8] [1] https://review.trustedfirmware.org/q/I40b0219fe5e6797fc2a2534d8ea8c9480af36… [2] https://review.trustedfirmware.org/q/I4f3a1ffe0cf374f433ac59b20b7d60ee77009… [3] https://review.trustedfirmware.org/q/I69248b2c17f8edfe7dfd27952aae688e7d424… [4] https://review.trustedfirmware.org/q/I78f5052e20572d92f1bc21213bb29b5549f34… [5] https://review.trustedfirmware.org/q/I7e2a543a3bc67d426a69fc25f93b878c9b5a3… [6] https://review.trustedfirmware.org/q/[1, "always", "Change-Id:"], /* Warning */ [7] https://review.trustedfirmware.org/q/I783a6838616c570a41a5a0f58db3e6430c43c… [8] https://review.trustedfirmware.org/q/Ibd4e4730bfc5cce8d85ec55021983d6f748ff… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.10.10/change-log.html Thanks, TF-A LTS team

6 months

1
0
0 0

Firmware-A v2.12 release follow up - shrinkwrap

by Olivier Deprez

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/

6 months

1
0
0 0

Re: Interaction with TF-a from NS World

by Tamas Ban

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

6 months, 1 week

3
3
0 0

Interaction with TF-a from NS World

by Max Adam

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

6 months, 1 week

2
1
0 0

Addition of mbedTLS as a submodule dependency to TF-A-Tests

by Soby Mathew

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

6 months, 1 week

1
0
0 0

Trusted Firmware-A LTS v2.8.25 Release Announcement

by ci_notify＠trustedfirmware.org

Hello, Trusted Firmware-A LTS version 2.8.25 is now available. This release contains the following patches: 3e1ecab9a build(deps): bump pip from 23.1.2 to 23.3 [1] 73421e1df build(deps): bump urllib3 from 2.0.2 to 2.2.2 [2] b607e5481 build(deps): bump jinja2 from 3.1.2 to 3.1.4 [3] 720d7ea22 build(deps): bump idna from 3.4 to 3.7 [4] [1] https://review.trustedfirmware.org/q/I40b0219fe5e6797fc2a2534d8ea8c9480af36… [2] https://review.trustedfirmware.org/q/I4f3a1ffe0cf374f433ac59b20b7d60ee77009… [3] https://review.trustedfirmware.org/q/I69248b2c17f8edfe7dfd27952aae688e7d424… [4] https://review.trustedfirmware.org/q/I78f5052e20572d92f1bc21213bb29b5549f34… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.8.25/change-log.html Thanks, TF-A LTS team

6 months, 1 week

1
0
0 0

Canceled event: TF-A Tech Forum @ Thu Nov 28, 2024 5pm - 6pm (GMT+1) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

This event has been canceled. TF-A Tech Forum Thursday Nov 28, 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. To stop receiving future updates for this event, decline this 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

6 months, 1 week

1
0
0 0

Trusted Firmware v2.12 release announcement

by Olivier Deprez

Hi All, We are pleased to announce the formal release of Trusted Firmware-A version 2.12 bundle of project deliverables. This includes Trusted Firmware-A, Trusted Firmware-A Tests, Hafnium, RMM, Trusted Services, and TF-A OpenCI scripts/jobs components. These went live on Nov, 21st 2024. 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.12 are as follows: TF-A/EL3 * New CPUs support: Cortex-A320 (Arcadia), Cortex-A720AE. * Arch extensions: : FEAT_THE, FEAT_LS64_ACCDATA, FEAT_Debugv8p9, FEAT_SCTLR2, FEAT_FGT2 ; Arm 9.4 : FEAT_D128 support. * Context management: Asymmetric CPU features, EL3 execution context, SVE S/R support. * RME: GPT contiguous descriptor (or GPT large mappings support). * Arm CCA: added attestation generic library, el3 attestation token signing support. Boot flow * Tools: * Introduced the Transfer List Compiler (TLC) Host Tool supporting the FW hand-off specification. * Introduced CoT Device Tree to C File (DT2C) tool. * mbedTLS Improvements: * Resolved random authentication failures with ECDSA. * Enhanced mbedTLS configuration selection. * Maximize usage of mbedTLS library APIs in TF-A. * Upgraded to mbedTLS v3.6.1. * Feature addition/support: * Support for the ECDSA P-384 curve with the PSA Crypto implementation. * Documentation: * Added the DPE Design and Threat Model document to TF-A readthedocs. Errata (CPU/GIC) * Cortex-A720, Cortex-A520, Cortex-X4 errata. TF-A platforms support * New platforms added: TC4, RD-1 AE, RK3566/RK3568. * Platform fixes: FPGA, FVP, Neoverse-RD, TC, Corstone-1000, Allwinner, AST2700, Poplar, Agilex, A3K, MT8188, iMX8M, S32G274A, qemu, Rpi3, Rockchip, STM32MP1, STM32MP2, Versal, ZynqMP. Hafnium/SPM (S-EL2) * FF-A features additions * FF-A v1.2 FFA_MSG_WAIT RX buffer ownership flag. * FF-A v1.2 FFA_VERSION endpoint restriction. * FF-A v1.1 VM availability messages. * Architectural support * vCPU IPI signaling. * Arch timer virtualization. * RME: GPF support and memcpy hardening. * Secure Interrupt Handling for UP S-EL1 partitions. TF-RMM (R-EL2) * REL0 RMM 1.0 support. * Support for alternative attestation token signing via EL3. * Various improvements and bugfixes as listed in the change log. TF-A Tests * Arm arch. extensions: AMU, FEAT_FGT2, LS64_ACCDATA, FEAT_Debugv8p9, LS64 64-byte load/store. * Asymmetric feature testing (FEAT_SPE, FEAT_TRBE, FEAT_TCR2). * EL1 and EL2 context switch tests. * FF-A: v1.2 support, S-EL2 arch timer virtualization, S-EL2+RME hardening, EL3 SPMC TFTF test suite, EL3 SVE test coverage. * RME: RMM v1.0 testing support, PCIe DOE support, RMI support for FEAT_LPA2, SIMD, PAuth. * Platforms: AMD Versal Gen 2 added, Neoverse-RD refactoring, FVP PCIe support. 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/+/refs/tags… 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.12.0/change-log.html#id1 https://trustedfirmware-a-tests.readthedocs.io/en/latest/change-log.html#ve… https://hafnium.readthedocs.io/en/v2.12.0/change-log.html#v2-12 https://tf-rmm.readthedocs.io/en/latest/about/change-log.html#v0-6-0 Regards, Olivier.

6 months, 2 weeks

1
0
0 0

Changelog for v2.12 Release

by Govindraj Raja

Hello Everyone, Please take a look at the changelog for your respective platforms ahead of the TF-A v2.12 release. The changelog is autogenerated from the commit messages of the patches that have been merged since the v2.11 release. Here's your chance to give us guidance on any small manual adjustments you would like to see. Patch: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/33483 Rendered Version: https://ci-builds.trustedfirmware.org/static-files/pAvWwn44kBOyAVI04_7T9WjV… -- Thanks, Govindraj R

6 months, 3 weeks

1
0
0 0

Canceled event: TF-A Tech Forum @ Thu Nov 14, 2024 5pm - 6pm (GMT+1) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

This event has been canceled. TF-A Tech Forum Thursday Nov 14, 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. To stop receiving future updates for this event, decline this 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

6 months, 3 weeks

1
0
0 0

Firmware-A v2.12 release code freeze notification

by Govindraj Raja

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

6 months, 3 weeks

1
1
0 0

Reference Secure Partition Code with FF-A

by Belsare, Akshay

Hello everyone, I'm seeking a reference code for a Standalone Secure Partition using FF-A. Any guidance or suggestions would be greatly appreciated! TIA, Akshay

7 months

3
2
0 0

TF-A: Compilation issues for Rockchip platforms

by Quentin Schulz

Hi all, I've sent a few patches for fixing some compilation warnings or issues on Rockchip platforms [1][2][3][4][5] but I'm left with a few still... [1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/33080 [2] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/33081 [3] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/33082 [4] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/33083 [5] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/33084 1) RK3588 symbol redefinition in assembly ======================================================================== commit fc3b98b2124c2b773322da0201e9ad7a697e6323 Author: Quentin Schulz <quentin.schulz(a)cherry.de> Date: Mon Oct 28 12:40:18 2024 +0100 fix(rk3588): pmu: fix assembly symbol redefinition Somehow cpus_pd_req_enter_wfi() gets called multiple times and clang isn't happy about redefining the same label multiple times (it is an inline function). An option could be to force the code to not be inlined (with __attribute__((noinline))) as removing the explicit inline still made the compiler inline the code. Recreate the while loop without a label to fix the clang build issue: plat/rockchip/rk3588/drivers/pmu/pmu.c:763:7: error: symbol 'wfi_loop' is already defined 763 | "wfi_loop:\n" | ^ <inline asm>:5:1: note: instantiated into assembly here 5 | wfi_loop: | ^ Signed-off-by: Quentin Schulz <quentin.schulz(a)cherry.de> Change-Id: Ie9f55135b2f95a78deb7cbb94f9a62d3ba61e808 diff --git a/plat/rockchip/rk3588/drivers/pmu/pmu.c b/plat/rockchip/rk3588/drivers/pmu/pmu.c index f693dbdf0..f05d3e58f 100644 --- a/plat/rockchip/rk3588/drivers/pmu/pmu.c +++ b/plat/rockchip/rk3588/drivers/pmu/pmu.c @@ -760,10 +760,10 @@ static inline void cpus_pd_req_enter_wfi(void) "mrs x0, S3_0_C15_C2_7\n" "orr x0, x0, #0x1\n" "msr S3_0_C15_C2_7, x0\n" - "wfi_loop:\n" + "ldr x0, .+4\n" "isb\n" "wfi\n" - "b wfi_loop\n"); + "br x0\n"); } static void nonboot_cpus_off(void) ========================================================================= This only happens for clang and I'm a bit confused as to why. Applying the above patch fixing that issue but inspecting the assembly code reveals something really odd. **With** that patch, with gcc: 25c8c: d510149f msr dbgprcr_el1, xzr 25c90: d538f2e0 mrs x0, s3_0_c15_c2_7 25c94: b2400000 orr x0, x0, #0x1 25c98: d518f2e0 msr s3_0_c15_c2_7, x0 25c9c: 58000020 ldr x0, 0x25ca0 25ca0: d5033fdf isb 25ca4: d503207f wfi 25ca8: d61f0000 br x0 **with** that patch, with clang: 26d2c: d510149f msr dbgprcr_el1, xzr 26d30: d538f2e0 mrs x0, s3_0_c15_c2_7 26d34: b2400000 orr x0, x0, #0x1 26d38: d518f2e0 msr s3_0_c15_c2_7, x0 26d3c: 58000020 ldr x0, 0x26d40 <--- "my" ldr 26d40: d5033fdf isb 26d44: d503207f wfi 26d48: d61f0000 br x0 <--- "my" br 26d4c: 94000e76 bl 0x2a724 26d50: d510149f msr dbgprcr_el1, xzr 26d54: d538f2e0 mrs x0, s3_0_c15_c2_7 26d58: b2400000 orr x0, x0, #0x1 26d5c: d518f2e0 msr s3_0_c15_c2_7, x0 26d60: 58000020 ldr x0, 0x26d64 <--- "my" ldr 26d64: d5033fdf isb 26d68: d503207f wfi 26d6c: d61f0000 br x0 <--- "my" br So I think the above patch is just a band-aid on what the actually is but I have no idea what could be going on. If I use this patch instead, to match the other assembly instructions in this file ========================================================================= diff --git a/plat/rockchip/rk3588/drivers/pmu/pmu.c b/plat/rockchip/rk3588/drivers/pmu/pmu.c index f693dbdf0..a4128b214 100644 --- a/plat/rockchip/rk3588/drivers/pmu/pmu.c +++ b/plat/rockchip/rk3588/drivers/pmu/pmu.c @@ -760,10 +760,10 @@ static inline void cpus_pd_req_enter_wfi(void) "mrs x0, S3_0_C15_C2_7\n" "orr x0, x0, #0x1\n" "msr S3_0_C15_C2_7, x0\n" - "wfi_loop:\n" + "1:\n" "isb\n" "wfi\n" - "b wfi_loop\n"); + "b 1b\n"); } static void nonboot_cpus_off(void) ========================================================================= It happily compiles, though the binary still seems to contain this loop twice. Using __attribute__((noinline)) the code is not duplicated, but I assume this is expected as it would now simply be a function. 2) RK3399 warning array subscript 0 is outside array bounds of 'volatile unsigned int[0]' [-Warray-bounds=] """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" In file included from src/dram.c:12: src/dram.c: In function 'm0_main': include/rk3399_mcu.h:15:34: warning: array subscript 0 is outside array bounds of 'volatile unsigned int[0]' [-Warray-bounds=] 15 | (*(volatile unsigned int *)(c)); __v; }) | ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ include/rk3399_mcu.h:16:69: note: in definition of macro 'mmio_write_32' 16 | #define mmio_write_32(c, v) ((*(volatile unsigned int *)(c)) = (v)) | ^ src/dram.c:67:23: note: in expansion of macro 'mmio_read_32' 67 | mmio_read_32(PARAM_ADDR + PARAM_FREQ_SELECT)); | ^~~~~~~~~~~~ cc1: note: source object is likely at address zero In function 'ddr_set_pll', inlined from 'm0_main' at src/dram.c:71:2: include/rk3399_mcu.h:14:40: warning: array subscript 0 is outside array bounds of 'volatile unsigned int[0]' [-Warray-bounds=] 14 | #define mmio_read_32(c) ({unsigned int __v = \ | ^~~ include/rk3399_mcu.h:16:69: note: in definition of macro 'mmio_write_32' 16 | #define mmio_write_32(c, v) ((*(volatile unsigned int *)(c)) = (v)) | ^ src/dram.c:47:23: note: in expansion of macro 'mmio_read_32' 47 | mmio_read_32(PARAM_ADDR + PARAM_DPLL_CON0)); | ^~~~~~~~~~~~ In function 'm0_main': cc1: note: source object is likely at address zero In function 'ddr_set_pll', inlined from 'm0_main' at src/dram.c:71:2: include/rk3399_mcu.h:14:40: warning: array subscript 0 is outside array bounds of 'volatile unsigned int[0]' [-Warray-bounds=] 14 | #define mmio_read_32(c) ({unsigned int __v = \ | ^~~ include/rk3399_mcu.h:16:69: note: in definition of macro 'mmio_write_32' 16 | #define mmio_write_32(c, v) ((*(volatile unsigned int *)(c)) = (v)) | ^ src/dram.c:49:23: note: in expansion of macro 'mmio_read_32' 49 | mmio_read_32(PARAM_ADDR + PARAM_DPLL_CON1)); | ^~~~~~~~~~~~ In function 'm0_main': cc1: note: source object is likely at address zero include/rk3399_mcu.h:16:35: warning: array subscript 0 is outside array bounds of 'volatile unsigned int[0]' [-Warray-bounds=] 16 | #define mmio_write_32(c, v) ((*(volatile unsigned int *)(c)) = (v)) | ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ src/dram.c:80:9: note: in expansion of macro 'mmio_write_32' 80 | mmio_write_32(PARAM_ADDR + PARAM_M0_DONE, M0_DONE_FLAG); | ^~~~~~~~~~~~~ cc1: note: source object is likely at address zero """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" This function is used in many places, but only in very specific places is it triggering a warning, when PARAM_ADDR is used, but only when accessed from m0 C files. PARAM_ADDR is set to 0xc0. From !m0 files, access to PARAM_ADDR seems to be done through the M0_PARAM_ADDR which is M0_BINCODE_BASE + PARAM_ADDR. For m0 files, it's directly accessing PARAM_ADDR. I honestly don't really know why it's complaining for m0 files but not the !m0 ones. 3) RK3399 expected string in '.incbin' directive This is only for clang. """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" <instantiation>:6:10: error: expected string in '.incbin' directive .incbin /home/qschulz/work/upstream/trusted-firmware-a/build/rk3399/release/m0/rk3399m0.bin ^ plat/rockchip/rk3399/drivers/pmu/pmu_fw.S:20:1: note: while in macro instantiation INCBIN """/home/qschulz/work/upstream/trusted-firmware-a/build/rk3399/release/m0/rk3399m0.bin""", "rk3399m0_bin", ".sram.incbin" ^ <instantiation>:6:10: error: expected string in '.incbin' directive .incbin /home/qschulz/work/upstream/trusted-firmware-a/build/rk3399/release/m0/rk3399m0pmu.bin ^ plat/rockchip/rk3399/drivers/pmu/pmu_fw.S:21:1: note: while in macro instantiation INCBIN """/home/qschulz/work/upstream/trusted-firmware-a/build/rk3399/release/m0/rk3399m0pmu.bin""", "rk3399m0pmu_bin", ".pmusram.incbin" ^ """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" With the following patch: ========================================================================= diff --git a/plat/rockchip/rk3399/drivers/pmu/pmu_fw.S b/plat/rockchip/rk3399/drivers/pmu/pmu_fw.S index 26f331317..ed70cba1f 100644 --- a/plat/rockchip/rk3399/drivers/pmu/pmu_fw.S +++ b/plat/rockchip/rk3399/drivers/pmu/pmu_fw.S @@ -11,7 +11,7 @@ .type \sym, @object .align 4 \sym : - .incbin \file + .incbin "\file" .size \sym , .-\sym .global \sym\()_end \sym\()_end : ========================================================================= clang seems happy with that error but the linker triggers another one: ld.lld: warning: ignoring memory region assignment for non-allocatable section '.incbin_sram' ld.lld: error: section '.pmusram' will not fit in region 'PMUSRAM': overflowed by 3928 bytes Would appreciate some guidance there :) Cheers, Quentin

7 months

3
15
0 0

Re: TF-A: Compilation issues for Rockchip platforms

by Chris Kay

I’m afraid I’ve not been able to reproduce the .incbin error – it all links fine for me. $ clang --version Ubuntu clang version 18.1.3 (1ubuntu1) Target: aarch64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/bin

7 months

1
0
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 1 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 447712: Integer handling issues (NO_EFFECT) /plat/arm/board/fvp/fvp_pm.c: 332 in fvp_node_hw_state() ________________________________________________________________________________________________________ *** CID 447712: Integer handling issues (NO_EFFECT) /plat/arm/board/fvp/fvp_pm.c: 332 in fvp_node_hw_state() 326 int ret = 0; 327 328 /* 329 * The format of 'power_level' is implementation-defined, but 0 must 330 * mean a CPU. We also allow 1 to denote the cluster 331 */ >>> CID 447712: Integer handling issues (NO_EFFECT) >>> This less-than-zero comparison of an unsigned value is never true. "power_level < 0ULL". 332 if ((power_level < ARM_PWR_LVL0) || (power_level > ARM_PWR_LVL1)) 333 return PSCI_E_INVALID_PARAMS; 334 335 /* 336 * Read the status of the given MPDIR from FVP power controller. The 337 * power controller only gives us on/off status, so map that to expected ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2…

7 months, 1 week

1
0
0 0

Canceled event: TF-A Tech Forum @ Thu Oct 31, 2024 5pm - 6pm (GMT+1) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

This event has been canceled. TF-A Tech Forum Thursday Oct 31, 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. To stop receiving future updates for this event, decline this 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

7 months, 1 week

1
0
0 0

TF-A Tech Forum regular call

by Olivier Deprez

Dear TF-A ML members, As mentioned in https://www.trustedfirmware.org/meetings/tf-a-technical-forum/, trustedfirmware.org hosts regular technical calls on Thursdays. It mentions TF-A although in practise a number of Cortex-A projects beyond TF-A were discussed (refer to prior recordings on this page). Unfortunately this slot hasn't been very active recently. By this email I'm kindly emphasizing this forum is open to the community (and beyond trustedfirmware.org members) and you are welcome to propose topics. Presentations/slides are not strictly necessary, and we can also host informal discussions or session of questions. If you think of a topic, please reach to me and I'll be happy to accommodate. Thanks for your contributions in advance! Regards, Olivier.

7 months, 1 week

1
0
0 0

How to configure TZC-400 in ATF?

by 钱非凡

I tried to add two new tzc regions in ATF's source code, and test the memory access in the new region. ```cpp #define ARM_TZC_REGIONS_DEF \ {ARM_AP_TZC_DRAM1_BASE, ARM_EL3_TZC_DRAM1_END + ARM_L1_GPT_SIZE, TZC_REGION_S_RDWR, 0}, \ {ARM_NS_DRAM1_BASE, 0xA0000000-1, ARM_TZC_NS_DRAM_S_ACCESS, PLAT_ARM_TZC_NS_DEV_ACCESS}, \ {0xA0000000, 0xB0000000-1, ARM_TZC_NS_DRAM_S_ACCESS, PLAT_ARM_TZC_NS_DEV_ACCESS}, \ {0xB0000000, 0xC0000000-1, ARM_TZC_NS_DRAM_S_ACCESS, PLAT_ARM_TZC_NS_DEV_ACCESS}, \ {0xC0000000, ARM_NS_DRAM1_END, ARM_TZC_NS_DRAM_S_ACCESS, PLAT_ARM_TZC_NS_DEV_ACCESS}, \ {ARM_DRAM2_BASE, ARM_DRAM2_END, ARM_TZC_NS_DRAM_S_ACCESS, PLAT_ARM_TZC_NS_DEV_ACCESS} ``` But FVP throws some warnings: ``` Info: FVP_Base_RevC_2xAEMvA: FVP_Base_RevC_2xAEMvA.bp.tzc_400: common_reset starts Info: FVP_Base_RevC_2xAEMvA: FVP_Base_RevC_2xAEMvA.bp.tzc_400: build config register value 0x3003f08 4 filters, 9 regions, address width 64 Info: FVP_Base_RevC_2xAEMvA: FVP_Base_RevC_2xAEMvA.bp.flashloader0: FlashLoader: Loaded 3164 kB from file '/home/bea1e/functionality-prototype/build/../trusted-firmware-a/build/fvp/release/fip.bin' Info: FVP_Base_RevC_2xAEMvA: FVP_Base_RevC_2xAEMvA.bp.secureflashloader: FlashLoader: Loaded 25 kB from file '/home/bea1e/functionality-prototype/build/../trusted-firmware-a/build/fvp/release/bl1.bin' Info: FVP_Base_RevC_2xAEMvA: FVP_Base_RevC_2xAEMvA.bp.tzc_400: common_reset starts Info: FVP_Base_RevC_2xAEMvA: FVP_Base_RevC_2xAEMvA.bp.tzc_400: build config register value 0x3003f08 4 filters, 9 regions, address width 64 Warning: FVP_Base_RevC_2xAEMvA: FVP_Base_RevC_2xAEMvA.bp.tzc_400: attempt to write invalid address 220 In file: (unknown):0 In process: FVP_Base_RevC_2xAEMvA.thread_p_32 @ 5126760 ns Warning: FVP_Base_RevC_2xAEMvA: FVP_Base_RevC_2xAEMvA.bp.tzc_400: attempt to write invalid address 224 In file: (unknown):0 In process: FVP_Base_RevC_2xAEMvA.thread_p_32 @ 5126760 ns Warning: FVP_Base_RevC_2xAEMvA: FVP_Base_RevC_2xAEMvA.bp.tzc_400: attempt to write invalid address 228 In file: (unknown):0 In process: FVP_Base_RevC_2xAEMvA.thread_p_32 @ 5126760 ns Warning: FVP_Base_RevC_2xAEMvA: FVP_Base_RevC_2xAEMvA.bp.tzc_400: attempt to write invalid address 22c In file: (unknown):0 In process: FVP_Base_RevC_2xAEMvA.thread_p_32 @ 5126760 ns Warning: FVP_Base_RevC_2xAEMvA: FVP_Base_RevC_2xAEMvA.bp.tzc_400: attempt to write invalid address 230 In file: (unknown):0 In process: FVP_Base_RevC_2xAEMvA.thread_p_32 @ 5126760 ns Warning: FVP_Base_RevC_2xAEMvA: FVP_Base_RevC_2xAEMvA.bp.tzc_400: attempt to write invalid address 234 In file: (unknown):0 In process: FVP_Base_RevC_2xAEMvA.thread_p_32 @ 5126760 ns Warning: FVP_Base_RevC_2xAEMvA: FVP_Base_RevC_2xAEMvA.bp.tzc_400: attempt to write invalid address 240 In file: (unknown):0 In process: FVP_Base_RevC_2xAEMvA.thread_p_32 @ 5127800 ns Warning: FVP_Base_RevC_2xAEMvA: FVP_Base_RevC_2xAEMvA.bp.tzc_400: attempt to write invalid address 244 In file: (unknown):0 In process: FVP_Base_RevC_2xAEMvA.thread_p_32 @ 5127800 ns Warning: FVP_Base_RevC_2xAEMvA: FVP_Base_RevC_2xAEMvA.bp.tzc_400: attempt to write invalid address 248 In file: (unknown):0 In process: FVP_Base_RevC_2xAEMvA.thread_p_32 @ 5127800 ns Warning: FVP_Base_RevC_2xAEMvA: FVP_Base_RevC_2xAEMvA.bp.tzc_400: attempt to write invalid address 24c In file: (unknown):0 In process: FVP_Base_RevC_2xAEMvA.thread_p_32 @ 5127800 ns Warning: FVP_Base_RevC_2xAEMvA: FVP_Base_RevC_2xAEMvA.bp.tzc_400: attempt to write invalid address 250 In file: (unknown):0 In process: FVP_Base_RevC_2xAEMvA.thread_p_32 @ 5127800 ns Warning: FVP_Base_RevC_2xAEMvA: FVP_Base_RevC_2xAEMvA.bp.tzc_400: attempt to write invalid address 254 In file: (unknown):0 In process: FVP_Base_RevC_2xAEMvA.thread_p_32 @ 5127800 ns ``` It seems the configuration registers for the two new regions are invalid. But I dont know how to solve this problem. Here are the arguments of FVP: ``` -C bp.ve_sysregs.exit_on_shutdown=1 \ -C cache_state_modelled=0 \ -C pctl.startup=0.0.0.0 \ -C cluster0.NUM_CORES=4 \ -C cluster1.NUM_CORES=4 \ -C bp.secure_memory=1 \ -C bp.dram_size=8 \ -C bp.tzc_400.diagnostics=1 \ -C bp.secureflashloader.fname=$(TF_A_PATH)/build/fvp/$(TF_A_BUILD)/bl1.bin \ -C bp.flashloader0.fname=$(TF_A_PATH)/build/fvp/$(TF_A_BUILD)/fip.bin \ -C bp.virtioblockdevice.image_path=$(BOOT_IMG) ``` Should I add more arguments while booting FVP? Is there any other advice for me to test the TZASC configurations?

7 months, 1 week

2
1
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 1 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 447121: Incorrect expression (UNUSED_VALUE) /drivers/cadence/emmc/cdns_sdmmc.c: 434 in card_reset() ________________________________________________________________________________________________________ *** CID 447121: Incorrect expression (UNUSED_VALUE) /drivers/cadence/emmc/cdns_sdmmc.c: 434 in card_reset() 428 uint32_t reg_value = 0; 429 430 /* Reading SRS10 value before writing */ 431 reg_value = mmio_read_32(cdns_params.reg_base + SDHC_CDNS_SRS10); 432 433 if (power_enable == true) { >>> CID 447121: Incorrect expression (UNUSED_VALUE) >>> Assigning value "4294963455U" to "reg_value" here, but that stored value is overwritten before it can be used. 434 reg_value &= ~((7 << SDMMC_CDN_BVS) | (1 << SDMMC_CDN_BP)); 435 reg_value = ((1 << SDMMC_CDN_BVS) | (1 << SDMMC_CDN_BP)); 436 } else { 437 reg_value &= ~((7 << SDMMC_CDN_BVS) | (1 << SDMMC_CDN_BP)); 438 } 439 mmio_write_32(cdns_params.reg_base + SDHC_CDNS_SRS10, reg_value); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2…

7 months, 1 week

1
0
0 0

Trusted Firmware-A LTS v2.10.9 Release Announcement

by ci_notify＠trustedfirmware.org

Hello, Trusted Firmware-A LTS version 2.10.9 is now available. This release contains the following patches: c4c6eae4e feat(cm): add errata 2938996, 2726228 [1] 33a04460d fix(cpus): modify the fix for Cortex-A75 erratum 764081 [2] [1] https://review.trustedfirmware.org/q/I53b037839820c8b3a869f393588302a365d5b… [2] https://review.trustedfirmware.org/q/Ifda1f4cb32bdec9a9af29397ddc03bf22a7a8… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.10.9/change-log.html Thanks, TF-A LTS team

7 months, 2 weeks

1
0
0 0

Trusted Firmware-A LTS v2.8.24 Release Announcement

by ci_notify＠trustedfirmware.org

Hello, Trusted Firmware-A LTS version 2.8.24 is now available. This release contains the following patches: 10cd41d91 feat(cm): add errata 2938996, 2726228 [1] 578d3577f fix(cpus): modify the fix for Cortex-A75 erratum 764081 [2] [1] https://review.trustedfirmware.org/q/I53b037839820c8b3a869f393588302a365d5b… [2] https://review.trustedfirmware.org/q/Ifda1f4cb32bdec9a9af29397ddc03bf22a7a8… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.8.24/change-log.html Thanks, TF-A LTS team

7 months, 2 weeks

1
0
0 0

Trusted Firmware-A LTS v2.10.8 Release Announcement

by ci_notify＠trustedfirmware.org

Hello, Trusted Firmware-A LTS version 2.10.8 is now available. This release contains the following patches: 9c723cd1a docs(prerequisites): update MbedTLS version to 3.6.1 [1] d3726fb42 refactor(mbedtls): remove hack in LIBMBEDTLS_CFLAGS [2] 34a4f2446 fix(cpus): workaround for Cortex-X4 erratum 3076789 [3] [1] https://review.trustedfirmware.org/q/I1a68dfcb52a8361c1689cb6ef12d265a6462f… [2] https://review.trustedfirmware.org/q/I934adefbf2fed16e16b9d98bc8674125b70b0… [3] https://review.trustedfirmware.org/q/Ib100bfab91efdb6330fdcdac127bcc5732d59… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.10.8/change-log.html Thanks, TF-A LTS team

7 months, 2 weeks

1
0
0 0

Trusted Firmware-A LTS v2.8.23 Release Announcement

by ci_notify＠trustedfirmware.org

Hello, Trusted Firmware-A LTS version 2.8.23 is now available. This release contains the following patches: 89c138ae8 docs(prerequisites): update MbedTLS version to 3.6.1 [1] 625207291 fix(cpus): workaround for Cortex-X4 erratum 3076789 [2] [1] https://review.trustedfirmware.org/q/I1a68dfcb52a8361c1689cb6ef12d265a6462f… [2] https://review.trustedfirmware.org/q/Ib100bfab91efdb6330fdcdac127bcc5732d59… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.8.23/change-log.html Thanks, TF-A LTS team

7 months, 3 weeks

1
0
0 0

Canceled event: TF-A Tech Forum @ Thu Oct 17, 2024 5pm - 6pm (GMT+2) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

This event has been canceled. TF-A Tech Forum Thursday Oct 17, 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. To stop receiving future updates for this event, decline this 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

7 months, 3 weeks

1
0
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 1 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 445539: High impact quality (WRITE_CONST_FIELD) /drivers/arm/dcc/dcc_console.c: 153 in console_dcc_register() ________________________________________________________________________________________________________ *** CID 445539: High impact quality (WRITE_CONST_FIELD) /drivers/arm/dcc/dcc_console.c: 153 in console_dcc_register() 147 .flush = dcc_console_flush, 148 }, 149 }; 150 151 int console_dcc_register(console_t *console) 152 { >>> CID 445539: High impact quality (WRITE_CONST_FIELD) >>> A write to an aggregate overwrites a const-qualified field within the aggregate. 153 memcpy(console, &dcc_console.console, sizeof(console_t)); 154 return console_register(console); 155 } 156 157 void console_dcc_unregister(console_t *console) 158 { 159 dcc_console_flush(console); 160 (void)console_unregister(console); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2…

7 months, 3 weeks

1
0
0 0

Kernel source for RAS error injection on neoverse reference design platform

by Nagal, Amit

Hi, I am referring to https://neoverse-reference-design.docs.arm.com/en/latest/features/ras/ras.h… for RAS error injection on neoverse reference design platform. I am referring to below steps : mount -t debugfs none /sys/kernel/debug # Step needed for Buildroot only echo 0x80020000 > /sys/kernel/debug/apei/einj/error_type echo 1 > /sys/kernel/debug/apei/einj/oem-einj/sel-firmware-first echo 1 > /sys/kernel/debug/apei/einj/oem-einj/sel-component echo 1 > /sys/kernel/debug/apei/einj/oem-einj/sel-error-type echo 1 > /sys/kernel/debug/apei/einj/error_inject I want to refer to kernel source driver which exposes attributes : sel-firmware-first , sel-component , sel-error-type. Also that driver must be doing the actual injections and registering sdei events with EL3 . can I be advised where to look in for kernel sources ? Regards Amit

7 months, 3 weeks

4
6
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 2 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 2 of 2 defect(s) ** CID 445362: Uninitialized variables (UNINIT) /drivers/st/ddr/phy/phyinit/src/ddrphy_phyinit_c_initphyconfig.c: 95 in atxslewrate_program() ________________________________________________________________________________________________________ *** CID 445362: Uninitialized variables (UNINIT) /drivers/st/ddr/phy/phyinit/src/ddrphy_phyinit_c_initphyconfig.c: 95 in atxslewrate_program() 89 uint32_t atxpredrvmode; 90 uint32_t c_addr; 91 uint16_t atxslewrate; 92 93 c_addr = anib << 12; 94 >>> CID 445362: Uninitialized variables (UNINIT) >>> Using uninitialized value "ck_anib_inst[0]". 95 if ((anib == ck_anib_inst[0]) || (anib == ck_anib_inst[1])) { 96 /* CK ANIB instance */ 97 #if STM32MP_DDR3_TYPE || STM32MP_DDR4_TYPE 98 atxpredrvmode = 0x0U; 99 #else /* STM32MP_LPDDR4_TYPE */ 100 atxpredrvmode = 0x1U; ** CID 445361: Control flow issues (DEADCODE) /drivers/st/ddr/phy/phyinit/src/ddrphy_phyinit_c_initphyconfig.c: 1021 in aforcetricont_acx4anibdis_program() ________________________________________________________________________________________________________ *** CID 445361: Control flow issues (DEADCODE) /drivers/st/ddr/phy/phyinit/src/ddrphy_phyinit_c_initphyconfig.c: 1021 in aforcetricont_acx4anibdis_program() 1015 #endif /* STM32MP_DDR3_TYPE || STM32MP_DDR4_TYPE */ 1016 1017 /* 1018 * If all the lanes can be disabled, and Anib is not the first or last disable 1019 * entire chiplet 1020 */ >>> CID 445361: Control flow issues (DEADCODE) >>> Execution cannot reach the expression "anib != 0U" inside this statement: "if (aforcetricont == 15U &&...". 1021 if ((aforcetricont == 0xFU) && (anib != 0U) && 1022 (anib != (config->uib.numanib - 1U))) { 1023 acx4anibdis = acx4anibdis | (0x1U << anib); 1024 } 1025 mmio_write_16((uintptr_t)(DDRPHYC_BASE + (4U * (TANIB | c_addr | 1026 CSR_AFORCETRICONT_ADDR))), ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2…

8 months

1
0
0 0

Introduction and Interest in Contributing to the TF-A Project

by omar elmasry

Dear TF-A Contributors, I hope this email finds you well. My name is Omar, and I am an Embedded Software Engineer at Valeo. I am excited to introduce myself to the Trusted Firmware-A community and look forward to contributing to the project. I have already enrolled in the mailing list and reviewed the documentation. I am passionate about technical deep dives and always eager to explore new areas. I am particularly interested in ARM-based projects, and I'm enthusiastic about getting involved with fellow geeks who share the same passion for cutting-edge technology. I would greatly appreciate any guidance on current tasks or areas where contributions are needed so I can start contributing effectively. Thank you for your time, and I look forward to collaborating with all of you! Best regards, Omar Embedded Software Engineer | Valeo (+20) 10 6962 8429

8 months

1
0
0 0

Trusted Firmware-A LTS v2.10.7 Release Announcement

by ci_notify＠trustedfirmware.org

Hello, Trusted Firmware-A LTS version 2.10.7 is now available. This release contains the following patches: 23b59a38b fix(cpus): workaround for Cortex-X4 erratum 2897503 [1] [1] https://review.trustedfirmware.org/q/I3178a890b6f1307b310e817af75f8fdfb8668… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.10.7/change-log.html Thanks, TF-A LTS team

8 months

1
0
0 0

Trusted Firmware-A LTS v2.8.22 Release Announcement

by ci_notify＠trustedfirmware.org

Hello, Trusted Firmware-A LTS version 2.8.22 is now available. This release contains the following patches: ac24f38b8 fix(cpus): workaround for Cortex-X4 erratum 2897503 [1] [1] https://review.trustedfirmware.org/q/I3178a890b6f1307b310e817af75f8fdfb8668… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.8.22/change-log.html Thanks, TF-A LTS team

8 months

1
0
0 0

Re: TF-A Tech Forum

by Olivier Deprez

Hi, Cancelling as no topic planned for today. Regards, Olivier. ________________________________ From: Trusted Firmware Public Meetings Sent: 24 July 2024 17:36 To: Trusted Firmware Public Meetings <linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com>; marek.bykowski(a)gmail.com <marek.bykowski(a)gmail.com>; okash.khawaja(a)gmail.com <okash.khawaja(a)gmail.com>; tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: TF-A Tech Forum When: 03 October 2024 17:00-18:00. Where: This event has been updated 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/<https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…> Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://linaro-org.zoom.us/my/trustedfirmware?pwd=VktXcm5MNUUyVVM4R0k3ZUtvd…<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fmy%2Ftruste…> 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-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> When Every 2 weeks from 8am to 9am on Thursday (Mountain Standard Time - Phoenix) Guests marek.bykowski(a)gmail.com<mailto:marek.bykowski@gmail.com> okash.khawaja(a)gmail.com<mailto:okash.khawaja@gmail.com> tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> View all guest info<https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…> RSVP for tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> for all events in this series Yes<https://calendar.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tM…> No<https://calendar.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tM…> Maybe<https://calendar.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tM…> More options<https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…> Invitation from Google Calendar<https://calendar.google.com/calendar/> You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this 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>

8 months, 1 week

1
0
0 0

Canceled event: TF-A Tech Forum @ Thu Oct 3, 2024 5pm - 6pm (GMT+2) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

This event has been canceled. TF-A Tech Forum Thursday Oct 3, 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. To stop receiving future updates for this event, decline this 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

8 months, 1 week

1
0
0 0

About the SDS usage model

by Deng Bob

Hi all, I am trying to raise a question about SDS. As you know, SDS (Shared data storage) is used to communicate or exhcange info among different processor units like AP, SCP, RSE, etc. So, do we need to add some lock mechanisms to protect the data when one processor entity is accessing it? After I reviewed the open source Trusted Firmware and SCP firmware it looks to me that both Trusted Firmware and SCP directly access the shared memory region without any limitation. Currently, it just uses the 'valid' flag to identify if the data is ready to use, is this good enough? Looking forwared to your response! Thank you!!! Best Regards, Bob

8 months, 1 week

2
2
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 1 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 445089: Control flow issues (DEADCODE) /drivers/st/pmic/stpmic2.c: 251 in stpmic2_regulator_levels_mv() ________________________________________________________________________________________________________ *** CID 445089: Control flow issues (DEADCODE) /drivers/st/pmic/stpmic2.c: 251 in stpmic2_regulator_levels_mv() 245 uint8_t id, const uint16_t **levels, 246 size_t *levels_count) 247 { 248 const struct regul_struct *regul = &regul_table[id]; 249 250 if (regul == NULL) { >>> CID 445089: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "return -3;". 251 return RET_ERROR_BAD_PARAMETERS; 252 } 253 254 if (levels_count != NULL) { 255 *levels_count = regul->volt_table_size; 256 } ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2…

8 months, 2 weeks

1
0
0 0

TF-A EL3 SPMC upgrade to FF-A Spec v1.2

by Belsare, Akshay

Hi Marc, In TF-A, the FF-A version is currently set to v1.2, but I am unable to find the corresponding implementation for EL3 SPMC configuration. I'm particularly interested in the support for FF-A Notification Mechanism. Could you please provide the timeline for when this will be added to the TF-A EL3 SPMC configuration? Thank You! Akshay Belsare

8 months, 2 weeks

2
2
0 0

PSA calls with RSE comms and MHU

by Yann Gautier

Hello, I would like to use PSA calls for an application on STM32MP2 platform. I've seen the psa_call() API that I could use, in drivers/arm/rse/rse_comms.c. The problem is that it is based on MHU mailbox, which I don't have on STM32MP2. So I was planning plan to disentangle RSE comms and MHU, having a new file in the same directory to manage MHU. This code should then be under a flag, I could re-use PLAT_MHU_VERSION. Setting it to 0, would mean no MHU. AFAICT TF-M uses that split with a dedicated file: rse_comms_hal.c: Abstracts MHU message sending and receiving. (see https://tf-m-user-guide.trustedfirmware.org/platform/arm/rse/rse_comms.html). Do you think this approach sounds right? Thanks, Yann

8 months, 2 weeks

4
5
0 0

Trusted Firmware-A LTS v2.8.21 Release Announcement

by ci_notify＠trustedfirmware.org

Hello, Trusted Firmware-A LTS version 2.8.21 is now available. This release contains the following patches: 75124503f fix(cpus): workaround for Cortex-X4 erratum 2816013 [1] dedcbb78e fix(cpus): workaround for Cortex-A720 erratum 2844092 [2] 9db99a3e4 fix(cpus): workaround for Cortex-A720 erratum 2792132 [3] a0a574d70 feat(cpus): workaround for Cortex-A520(2938996) and Cortex-X4(2726228) [4] d1f63aba2 fix(spm-mm): carve out NS buffer TZC400 region [5] 4220b8313 feat(fvp): add cpu power control [6] d9daf130c docs(fvp): update FVP versions used [7] [1] https://review.trustedfirmware.org/q/I546044bde6e5eedd0abf61643d25e2dd2036d… [2] https://review.trustedfirmware.org/q/I3d8eacb26cba42774f1f31c3aae2a0e6fecec… [3] https://review.trustedfirmware.org/q/I8d11fe65a2ab5f79244cc3395d0645f772563… [4] https://review.trustedfirmware.org/q/I8f886a1c21698f546a0996c719cc27dc0a236… [5] https://review.trustedfirmware.org/q/Idc3370803ad204ac29efeded77305e52e17cc… [6] https://review.trustedfirmware.org/q/Iba6c3c8db60dbeb177cead7ebc65df8265860… [7] https://review.trustedfirmware.org/q/Ie478b81b0f09d8664966cc1fac71a775a1a95… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.8.21/change-log.html Thanks, TF-A LTS team

8 months, 2 weeks

1
0
0 0

Trusted Firmware-A LTS v2.10.6 Release Announcement

by ci_notify＠trustedfirmware.org

Hello, Trusted Firmware-A LTS version 2.10.6 is now available. This release contains the following patches: 582b950ed fix(cpus): workaround for Cortex-X4 erratum 2816013 [1] 9d3934323 fix(cpus): workaround for Cortex-A720 erratum 2844092 [2] a93c69bbb fix(cpus): workaround for Cortex-A720 erratum 2792132 [3] 74fc9576d fix(spm-mm): carve out NS buffer TZC400 region [4] 9ca6bf389 feat(fvp): add cpu power control [5] e941b0e0f fix(arm_fpga): halve number of PEs per core [6] 47010ae9d feat(cpus): workaround for Cortex-A520(2938996) and Cortex-X4(2726228) [7] c1b976727 docs(fvp): update FVP versions used [8] [1] https://review.trustedfirmware.org/q/I546044bde6e5eedd0abf61643d25e2dd2036d… [2] https://review.trustedfirmware.org/q/I3d8eacb26cba42774f1f31c3aae2a0e6fecec… [3] https://review.trustedfirmware.org/q/I8d11fe65a2ab5f79244cc3395d0645f772563… [4] https://review.trustedfirmware.org/q/Idc3370803ad204ac29efeded77305e52e17cc… [5] https://review.trustedfirmware.org/q/Iba6c3c8db60dbeb177cead7ebc65df8265860… [6] https://review.trustedfirmware.org/q/Ieb37ccc9f362b10ff0ce038f72efca21512a7… [7] https://review.trustedfirmware.org/q/I8f886a1c21698f546a0996c719cc27dc0a236… [8] https://review.trustedfirmware.org/q/Ie478b81b0f09d8664966cc1fac71a775a1a95… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.10.6/change-log.html Thanks, TF-A LTS team

8 months, 2 weeks

1
0
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 1 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 445015: Control flow issues (UNREACHABLE) /mbedtls/library/psa_crypto_cipher.c: 250 in mbedtls_cipher_values_from_psa() ________________________________________________________________________________________________________ *** CID 445015: Control flow issues (UNREACHABLE) /mbedtls/library/psa_crypto_cipher.c: 250 in mbedtls_cipher_values_from_psa() 244 cipher_id_tmp = MBEDTLS_CIPHER_ID_CHACHA20; 245 break; 246 #endif 247 default: 248 return PSA_ERROR_NOT_SUPPORTED; 249 } >>> CID 445015: Control flow issues (UNREACHABLE) >>> This code cannot be reached: "if (cipher_id != NULL) { ...". 250 if (cipher_id != NULL) { 251 *cipher_id = cipher_id_tmp; 252 } 253 254 return mbedtls_cipher_validate_values(alg, key_type); 255 } ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2…

8 months, 2 weeks

1
0
0 0

Re: Canceled event: TF-A Tech Forum @ Thu Sep 19, 2024 5pm - 6pm (GMT+2) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

Hi, Cancelling today's Sep 19th instance as no topic proposed. Regards, Olivier. ________________________________ From: Trusted Firmware Public Meetings Sent: 24 July 2024 17:36 To: Trusted Firmware Public Meetings <linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com>; tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Canceled event: TF-A Tech Forum @ Thu Sep 19, 2024 5pm - 6pm (GMT+2) (tf-a(a)lists.trustedfirmware.org) When: 19 September 2024 17:00-18:00. Where: This event has been canceled. 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/<https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…> Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://linaro-org.zoom.us/my/trustedfirmware?pwd=VktXcm5MNUUyVVM4R0k3ZUtvd…<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fmy%2Ftruste…> 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-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> When Thursday Sep 19, 2024 ⋅ 5pm – 6pm (Central European Time - Paris) Guests tf-a(a)lists.trustedfirmware.org<mailto:tf-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. To stop receiving future updates for this event, decline this 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>

8 months, 3 weeks

1
0
0 0

Canceled event: TF-A Tech Forum @ Thu Sep 19, 2024 5pm - 6pm (GMT+2) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

This event has been canceled. TF-A Tech Forum Thursday Sep 19, 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. To stop receiving future updates for this event, decline this 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

8 months, 3 weeks

1
0
0 0

How to map a physical address using `mmap_add_dynamic_region_alloc_va`?

by 钱非凡

Hi experts, I tried to allocate a physical memory address in Linux Kernel, and pass the memory address to tf-a using smc call. As I asked in previous mails (https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.…), tf-a can not access the physical memory address directly, so I try to use the `mmap_add_dynamic_region_alloc_va` function in `xlat_table_v2` Library, and map the physical memory in tf-a. After calling the function, It does return a new virtual memory address, but I still failed to access the address, is there any details I have missed? Here is the code: ``` NOTICE("phys_addr: 0x%lx, virt_addr: 0x%lx\n", phys_addr, virt_addr); int rc = mmap_add_dynamic_region_alloc_va(phys_addr, ptr_virt_addr, size, MT_NS | MT_RW_DATA); if (rc) { WARN("Failed to map memory at 0x%lx: %d\n", phys_addr, rc); return; } NOTICE("virt_addr_el3: 0x%lx\n", virt_addr_el3); NOTICE("virt_addr_el3[0] = 0x%x\n", *((uint32_t *)virt_addr_el3)); ``` Here is the output: ``` NOTICE: phys_addr: 0x40f0000, virt_addr: 0xffff0000040f0000 NOTICE: mm.base_va: 0 NOTICE: mm.base_va: 100000000 NOTICE: virt_addr_el3: 0x100000000 [ 38.540464] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: [ 38.546584] rcu: 4-...0: (1 ticks this GP) idle=4224/1/0x4000000000000000 softirq=125/125 fqs=2625 [ 38.555651] (detected by 0, t=5252 jiffies, g=-779, q=16 ncpus=8) [ 38.561843] Task dump for CPU 4: [ 38.565075] task:main state:R running task stack:0 pid:195 ppid:181 flags:0x00000002 [ 38.575015] Call trace: [ 38.577464] __switch_to+0xe4/0x160 [ 38.580975] 0x42 ``` I would be grateful for any advice or suggestions you may have. Sincerely, Feifan

8 months, 3 weeks

2
1
0 0

Canceled event with note: TF-A Tech Forum @ Thu Sep 5, 2024 5pm - 6pm (GMT+2) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

This event has been canceled with a note: "Hi, Cancelling as no topic this week. Thanks & Regards, Olivier. " TF-A Tech Forum Thursday Sep 5, 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. To stop receiving future updates for this event, decline this 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

9 months

1
0
0 0

Can't start new thread in website

by 林觀明

Hi I have a question. But, I can't launch a new thread. Can you help me? Thanks

9 months

1
0
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 6 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 1 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 6 of 6 defect(s) ** CID 443168: Error handling issues (CHECKED_RETURN) /plat/st/stm32mp2/bl2_plat_setup.c: 183 in bl2_el3_plat_arch_setup() ________________________________________________________________________________________________________ *** CID 443168: Error handling issues (CHECKED_RETURN) /plat/st/stm32mp2/bl2_plat_setup.c: 183 in bl2_el3_plat_arch_setup() 177 BL_CODE_END - BL_CODE_BASE, 178 MT_CODE | MT_SECURE); 179 180 configure_mmu(); 181 182 /* Prevent corruption of preloaded Device Tree */ >>> CID 443168: Error handling issues (CHECKED_RETURN) >>> Calling "mmap_add_dynamic_region" without checking return value (as is done elsewhere 25 out of 29 times). 183 mmap_add_dynamic_region(DTB_BASE, DTB_BASE, 184 DTB_LIMIT - DTB_BASE, 185 MT_RO_DATA | MT_SECURE); 186 187 if (dt_open_and_check(STM32MP_DTB_BASE) < 0) { 188 panic(); ** CID 443167: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /plat/rockchip/rk3588/drivers/scmi/rk3588_clk.c: 578 in rk3588_b0pll_get_rate() ________________________________________________________________________________________________________ *** CID 443167: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /plat/rockchip/rk3588/drivers/scmi/rk3588_clk.c: 578 in rk3588_b0pll_get_rate() 572 573 rate64 *= m; 574 rate64 = rate64 / p; 575 576 if (k != 0) { 577 /* fractional mode */ >>> CID 443167: Integer handling issues (OVERFLOW_BEFORE_WIDEN) >>> Potentially overflowing expression "24000000U * k" with type "unsigned int" (32 bits, unsigned) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "uint64_t" (64 bits, unsigned). 578 uint64_t frac_rate64 = 24000000 * k; 579 580 postdiv = p * 65535; 581 frac_rate64 = frac_rate64 / postdiv; 582 rate64 += frac_rate64; 583 } ** CID 443166: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 443166: Memory - corruptions (OVERRUN) /plat/intel/soc/common/socfpga_vab.c: 97 in socfpga_vab_authentication() 91 if (!IS_BYTE_ALIGNED(img_sz, sizeof(uint32_t))) { 92 ERROR("Image size (%d bytes) not aliged to 4 bytes!\n", img_sz); 93 return -EIMGERR; 94 } 95 96 /* Generate HASH384 from the image */ >>> CID 443166: Memory - corruptions (OVERRUN) >>> Overrunning array "hash384" of 12 bytes by passing it to a function which accesses it at byte offset 47. 97 sha384_start((uint8_t *)img_addr, img_sz, hash384, CHUNKSZ_PER_WD_RESET); 98 cert_hash_ptr = (uint8_t *)(img_addr + img_sz + VAB_CERT_MAGIC_OFFSET + 99 VAB_CERT_FIT_SHA384_OFFSET); 100 101 /* 102 * Compare the SHA384 found in certificate against the SHA384 ** CID 443165: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /plat/rockchip/rk3588/drivers/scmi/rk3588_clk.c: 747 in rk3588_b1pll_get_rate() ________________________________________________________________________________________________________ *** CID 443165: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /plat/rockchip/rk3588/drivers/scmi/rk3588_clk.c: 747 in rk3588_b1pll_get_rate() 741 742 rate64 *= m; 743 rate64 = rate64 / p; 744 745 if (k != 0) { 746 /* fractional mode */ >>> CID 443165: Integer handling issues (OVERFLOW_BEFORE_WIDEN) >>> Potentially overflowing expression "24000000U * k" with type "unsigned int" (32 bits, unsigned) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "uint64_t" (64 bits, unsigned). 747 uint64_t frac_rate64 = 24000000 * k; 748 749 postdiv = p * 65535; 750 frac_rate64 = frac_rate64 / postdiv; 751 rate64 += frac_rate64; 752 } ** CID 443164: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /plat/rockchip/rk3588/drivers/scmi/rk3588_clk.c: 408 in rk3588_lpll_get_rate() ________________________________________________________________________________________________________ *** CID 443164: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /plat/rockchip/rk3588/drivers/scmi/rk3588_clk.c: 408 in rk3588_lpll_get_rate() 402 403 rate64 *= m; 404 rate64 = rate64 / p; 405 406 if (k != 0) { 407 /* fractional mode */ >>> CID 443164: Integer handling issues (OVERFLOW_BEFORE_WIDEN) >>> Potentially overflowing expression "24000000U * k" with type "unsigned int" (32 bits, unsigned) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "uint64_t" (64 bits, unsigned). 408 uint64_t frac_rate64 = 24000000 * k; 409 410 postdiv = p * 65535; 411 frac_rate64 = frac_rate64 / postdiv; 412 rate64 += frac_rate64; 413 } ** CID 254051: Memory - illegal accesses (OVERRUN) /plat/intel/soc/common/lib/sha/sha.c: 206 in sha512_base_do_finalize() ________________________________________________________________________________________________________ *** CID 254051: Memory - illegal accesses (OVERRUN) /plat/intel/soc/common/lib/sha/sha.c: 206 in sha512_base_do_finalize() 200 const int bit_offset = SHA512_BLOCK_SIZE - sizeof(uint64_t[2]); 201 uint64_t *bits = (uint64_t *)(sctx->buf + bit_offset); 202 unsigned int partial = sctx->count[0] % SHA512_BLOCK_SIZE; 203 204 sctx->buf[partial++] = 0x80; 205 if (partial > bit_offset) { >>> CID 254051: Memory - illegal accesses (OVERRUN) >>> Overrunning array of 128 bytes at byte offset 128 by dereferencing pointer "sctx->buf + partial". [Note: The source code implementation of the function has been overridden by a builtin model.] 206 memset(sctx->buf + partial, 0x0, SHA512_BLOCK_SIZE - partial); 207 partial = 0; 208 209 sha512_block_fn(sctx, sctx->buf, 1); 210 } 211 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2…

9 months, 1 week

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-A