Hello,
I am a TF-A firmware developer currently working on the Arm Neoverse RD-V3-R1 reference design, and I am in the process of porting and validating Hafnium (SPMC, TF-A BL32) on this platform.
On RD-V3-R1, we are using secure_rdv3r1_clang as the Hafnium target platform configuration.
However, I noticed that secure_rdv3r1_clang does not appear in the list of supported Hafnium platforms (or reference build targets) in the upstream repository.
Could you please clarify the following?
Is secure_rdv3r1_clang an officially supported target configuration for Hafnium?
If not, is there a plan to support it upstream in the future, or is there an alternative recommended target for RD-V3-R1 secure builds?
If there is an official/recommended build configuration for RD-V3-R1 in the upstream Hafnium project, I would appreciate any guidance.
Thank you very much for your time and support.
Best regards,
Seongju Yoo
Hi,
We are pleased to announce the formal release of Trusted Firmware-A version 2.14 bundle of project deliverables.
This includes Trusted Firmware-A, Trusted Firmware-A Tests, Hafnium, TF-RMM, Trusted Services, and TF-A OpenCI scripts/jobs components.
These went live on Nov, 24th 2025.
Please find tag references 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.14 are as follows:
TF-A/EL3
* New architectural features support: FEAT_FGWTE3, FEAT_IDTE3, FEAT_RME_GPC2, FEAT_AIE, FEAT_CPA2, FEAT_MPAM_PE_BW_CTRL, FEAT_PFAR, FEAT_RME_GDI.
*
Live Firmware Activation: base support enabling TF-RMM LFA, added RMM MEM RESERVE ABI.
*
Armv9 CPU power down abandon support
* GICv5 driver permitting normal world kernel boot
* GIC720-AE support added
* Per-cpu framework supporting NUMA platforms
* SMCCC SoC name support (SMCCC v1.6 SMCCC_ARCH_SOC_ID)
* SPMD: added FF-A v1.3 FFA_NS_RES_INFO_GET, FFA_ABORT interfaces
* EL3 SPMC: add multiple UUIDs support, TPM event log delivered by HOB list, FFA_MEM_RETRIEVE_REQ from hypervisor
* RME: FEAT_D128 for realm world, SMCCC_ARCH_FEATURE_AVAILABILITY
* Platforms: RD-Aspen added, updates to Arm FVP/Juno, AMD Versal Gen2, Intel, MT8189, MT8196, i.MX94, i.MX95, S32G274A, QTI Kodiak, Renesas R-Car, STM32MP1, STM32MP2, STM32MP21, STM32MP25, Xilinx Versal, ZynqMP
Boot flow
* Transfer list and event log libraries now offered as shared libraries consumed as submodules by TF-A.
* Update to mbedTLS 3.6.5
* Various PSA FWU improvements, namely BL2 in a dedicated FIP, GPT-corruption notifications to BL32, and expanded FWU tests.
Errata/Security mitigations (CPU/GIC)
* New CPU support: Arm Lumex C1, Dionysus, Caddo/Veymont, Venom.
* Added close to 30 new CPU errata across multiple processor families, based on the latest SDEN updates.
Hafnium/SPM (S-EL2)
* FF-A v1.3 early adoption
* FFA_NS_RES_INFO_GET ABI added
* Partition lifecycle support: new states, abort handling. Pre-requisite to secure partitions live firmware activation.
* Notifications support refactored with per-vCPU notifications removed.
* Multi-GIC configuration supporting complex topologies.
* Shrinkwrap used at core of Hafnium testing infrastructure.
TF-RMM (R-EL2)
* RMM v1.1 Planes support
* PMU, timer, GIC ownership transfer.
* Support for FEAT_S1POE/S1PIE, FEAT_S2POE/S2PIE
* RMM v1.1 Memory Encryption Contexts (MEC) support
* Realm Device Assignment
* RMM v1.1. ALP12 base Device Assignment support
* RMI VDEV ABIs, PDEV life cycle, root port IDE key programming, SPDM client as EL0 app.
* Improved ID registers trapping leveraging SMCCC ARCH_FEATURE_AVAILABILITY, in light of future FEAT_IDTE3 support.
* Additional architectural support: FEAT_TCR2, FEAT_D128, single-copy atomics,
TF-A Tests
*
RME: DA and PCIe, Planes, MEC
*
SPM/FF-A
* Bumped support o FF-A v1.3
* FFA_ABORT ABI
* Deprecated per-vCPU notifications.
* FWU: added negative testing (invalid image size, corrupted ROTPK)
* GICv5 support added
* Arm architecture tests
* FEAT_TCR2 (for RME) , FEAT_IDTE3, FEAT_MPAM_PE_BW_CTRL, FEAT_EBEP, FEAT_AIE, FEAT_PFAR
* SMCCC_ARCH_SOC_ID
* SMCCC_ARCH_FEATURE_AVAILABILITY
* Fuzzing: added SMC fuzzer documentation
* Basic LFA framework tests
* Platforms updates: AMD/Xilinx, Arm FVP, Corstone-1000
Trusted Services
* RD-Aspen platform support added.
* EFI ESRT handling in FWU Proxy (supporting Corstone1000 platform).
* Block Storage service threat modelling.
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.14.0/change-log.html#id1https://trustedfirmware-a-tests.readthedocs.io/en/v2.14.0/change-log.html#v…https://hafnium.readthedocs.io/en/v2.14.0/change-log.html#id1https://tf-rmm.readthedocs.io/en/tf-rmm-v0.8.0/about/change-log.html#v0-8-0https://git.trustedfirmware.org/plugins/gitiles/TS/trusted-services/+/refs/…
Regards,
Olivier.
Hello,
I'm Junho Choi in Samsung S.LSI and I've been working on virtualization
solution.
I have some questions about Hafnium for Secure EL2 extension.
(1) Why do you consider VHE as default option? (I saw it in
arch_mm_init)
According to Hafnium init sequence, has_vhe_support always returns
true as long as ARM cores have support for VHE.
Is there any requirements that Hafnium should support VHE?
(2) TF-A's SPMD has only forwarded svc_on_finish and svc_off of PSCI.
Why doesn't SPMD forward other commands such as CPU_SUSPEND?
In case of the CPU_SUSPEND, secure EL2 or SP may need to know when
physcial CPU turns off.
(3) Why do you set HCR_EL2.VI and VF to handle virtual interrupt?
I think we have an another method to use List registers
(ICH_LRn_EL2) to inject virtual interrup to guest (SP).
I'm not sure whether asking you is proper or not.
If you're not the right person, please forward this mail to the right
person.
Thanks!
Best Regards,
Junho Choi
[cid:cafe_image_0@s-core.co.kr]
[update?userid=junhosj.choi&do=bWFpbElEPTIwMjUxMTE4MDU1MTQ0ZXBjbXMycDUy
MjBlZTFkOGFiNGIxNGRkYzQ1MTNiN2E2ZTA3NzM2MyZyZWNpcGllbnRBZGRyZXNzPWhhZm5
pdW1AbGlzdHMudHJ1c3RlZGZpcm13YXJlLm9yZw__]
TF-A Tech Forum - Hafnium future looking improvements
Thursday Nov 13, 2025 ⋅ 12pm – 1pm
Central European Time - Paris
Location
https://linaro-org.zoom.us/j/93557863987?pwd=56a1l8cBnetDTZ6eazHGaE1Ctk4W34…https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9355786…
Hi, This is a one off session for a partner to present coming improvements
related to Hafnium project. Apologies for the meeting time not
accommodating people in US timezones. We'll record the session and publish
in the TF-A tech forum page as usual. Regards,Olivier.Trusted Firmware is
inviting you to a scheduled Zoom meeting.Please download and import the
following iCalendar (.ics) files to your calendar
system.Weekly: https://linaro-org.zoom.us/meeting/tJcocu6gqDgjEtOkyBhSQauR1sUyFwIcNKLa/ics…
Zoom
Meetinghttps://linaro-org.zoom.us/j/93557863987?pwd=56a1l8cBnetDTZ6eazHGaE1Ctk4W34.1Meeting
ID: 935 5786 3987Passcode: 939141---One tap
mobile+12532158782,,93557863987# US (Tacoma)+13017158592,,93557863987# US
(Washington DC)---Dial by your location• +1 253 215 8782 US (Tacoma)• +1
301 715 8592 US (Washington DC)• +1 305 224 1968 US• +1 309 205 3325 US• +1
312 626 6799 US (Chicago)• +1 346 248 7799 US (Houston)• +1 360 209 5623
US• +1 386 347 5053 US• +1 507 473 4847 US• +1 564 217 2000 US• +1 646 558
8656 US (New York)• +1 646 931 3860 US• +1 669 444 9171 US• +1 669 900 9128
US (San Jose)• +1 689 278 1000 US• +1 719 359 4580 US• +1 253 205 0468 US•
833 548 0276 US Toll-free• 833 548 0282 US Toll-free• 833 928 4608 US
Toll-free• 833 928 4609 US Toll-free• 833 928 4610 US Toll-free• 877 853
5247 US Toll-free• 888 788 0099 US Toll-freeMeeting ID: 935 5786 3987Find
your local number: https://linaro-org.zoom.us/u/adoz9mILli
Reply for hafnium(a)lists.trustedfirmware.org and view more details
https://calendar.google.com/calendar/event?action=VIEW&eid=MDdmMGs0NjBkcW5q…
Your attendance is optional.
~~//~~
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
All,
Please be aware that today we have published our AI policy with Guidance on
AI-assisted contributions.
See the full details here: https://www.trustedfirmware.org/aipolicy/
Should you have any questions feel free to raise them.
Thanks,
Shaun
Community Manager
Hi All,
The next release of the Firmware-A bundle of projects tagged v2.12 has an expected code freeze date of Nov, 8th 2024.
Refer to the release cadence section from TF-A documentation (https://trustedfirmware-a.readthedocs.io/en/latest/about/release-informatio…).
Closing out the release takes around 6-10 working days after the code freeze.
v2.12 release preparation tasks start from now.
We want to ensure that planned feature patches for the release are submitted in good time for the review process to conclude.
As a kind recommendation and a matter of sharing CI resources, please launch CI jobs with care e.g.:
-For simple platform, docs changes, or one liners, use Allow-CI+1 label (no need for a full Allow-CI+2 run).
-For large patch stacks use Allow-CI+2 at top of the patch stack (and if required few individual Allow+CI+1 labels in the middle of the patch stack).
-Carefully analyze results and fix the change if required, before launching new jobs on the same change.
-If after issuing a Allow-CI+1 or Allow-CI+2 label a Build start notice is not added as a gerrit comment on the patch right away please be patient as under heavy load CI jobs can be queued and in extreme conditions it can be over an hour before the Build start notice is issued. Issuing another Allow-CI+1 or Allow-CI+2 label will just result in an additional job being queued.
--
Thanks,
Govindraj R
Hi All,
We will be performing maintenance activity on review.trustedfirmware.org and service will be unavailable on 8th November between 8 AM-11 AM UTC.
Best regards,
Saheer
Hi All,
The next release of the Firmware-A bundle of projects tagged v2.13 has an expected code freeze date of May, 2nd 2025.
In order to accommodate the Linaro connect event occurring during the week of May 12th we may extend the release completion date up until the week of May 26th.
v2.13 release preparation tasks start from now.
We want to ensure that planned feature patches for the release are submitted in good time for the review process to conclude.
As a kind recommendation and a matter of sharing CI resources, please launch CI jobs with care e.g.:
-For simple platform, docs changes, or one liners, use Allow-CI+1 label (no need for a full Allow-CI+2 run).
-For large patch stacks use Allow-CI+2 at top of the patch stack (and if required few individual Allow+CI+1 labels in the middle of the patch stack).
-Carefully analyze results and fix the change if required, before launching new jobs on the same change.
-If after issuing a Allow-CI+1 or Allow-CI+2 label a Build start notice is not added as a gerrit comment on the patch right away please be patient as under heavy load CI jobs can be queued and in extreme conditions it can be over an hour before the Build start notice is issued. Issuing another Allow-CI+1 or Allow-CI+2 label will just result in an additional job being queued.
Regards,
Olivier.
