+TF-RMM ML
________________________________
From: Google Calendar <calendar-notification(a)google.com> on behalf of Olivier Deprez <olivier.deprez(a)arm.com>
Sent: 17 January 2025 08:46
To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>; Olivier Deprez <Olivier.Deprez(a)arm.com>
Subject: TF-A Tech Forum - Jan 23rd 2025 - RMM design of EL0 applications support
Hi,
On Jan 23rd 2025, in the TF-A Tech forum, Mate Toth-Pal and Soby Mathew will present the RMM design of EL0 applications support.
The TF-A Tech forum is a regular open forum for anyone from the open source community to participate. Feel free to reach if you have a topic you'd want to present. It can be a design review with slides, walking through RFC patches, or more generic discussion around open source projects.
Regards,
Olivier.
TF-A Tech Forum
Thursday Jan 23, 2025 ⋅ 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/<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…>
Guests
tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi,
As a follow up to the Firmware-A v2.12 release [1], we are pleased to share the shrinkwrap tool [2]
configurations have been updated to consume latest firmware/upstream ingredients using following tags:
TF-A: v2.12.0
TF-a-tests: v2.12.0
Hafnium: v2.12.0
TF-RMM: tf-rmm-v0.6.0
CCA EDK2: 3223_arm_cca_rmm_v1.0_rel0_v3
linux: cca-full/v5+v7
kvmtool: cca/v3
An additional merge request is in queue for kvm-unit-tests update to cca/rmm-v1.0-rel0 tag.
Shrinkwrap is a convenient tool for building a fully integrated Arm CCA SW stack running on
the Base AEM FVP platform. In particular this is the tool of choice for RMM development to
reproduce a 3 or 4 worlds RME based environment.
Regards,
Olivier.
[1] https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.…
[2] https://shrinkwrap.docs.arm.com/en/latest/
Hi Everyone,
In order to facilitate development for Device Assignment tests for RME-DA, we have added MbedTLS repo as a submodule dependency to tf-a-tests. The merge commit can be found here : https://review.trustedfirmware.org/plugins/gitiles/TF-A/tf-a-tests/+/3e72cd…
The patch is done in such a way that existing build of TF-A-Tests or Test run is not affected due to the additional dependency. Only tests which depend on MbedTLS will be affected in that they will either be skipped or fail at runtime due to the missing dependency. Also, the change allows to use the config `MBEDTLS_DIR` to point to a MbedTLS directory outside the tf-a-tests source tree. This aligns with the TF-A mechanism for MbedTLS dependancy in case the submodule mechanism is not preferred.
We expect existing CI and testing infrastructure to be unaffected by this change. Please let us know if you have any comments.
Best Regards
Soby Mathew
Hi Everyone
We are planning to change how TF-RMM clones and updates the submodule dependencies. The usual practice is to specify the `recursive` option to git clone of the project. This works well when the submodules themselves do not have dependencies. For some dependent repositories like libspdm, there are further dependencies like openssl, cmocka which are not used in the RMM context. Hence specifying the specifying the `recursive` option is not the ideal solution especially when RMM is deployed in Continuous integration solutions. The above issue was worked around in RMM by fetching libspdm within the build context but this was also not ideal as it kept the libspdm outside the git submodules framework and the git fetch was done every time the project was rebuilt.
To solve this, we are proposing to move the management of the submodules into the build system and away from the user. Specifically, during configuration phase of the project, cmake will issue `git submodule update --init --depth 1`.
This means that the user will not be responsible for syncing the submodules anymore and the build system will take of this. This also ties in with the patching method of the build system as a particular SHA can be ensured before the patch is applied.
The patch can be found here : https://review.trustedfirmware.org/c/TF-RMM/tf-rmm/+/33512
Any rebase of the project which updates the submodules will now be transparently applied without the user having to update the submodules manually.
We think that we will have more dependent submodules for TF-RMM in the future and it is better to script this within the build system. This change should not break any of the existing CI systems as it is backward compatible, but it may become a little inefficient if the `recursive` option is specified as there will be unnecessary git repositories fetched.
Please let us know if any comments.
Best Regards
Soby Mathew
hello tf-rmm group,
Recently I'm learning ARM CCA.But I have trouble running the latest version TF-RMM.It failed at runtime/ core/ init.c/ in func rmm_arch_init.When try to do write_hcrx_el2 action it paniced.So it looks like the FVP doesn't have the hcrx_el2 register.I'm using the FVP_Base_RevC-2xAEMvA_11.27_19. It's the latest version in the arm's offical website.The tf-rmm-v0.5.0 works fine.So I'm wondering how do you test latest version TF-RMM.It would be appreciated if you could reply.
Best,
Wang.
Hi All,
In preparation to the Firmware-A v2.12 bundle release the following TF-A/TF-A-tests/Hafnium/RMM/CI project tags were applied:
https://git.trustedfirmware.org/TF-A/trusted-firmware-a/+/refs/tags/v2.12-r…https://git.trustedfirmware.org/tf-a-tests/+/refs/tags/v2.12-rc0https://git.trustedfirmware.org/ci/tf-a-ci-scripts/+/refs/tags/v2.12-rc0https://git.trustedfirmware.org/ci/tf-a-job-configs/+/refs/tags/v2.12-rc0https://git.trustedfirmware.org/hafnium/hafnium.git/+/refs/tags/v2.12-rc0https://git.trustedfirmware.org/ci/hafnium-ci-scripts.git/+/refs/tags/v2.12…https://git.trustedfirmware.org/ci/hafnium-job-configs.git/+/refs/tags/v2.1…https://git.trustedfirmware.org/TF-RMM/tf-rmm/+/refs/tags/tf-rmm-v0.6.0-rc0
Trees are frozen still accepting security or bug fixes until the release close down happening end next week (hopefully!).
For partners, it will help if tests are run against those trees on downstream platforms and spot any issue hit before the final tagging.
--
Thanks,
Govindraj R
________________________________
From: Govindraj Raja via TF-A-Tests <tf-a-tests(a)lists.trustedfirmware.org>
Sent: Monday, October 14, 2024 20:18
To: Joanna Farley via TF-A <tf-a(a)lists.trustedfirmware.org>; tf-a-tests(a)lists.trustedfirmware.org <tf-a-tests(a)lists.trustedfirmware.org>
Cc: hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org>; tf-rmm(a)lists.trustedfirmware.org <tf-rmm(a)lists.trustedfirmware.org>; trusted-services(a)lists.trustedfirmware.org <trusted-services(a)lists.trustedfirmware.org>
Subject: [Tf-a-tests] Firmware-A v2.12 release code freeze notification
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
--
TF-A-Tests mailing list -- tf-a-tests(a)lists.trustedfirmware.org
To unsubscribe send an email to tf-a-tests-leave(a)lists.trustedfirmware.org
+ other MLs
________________________________
From: Olivier Deprez
Sent: 30 October 2024 11:41
To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>
Subject: TF-A Tech Forum regular call
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.
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
