- TF-A - lists.trustedfirmware.org

TF-A Tech Forum @ April 2, 2026

by Scaria Kochidanadu

Hi, this is Scaria Kochidanadu, from Texas Instruments and would like to present : "s2idle-driven Low Power Mode Selection using PSCI on AM62L", in the TF-A tech forum on April 2nd, 2026. We present a runtime-configurable low power mode(LPM) management approach for *PSCI* firmware in ATF, implemented on the AM62L SoC, a 2-core system with A53 cores. The primary goal of this session is to gather feedback on the *suitability of this design for upstreaming*, and to get guidance on key challenges encountered during implementation before proceeding with further debugging and optimization. In this design, we transition to an *s2idle-based flow* where Linux cpuidle framework and governor drive idle state selection, from the multiple platform-specific standby and low power modes that are provided in the devicetree. The PSCI driver in ATF is then responsible for the validation of the idle-states passed and the entire suspend-resume flow, with the *Operating-System Initiated (OSI) mode in PSCI*. As ATF now handles the full suspend-resume flow, it has the responsibility of managing the powering down and bringing up of the cores, along with the state of the system. We observe issues related to core *coordination in a multi-core system*, as well as system state management during resume, including *GIC* and (*Interrupt Translation Service*)ITS context handling. In this session, we will present our suspend and resume design in the AM62L PSCI implementation and discuss these challenges in detail. We would also like to discuss the *current validation logic* for the context-preserving retention states like standby and our approach to enable standby mode. We are particularly interested in feedback on whether this *OS-driven LPM selection model aligns with ATF design expectations*, and on recommended approaches for handling *inter-core coordination and system state restoration within PSCI-based flows*. Regards, Scaria Kochidanadu, Texas Instruments.

22 hours, 18 minutes

1
0
0 0

Re: RMMv2.0 implementation plan for TF-RMM

by Soby Mathew

[+ TF-A list for FYI] Hi All, An update on v2.0 migration. As RMM and the rest of the software stack are being prepared for the initial v2.0 migration, TF-A has introduced a new build configuration flag, RMM_V1_COMPAT, to control the world-switch behaviour between RMM v1.x and RMM v2.0 [1] . This flag is enabled by default, meaning the default behaviour currently corresponds to RMM v1.x. Once TF-RMM is ready to merge the v2.0 support, the default value of this flag will be changed to 0. The flag also updates the EL3–RMM interface major version, allowing incompatibility with TF-A related to this build configuration to be detected at runtime. We expect the initial v2.0 changes in TF-RMM to be merged by the end of this month. As mentioned in the previous email, we will create a v1.x branch prior to this and provide an update here. [1] https://git.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/+/r… Best regards, Soby Mathew From: Soby Mathew via tf-rmm <tf-rmm(a)lists.trustedfirmware.org> Date: Thursday, 5 February 2026 at 09:42 To: tf-rmm(a)lists.trustedfirmware.org <tf-rmm(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [tf-rmm] RMMv2.0 implementation plan for TF-RMM Hi Everyone, The RMM v2.0 Beta 0 specification has been published here: https://developer.arm.com/documentation/den0137/latest/ As you may have noticed, this release introduces breaking changes to the RMI APIs (host side), while the RSIs (guest side) remain backward compatible. Nearly all ABIs are affected, and the scope of these changes makes it highly disruptive to maintain support for both RMI v1.x and RMI v2.0 within the same codebase. We do not expect RMI v1.x to be deployed in production, and retaining support for it would increase development overhead and the risk of introducing bugs. A more pragmatic approach is to branch the current RMM codebase at the RMI v1.x ABI and then migrate the mainline to the RMI v2.0 ABI. This will be a breaking change for host-side components that rely on the older RMI ABI. Given the extent of the ABI changes, significant effort will be required to align with RMI v2.0, and this approach allows the team to focus on upstreaming the new ABI support efficiently. The initial RMI v2.0 upstreaming will consist of a series of commits that together form an initial RMM implementation targeting the RMM v2.0 specification. This initial implementation will not be fully feature-complete with respect to the v2.0 spec, and we expect to continue layering additional RMM v2.0 ABI-related changes on top as the implementation matures during the course of the year. That said, we intend to maintain integration with an externally available, compatible Linux host kernel branch throughout this process. The initial RMI v2.0 RMM implementation will be compatible with an initial v2.0-based host kernel, and we will notify the mailing list once this integration is available to pick up (likely end of March ’26). If and when we need to introduce further ABI changes that break compatibility with a previously published kernel branch, we will call this out explicitly in advance and indicate when an updated kernel branch will be available for integration. We plan to keep RMI v1.x ABI as a separate branch and selectively merge bug fixes on a request or need basis. Please let us know if you have any concerns regarding this plan within the next two weeks. Best Regards Soby Mathew

