FYI
From: Saheer Babu via Tf-openci <tf-openci(a)lists.trustedfirmware.org>
Date: Wednesday, 10 September 2025 at 15:17
To: tf-openci(a)lists.trustedfirmware.org <tf-openci(a)lists.trustedfirmware.org>
Subject: [Tf-openci] CI infrastructure scheduled maintenance: 12th Sep 2025
Hi all,
We will be performing upgrade of the clusters hosting review.trustedfirmware.org and ci.trustedfirmware.org on Friday, 12th Sep 2025 at 16:00 GMT+1.
During this maintenance window, both services will be unavailable for approximately 4 hours.
A follow-up email will be sent once the services are fully restored.
Best regards,
Saheer
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.
--
Tf-openci mailing list -- tf-openci(a)lists.trustedfirmware.org
To unsubscribe send an email to tf-openci-leave(a)lists.trustedfirmware.org
Hi,
Sona Rebecca Mathew will present on the TF-RMM ID registers management scheme at the TF-A Tech Forum tomorrow. Her presentation is expected to take place during the second half of the one-hour session.
Abstract:
* Earlier RMM directly read ID registers, creating a dependency on EL3 revisions to enable features forcing a version compatibility between the two.
* New approach: EL3 capabilities are queried via an SMC call and RMM now uses cached ID register copies populated at cold boot. Includes forward-looking support for FEAT_IDTE3 in TF-A.
For meeting details, please refer to the TF-A Tech Forum email here : https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.…
Best Regards
Soby Mathew
Hi Everyone,
We've merged the final batch of outstanding patches for Alp-12-based DA foundation support in RMM: TF-RMM Commit bd2eb59<https://github.com/TF-RMM/tf-rmm/commit/bd2eb596ca0739c8051badefde34993e24f…>
This completes the fourth and final merge in the series, incorporating support for DVSEC and IDE key programming. With this, the refactoring of the Alp-12 branch to the EL0 app framework is now complete.
(Some quick stats: over 60 patches and >13K lines of code changed.)
While the current base support has several limitations that we plan to address in the coming months including:
1. Initial SMMU Stage 2 driver
2. Updated IDE key programming flow
3. Alp-16 migration groundwork
4. Multi PDEV/VDEV support
5. Validation of PDEV , VDEV params and improved testing from TFTF.
With the base DA support now in place, RMM is ready to accept contributions to further improve Device assignment support.
Best Regards
Soby Mathew
Hi Everyone
We have pushed a Design document for TF-RMM Live Firmware Activation for wider discussion : https://github.com/TF-RMM/tf-rmm/wiki/RFC:-TF‐RMM-Live-Firmware-Activation
An initial implementation of the design is available for review here : https://review.trustedfirmware.org/q/topic:"rmm-lfa<https://review.trustedfirmware.org/q/topic:%22rmm-lfa>"
This patch series had to undergo a lot of design changes mainly around Stage 1 xlat management. Some of the changes were done anticipating upcoming feature like Flexible memory management in RMM specification.
We hope to schedule a separate design review session discussing the same. Please let us know of feedback or comments in the meantime.
Best Regards
Soby Mathew
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