4 days, 13 hours

1
1
0 0

Trusted Firmware-A LTS v2.12.11 Release Announcement

by svc_openci_enginfra＠arm.com

Hello, Trusted Firmware-A LTS version 2.12.11 is now available. This release contains the following patches: f8013b344 fix(security): add workaround for CVE-2025-0647 [1] 72301cc63 fix(security): add CVE-2025-0647 for Cortex-A710 [2] 69437f876 fix(security): add CVE-2025-0647 for Cortex-X2 [3] 48df3fd66 fix(security): add CVE-2025-0647 for Cortex-X3 [4] b2534f255 fix(security): add CVE-2025-0647 for Cortex-X4 [5] 9776ee7aa fix(security): add CVE-2025-0647 for Cortex-X925 [6] 723c2ec2c fix(security): add CVE-2025-0647 for Neoverse-N2 [7] 3d8da003c fix(security): add CVE-2025-0647 for Neoverse-V2 [8] 6232ed263 fix(security): add CVE-2025-0647 for Neoverse-V3 [9] 12e155e47 fix(security): add CVE-2025-0647 for C1-Ultra [10] c43bcc1e3 fix(cpus): correct CVE-2024-7881 workaround and drop duplicate erratum [11] 306acbd96 fix(cpus): remove C1-Ultra erratum 3651221 [12] 4cd3b2f8d fix(cpus): workaround for Cortex-A65AE erratum 1638571 [13] f80d2e80d fix(cpus): add missing add_erratum_entry [14] 8f9b4f2f9 fix(cpus): workaround for Cortex-A76 erratum 1165347 [15] 24056d15a fix(cpus): workaround for Cortex-A76 erratum 1207823 [16] 0a6f09f42 fix(cpus): update revisions for Cortex-A76 erratum 1946160 [17] 89a7ef458 fix(cpus): reorder docs for Cortex-A76 erratum 1165522 [18] a811bf47d fix(cpus): correct comments for Cortex-A720 erratum 3711910 [19] 59f718e59 refactor(cpus): make errata reporting more generic [20] 8dde508cc perf(cpus): reduce the footprint of errata reporting [21] d61856ce5 fix(cpus): enable Neoverse-V2 external LLC support [22] 7cc23b58b feat(locks): add non-blocking spinlock_try() API [23] f6b942b2c fix(locks): mark spin_trylock as a public function [24] [1] https://review.trustedfirmware.org/q/I5e7589afbeb69ebb79c01bec80e29f572aff3… [2] https://review.trustedfirmware.org/q/I522dedfffd3108f7a94df1ce2cabd742ce682… [3] https://review.trustedfirmware.org/q/Idba607340d944a6387759c856e8eacc967e0e… [4] https://review.trustedfirmware.org/q/Ic276befafc1ca0b456826532437ca453eb771… [5] https://review.trustedfirmware.org/q/I585a7ea516515fe16a3eca907695728068cef… [6] https://review.trustedfirmware.org/q/I4c1ac2be3620566813c90f5815ffcc7205bb5… [7] https://review.trustedfirmware.org/q/I366c2683cca22403d33f0761487e1ffa62e96… [8] https://review.trustedfirmware.org/q/I7ec215a9dd168eb045366b589a02b54148f58… [9] https://review.trustedfirmware.org/q/Ic52ad93474c5f81e01eb4839ece726c84c334… [10] https://review.trustedfirmware.org/q/I506007ec8702b183e377be50eede72d6803b3… [11] https://review.trustedfirmware.org/q/I6207c49486e4020f34c862ad40ec3137bd368… [12] https://review.trustedfirmware.org/q/If7ea433e4614f92333e788e3f6b366db22c92… [13] https://review.trustedfirmware.org/q/I861230de94a105fd52f9c8ef7e7551a2633c0… [14] https://review.trustedfirmware.org/q/I19a484c73ac31a90b3ff1b219f647c88a1c81… [15] https://review.trustedfirmware.org/q/If9817dc26d0df835d749f506de63a4f613735… [16] https://review.trustedfirmware.org/q/Ife06401f3946884872b733f98c08e61f586d8… [17] https://review.trustedfirmware.org/q/I532ce10c3037dd77e31d7df849beb578f8b5e… [18] https://review.trustedfirmware.org/q/I2e7c05d6355dfbaa69170fc098adc1f12edc6… [19] https://review.trustedfirmware.org/q/I8b070927c19c5982b2ded815e7673e0c4ff11… [20] https://review.trustedfirmware.org/q/I83710d8475a4a55046cf2eb6d16cd27b8ef0f… [21] https://review.trustedfirmware.org/q/I215a84bd2c91e33703349c41fc59f654f7764… [22] https://review.trustedfirmware.org/q/I9582c7405db6862e77db240822e241d408296… [23] https://review.trustedfirmware.org/q/I9483206952d1a34dc245ebf69e80c3645b658… [24] https://review.trustedfirmware.org/q/Id264a36490707a9377a221ed2b5bd27ca90bf… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.12.11/change-log.html Thanks, TF-A LTS team

5 days, 10 hours

1
0
0 0

SCMI clock v3.0: Unannounced breaking change in v2.14

by Ahmad Fatoum

Hi, Commit 684952d17275 ("feat(scmi): add support for discovering and changing parent clocks") first introduced with TF-A v2.14 breaks the barebox bootloader on a STM32MP157-based MC-1 with SCMI clocks over SMC. The breakage for SCMI consumers is acknowledged in the Gerrit discussion[1], but unfortunately the resolution was limited to patching U-Boot[2]. I find this approach problematic, because it introduces a compatibility break for the whole SCMI ecosystem, e.g. following software is made incompatible with the newest TF-A this way: - Linux v6.6 and earlier (that's four official LTS releases) - U-Boot v2025.10 and earlier (only one newer release compatible) - barebox v2026.03.1 and earlier (no compatible releases yet) Firmware and kernel, and to a lesser degree firmware and bootloaders, are not always updated or rolled back in lockstep. A very normal scenario: - System with Linux v6.6 updates to newer LTS, e.g. v6.12 or v6.18 - In the same update, TF-A v2.14 is installed - New system fails to function for whatever reason - Kernel update is rolled back, but bootloader/firmware stays the same - Kernel v6.6 fails to boot with TF-A v2.14 - Technician moves out to unbrick device in the field At the very least, marking this feature a breaking change would have been appropriate. Preferably, TF-A would handle existing consumers using SCMI clock v3.0. I haven't looked into the technical feasibility myself and I am unsure it this had been considered. I will submit patches for the barebox bootloader, but these only solve the problem for new systems or ones where everything can be flashed at once with no rollback. Systems out in the field are at risk of bricking if not resolved properly. [1]: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/34226 [2]: https://lore.kernel.org/u-boot/20251104-b4-scmi-v1-v4-0-51f101a6f8c3@ti.com/ Thanks, Ahmad -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |

6 days, 20 hours

1
0
0 0

BERT Record Erase Only After Kernel Consumes

by Jaiprakash Singh

Hi All, BERT (Boot Error Record Table) captures errors which occurred in previous boot. Below is the Flow with FFH (firmware first handling) 1. Kernel is running 2. Fatal error happens, which requires reboot 3. Firmware decides to reboot system, before that capture current snapshot and save it as bert record on non-volatile memory 4. System reboot 5. On next boot, firmware read bert record from non-volatile memory 6. Copy bert record to ghes dram buffer 7. Kernel boots 8. Kernel reads ghes dram buffer and prints bert record. Problem in this flow is "When firmware should erase or delete bert records from non-volatile memory"? Ideally, when Kernel has consumed Bert record after that only firmware should erase them from non-volatile memory. But there is no communication from Kernel to firmware that it has consume bert record and now it is safe to erase them. Is there already a solution for this problem available in Kernel or firmware? Can generic SMC call from Kernel to firmware be a solution? Any other suggestion? Thanks Regards, Jaiprakash

1 week, 6 days

4
7
0 0

GIC v4.1 (GIC 700) - USE_GIC_DRIVER=3

by Jaiprakash Singh

Hi, We are using GIC v4.1 (GIC 700) for our platform. My query is regarding "USE_GIC_DRIVER=3" build option. When I enable "USE_GIC_DRIVER=3" option, does this means I do not have to defined below functions? And they will be included from gicv3 base file? Is this right understanding? plat_arm_gic_init plat_arm_gic_cpuif_enable plat_arm_gic_cpuif_disable plat_arm_gic_pcpu_init plat_arm_gic_redistif_on plat_arm_gic_redistif_off plat_arm_gic_save plat_arm_gic_resume Also, do I need to explicitly call plat_arm_gic_init from platform init? Thanks Regards, Jaiprakash

2 weeks, 5 days

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. 298 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 1 of 1 defect(s) ** CID 501830: Uninitialized variables (UNINIT) /drivers/nxp/ddr/s32cc/ddr_init.c: 43 in load_ddr_config() _____________________________________________________________________________________________ *** CID 501830: Uninitialized variables (UNINIT) /drivers/nxp/ddr/s32cc/ddr_init.c: 43 in load_ddr_config() 37 config.pie = (struct regconf_16 *)(current_addr + ddr_layout.pie_offset); 38 config.imem_1d = (uint16_t *)(current_addr + ddr_layout.imem_1d_offset); 39 config.dmem_1d = (uint16_t *)(current_addr + ddr_layout.dmem_1d_offset); 40 config.imem_2d = (uint16_t *)(current_addr + ddr_layout.imem_2d_offset); 41 config.dmem_2d = (uint16_t *)(current_addr + ddr_layout.dmem_2d_offset); 42 >>> CID 501830: Uninitialized variables (UNINIT) >>> Using uninitialized value "config". Field "config.phy_csr" is uninitialized. 43 return config; 44 } 45 46 /* Initialize ddr controller with given settings. */ 47 static uint32_t ddrc_init_cfg(const struct ddrss_config *config) 48 { ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://scan.coverity.com/projects/arm-software-arm-trusted-firmware?tab=ov…

2 weeks, 6 days

1
0
0 0

Kernel freezes at boot (commit fa28b3a)

by Thomas Bonnefille

Hello, I'm currently working on an NXP i.MX93 and I'm having issues with the commit fa28b3a adding, by default, link-time optimization. When using a commit more recent than fa28b3a my kernel freezes at some point (after 1.2s to 1.8s from boot), there are no logs indicating a problem, just a freeze. It doesn't always appear at the same time in boot but I've never been able to reach a shell. Using master with this commit reverted results in a working system. If you want to reproduce the issue, I did produce it with : - Mainline Barebox 2025.09 (slightly modified but nothing that should interfere with TF-A) - Mainline Linux 6.18.13 with a simple embedded Buildroot initramfs loaded via TFTP Regards, Thomas Bonnefille

2 weeks, 6 days

3
6
0 0

Why can TF-A code still run in an address space that it itself has set to be "Execute-Never"?

by Hughard

*Environment:* - *Exception Level:* EL3 (AArch64) - *Component:* [image: 微信图片_20260304154227_69_553.png] ARM Trusted Firmware (TF-A) - BL2/BL31 - *Platform:* Arm FVP / Base_Revc_2xAEMvA / Bare Metal Debug /ARMAEM-A_MP_0 [ Arm Development Studio ] *Observation:* I am observing a strange thing of the ARMv8-A architecture's memory translation rules. Despite the translation table explicitly marking the memory region as Execute-Never, the CPU continues to fetch and execute instructions from this region without triggering an exception. I'm a student with limited hardware background, and I'm learning TF-A and doing porting during my internship. I'd really like to know the reason behind this. *Code I use:* ARM Trusted Firmware v2.13 *Github:* github.com/.../arm-trusted-firmware <https://github.com/ARM-software/arm-trusted-firmware> *Take the case of running BL31 in Development Studio as an example. （Breakpoint at the beginning of bl31_setup）* *Technical Evidence (Verified via Debugger):* SCTLR_EL3: M=1 (MMU enabled), WXN=1 (Write implies execute-never), I=1 (Instruction Cache enabled). BL31’s code is loaded at: 0x04003000 Translation Table Entry (L3 Descriptor): 0x00400000_04003743 Physical Address: Verified via TTBR0_EL3 walk. (0x04034600 -> 0x04035003 -> 0x04037003 -> 0x00400000_04003743) Attributes: AP[2:1]=0x1 (Read/Write), XN=1 (Execute-Never), AF=1, SH=0x3 (Inner Shareable), NS=0, AttrIndx = 0x0 (See the MAIR_EL3) MAIR_EL3: 0x4404FF (Attr0 = 0xFF, Normal Memory). Synchronization Performed: DSB SY + ISB The PC (Program Counter) is confirmed to executing from the first instruction of BL31 code at address 0x04003000. *The Problem:* This evidence should point to one conclusion: it cannot execute the BL31 code and will report an error. However, the execution flow remains uninterrupted. From my point of view, it should cause "ESR_EL3 = 0x8600000F", which means: "Instruction Abort taken without a change in Exception level. Used for MMU faults generated by instruction accesses and synchronous External aborts, including synchronous parity or ECC errors. Not used for debug-related exceptions." + "Permission Fault, level 3". As I test on a real fpga by using similar code by making some changes at the end of BL1 so that it would execute BL2 at level EL3 (but instead of bl2_el3_entrypoint.S, it would execute bl2_entrypoint.S). In this case, it throws an error when it jumps to the first instruction of BL2, and the ESR_EL3 register displays "Permission Fault, level 3". If I add the instruction to disable the MMU (setting SCTLR_EL3.M_BIT to 0) at the end of BL1, and change the function to enable the MMU in the official code "arm_bl2_plat_arch_setup" to use "enable_mmu_el3(0)", it can run normally on the FPGA and bring up the UEFI. (In this real-world test, I used DDR instead of SRAM, so BL2 and BL31 were also placed here after being parsed.) *Request for Help:* The above content is beyond my comprehension; even my internship supervisor doesn't understand the reasoning behind it. Therefore, I need help from the experts on this forum. *Reference:* DDI0487M_a_a-profile_architecture_reference_manual.pdf ARM Development Studio@Docs (such as Docs/ARM_A/xhtml/AArch64-esr_el3.html) armv8_a_address_translation version1.1

3 weeks, 4 days

1
0
0 0

Subject: [RFC] Physical Sovereignty: M2-Layer Intercept Logic (Verilog) & Formal Verification Request [Patent Pending]

by 王毛

Since there was no specific topic scheduled for today's Tech Forum, I am taking this opportunity to formally submit the Verilog-level implementation logic of the 3→M2→3 architecture for your review. I am an independent architect (ATI Project). I believe purely software-based AGI alignment is a dead end. To achieve deterministic safety, I have developed the 3→M2→3 architecture, which enforces a physical-layer audit.To save your time, I have included the Core Logic Gate (Verilog-style) of the M2-layer intercept below for your verification: // --- ATI Sovereign Audit Logic (Conceptual) --- module m2_layer_audit ( input wire [63:0] inst_stream, // Logic from 3nm Layer output reg sovereign_gate_lock // Physical Bias-Lock at M2 ); // Physical Constant Hash (7.83Hz Resonance) parameter SOVEREIGN_HASH = 64'h783A_B026_M2_3_LISA; always @(posedge inst_stream) begin // The M2 Intercept: Physics-based verification if (inst_stream ^ SOVEREIGN_HASH !== 64'b0) begin sovereign_gate_lock <= 1'b1; // Trigger Back-gate Bias Lock end else begin sovereign_gate_lock <= 1'b0; // Proceed to Output end end endmodule Note: The architectural logic and the M2-layer intercept mechanism described above are protected under pending patent applications (ATI Project - Physical Sovereignty Series). The 3→M2→3 Workflow: 1.3nm Source: Instructions generated at the device layer. 2.M2 Intercept: Mandatory vertical routing to Metal 2 layer. 3.Atomic Audit: Physical bias check at the dielectric junction. 4.3nm Return: Bias lock ensures 100% isolation if the audit fails. My Request: Can current formal methods (like Gröbner basis for Daniela or SMT solvers for Lee) model this physical-layer-enforced constraint to provide a mathematical proof of AGI containment? I seek your academic endorsement of this "Physical Sovereignty" paradigm to present to the industry. This disclosure is provided for verification and standard-review purposes only. All intellectual property rights are reserved. Respectfully, GuanghuiMao (China )

3 weeks, 5 days

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-A