- TF-A - lists.trustedfirmware.org

TF-A Tech Forum on June 26th 2025 - Building Modern Industrial SoC Support in Arm Trusted Firmware

by Olivier Deprez

Hi, In the TF-A Tech forum on June 26th 2025 Dhruva Gole from Texas Instruments will present: Building Modern Industrial SoC Support in Arm Trusted Firmware Pragmatic Approaches to Power and Clock Management Regards, Olivier. TF-A Tech Forum Thursday Jun 26, 2025 ⋅ 5pm – 6pm 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… Trusted Firmware is inviting you to a scheduled Zoom meeting.Topic: TF-A Tech ForumTime: May 15, 2025 02:00 PM London Every 2 weeks on Thu, 78 occurrence(s)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 Guests tf-a(a)lists.trustedfirmware.org

1 year

2
2
0 0

Trusted Firmware-A LTS v2.12.4 Release Announcement

by svc_openci_enginfra＠arm.com

Hello, Trusted Firmware-A LTS version 2.12.4 is now available. This release contains the following patches: e21418b78 feat(errata): implement workaround for DSU-120 erratum 2900952 [1] 648b4f34f fix(cpus): remove accidental alto cpu addition [2] 68453765e feat(cpus): update cpu_check_csv2 check [3] [1] https://review.trustedfirmware.org/q/I87aa440ab5c35121aff703032f5cf7a62d0b0… [2] https://review.trustedfirmware.org/q/I04cb5394a8caf32a69775e6236cb9c09aadf7… [3] https://review.trustedfirmware.org/q/I8473047ed4ad759b7b506161a76774ac21555… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.12.4/change-log.html Thanks, TF-A LTS team

1 year

1
0
0 0

Trusted Firmware-A LTS v2.10.18 Release Announcement

by svc_openci_enginfra＠arm.com

Hello, Trusted Firmware-A LTS version 2.10.18 is now available. This release contains the following patches: 7323c2d9d feat(errata): implement workaround for DSU-120 erratum 2900952 [1] 39e7f4a7c feat(cpus): update cpu_check_csv2 check [2] [1] https://review.trustedfirmware.org/q/I87aa440ab5c35121aff703032f5cf7a62d0b0… [2] https://review.trustedfirmware.org/q/I8473047ed4ad759b7b506161a76774ac21555… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.10.18/change-log.html Thanks, TF-A LTS team

1 year

1
0
0 0

Trusted Firmware-A LTS v2.8.34 Release Announcement

by svc_openci_enginfra＠arm.com

Hello, Trusted Firmware-A LTS version 2.8.34 is now available. This release contains the following patches: 3a299d0bf feat(errata): implement workaround for DSU-120 erratum 2900952 [1] ae330d547 feat(cpus): update cpu_check_csv2 check [2] [1] https://review.trustedfirmware.org/q/I87aa440ab5c35121aff703032f5cf7a62d0b0… [2] https://review.trustedfirmware.org/q/I8473047ed4ad759b7b506161a76774ac21555… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.8.34/change-log.html Thanks, TF-A LTS team

1 year

1
0
0 0

TF-A - sError Queries

by Jaiprakash Singh

Hi, I have below queries regarding nested sError handling in TF-A, please help. 1. While handling exceptions in EL3, sError is almost unmask most of the time. Any specific reason to keep sError unmasked? For example, while handing nested sError, we can keep sError masked in serror_sp_elx. So that no further sError comes to EL3. And unmask sError when returning to lower ELs. Do you think this will create any problem in the system? 1. In system, sError can happen at any time. At EL3, we have nested sError handling in serror_sp_elx. Do you think we should have similar nested sError handling in serror_sp_el0? If not, what is the reason? 1. Double fault will always lead to unhandled exception. * Can someone help define double fault scenario? * What is the purpose of this patch - https://github.com/ARM-software/arm-trusted-firmware/commit/c72200357aed49f…<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ARM-2Dsoftw…> Is purpose only to save esr_el3 register? Thanks Regards, Jaiprakash 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.

1 year

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. 5 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 5 of 5 defect(s) ** CID 472149: Integer handling issues (NEGATIVE_RETURNS) _____________________________________________________________________________________________ *** CID 472149: Integer handling issues (NEGATIVE_RETURNS) /lib/psci/psci_main.c: 300 in psci_affinity_info() 294 * - the cluster was removed from coherency as part of the CPU shutdown 295 * 296 * In this case the cache maintenace that was performed as part of the 297 * target CPUs shutdown was not seen by the current CPU's cluster. And 298 * so the cache may contain stale data for the target CPU. 299 */ >>> CID 472149: Integer handling issues (NEGATIVE_RETURNS) >>> "target_idx" is passed to a parameter that cannot be negative. 300 flush_cpu_data_by_index(target_idx, 301 psci_svc_cpu_data.aff_info_state); 302 303 return psci_get_aff_info_state_by_idx(target_idx); 304 } 305 ** CID 472148: Memory - corruptions (OVERRUN) _____________________________________________________________________________________________ *** CID 472148: Memory - corruptions (OVERRUN) /lib/psci/psci_main.c: 39 in psci_cpu_on() 33 34 /* Validate the target CPU */ 35 if (!is_valid_mpidr(target_cpu)) { 36 return PSCI_E_INVALID_PARAMS; 37 } 38 >>> CID 472148: Memory - corruptions (OVERRUN) >>> Overrunning callee's array of size 2 by passing argument "target_idx" (which evaluates to 4294967295) in call to "_cpu_data_by_index". 39 ep = get_cpu_data_by_index(target_idx, warmboot_ep_info); 40 /* Validate the lower EL entry point and put it in the entry_point_info */ 41 rc = psci_validate_entry_point(ep, entrypoint, context_id); 42 if (rc != PSCI_E_SUCCESS) { 43 return rc; 44 } ** CID 472147: (OVERRUN) _____________________________________________________________________________________________ *** CID 472147: (OVERRUN) /lib/psci/psci_main.c: 300 in psci_affinity_info() 294 * - the cluster was removed from coherency as part of the CPU shutdown 295 * 296 * In this case the cache maintenace that was performed as part of the 297 * target CPUs shutdown was not seen by the current CPU's cluster. And 298 * so the cache may contain stale data for the target CPU. 299 */ >>> CID 472147: (OVERRUN) >>> Overrunning callee's array of size 2 by passing argument "target_idx" (which evaluates to 4294967295) in call to "_cpu_data_by_index". 300 flush_cpu_data_by_index(target_idx, 301 psci_svc_cpu_data.aff_info_state); 302 303 return psci_get_aff_info_state_by_idx(target_idx); 304 } 305 /lib/psci/psci_main.c: 303 in psci_affinity_info() 297 * target CPUs shutdown was not seen by the current CPU's cluster. And 298 * so the cache may contain stale data for the target CPU. 299 */ 300 flush_cpu_data_by_index(target_idx, 301 psci_svc_cpu_data.aff_info_state); 302 >>> CID 472147: (OVERRUN) >>> Overrunning callee's array of size 2 by passing argument "target_idx" (which evaluates to 4294967295) in call to "psci_get_aff_info_state_by_idx". 303 return psci_get_aff_info_state_by_idx(target_idx); 304 } 305 306 int psci_migrate(u_register_t target_cpu) 307 { 308 int rc; ** CID 472146: Memory - corruptions (OVERRUN) _____________________________________________________________________________________________ *** CID 472146: Memory - corruptions (OVERRUN) /lib/el3_runtime/aarch64/context_debug.c: 107 in report_allocated_memory() 101 if (is_ctx_pauth_supported()) { 102 PRINT_SINGLE_MEM_USAGE_SEP_BLOCK(); 103 } 104 105 PRINT_MEM_USAGE_SEPARATOR(); 106 >>> CID 472146: Memory - corruptions (OVERRUN) >>> Overrunning callee's array of size 2 by passing argument "i" (which evaluates to 7) in call to "cm_get_context_by_index". 107 cpu_context_t *ctx = (cpu_context_t *)cm_get_context_by_index(i, 108 security_state_idx); 109 core_total = sizeof(*ctx); 110 el3_size = sizeof(ctx->el3state_ctx); 111 gp_size = sizeof(ctx->gpregs_ctx); 112 size_other = core_total - (el3_size + gp_size); ** CID 472145: Integer handling issues (NEGATIVE_RETURNS) _____________________________________________________________________________________________ *** CID 472145: Integer handling issues (NEGATIVE_RETURNS) /lib/psci/psci_main.c: 39 in psci_cpu_on() 33 34 /* Validate the target CPU */ 35 if (!is_valid_mpidr(target_cpu)) { 36 return PSCI_E_INVALID_PARAMS; 37 } 38 >>> CID 472145: Integer handling issues (NEGATIVE_RETURNS) >>> "target_idx" is passed to a parameter that cannot be negative. 39 ep = get_cpu_data_by_index(target_idx, warmboot_ep_info); 40 /* Validate the lower EL entry point and put it in the entry_point_info */ 41 rc = psci_validate_entry_point(ep, entrypoint, context_id); 42 if (rc != PSCI_E_SUCCESS) { 43 return rc; 44 } ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://scan.coverity.com/projects/arm-software-arm-trusted-firmware?tab=ov…

1 year, 1 month

1
0
0 0

TF-A Tech Forum on June 12th 2025 - TF-RMM live activation

by Olivier Deprez

Hi, On June 12th 2025, the TF-A Tech forum will take place at 4.00pm UK with the following topic: TF-RMM live activation design discussion Presenters: Andre Przywara Soby Mathew Manish Badarkhe In this meeting, we aim to discuss the details of live firmware activation for TF-RMM. The key topics will include: * Design details of TF-RMM live activation * Rationale for EL3-RMM communication changes: We will explain the motivation behind the proposed changes to the communication mechanism between EL3 and RMM which simplifies internal state migration for LFA, enables sharing of the state across RMM instances that are live-activated, supports localized per-CPU allocations for NUMA and multi-chip configurations, decouples the RMM binary from platform-specifics. * LFA SMC Implementation in EL3: We will also provide an overview of the LFA SMC implementation at EL3. Regards, Olivier. TF-A Tech Forum Thursday Jun 12, 2025 ⋅ 5pm – 6pm 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… Trusted Firmware is inviting you to a scheduled Zoom meeting.Topic: TF-A Tech ForumTime: May 15, 2025 02:00 PM London Every 2 weeks on Thu, 78 occurrence(s)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 Guests tf-a(a)lists.trustedfirmware.org

1 year, 1 month

2
1
0 0

FVP_Base_Cortex-A520 crash

by shaunak saha

Hi All, I'm new to TF-A. While working on enabling Linux on A-520 FVP, I ran into an issue that I wanted to ask about. My stack looks like this:TF-A->U-boot->kernel. Initially I was able to boot on Base FVP(FVP_Base_RevC-2xAEMvA) and get to the linux console. Now we need to enable the same for A-520 FVP as our soc will be A-520. I saw the crash happening very early in "cpu_helpers.S. I made the change in plat/arm/board/fvp/platform.mk by adding lib/cpus/aarch64/cortex_a520.S in one of the FVP_CPU_LIBS and enabling the ERRATA_A520_2938996, ERRATA_A520_2858100 and ERRATA_A520_2630792. These changes helped me get past the TF-A and now i ' m seeing a crash inside kernel in pci. 16.720973] pci-host-generic 40000000.pci: host bridge /pci@40000000 ranges: [ 16.721375] pci-host-generic 40000000.pci: MEM 0x0050000000..0x005fffffff -> 0x0050000000 [ 16.722013] pci-host-generic 40000000.pci: ECAM at [mem 0x40000000-0x4fffffff] for [bus 00-ff] [ 16.723128] pci-host-generic 40000000.pci: PCI host bridge to bus 0000:00 [ 16.723461] pci_bus 0000:00: root bus resource [bus 00-ff] [ 16.723761] pci_bus 0000:00: root bus resource [mem 0x50000000-0x5fffffff] [ 16.724101] Internal error: synchronous external abort: 0000000096000010 [#1] SMP [ 16.724216] Modules linked in: [ 16.724302] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.15.0-rc7-dirty #12 PREEMPT [ 16.724449] Hardware name: FVP Base RevC (DT) [ 16.724531] pstate: 214000c9 (nzCv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 16.724666] pc : pci_generic_config_read+0x38/0xb8 [ 16.724802] lr : pci_generic_config_read+0x24/0xb8 [ 16.724939] sp : ffff80008272b940 [ 16.725012] x29: ffff80008272b940 x28: 0000000000000000 x27: ffff800081dc00b0 [ 16.725205] x26: ffff800081ec9060 x25: ffff800081ec9078 x24: ffff80008266a9a0 [ 16.725401] x23: 0000000000000000 x22: ffff80008272b9f4 x21: ffff000800fa8000 [ 16.725594] x20: ffff80008272b964 x19: 0000000000000004 x18: 0000000000000006 [ 16.725781] x17: 6666666666663478 x16: 302d303030303030 x15: ffff800082edbbbf [ 16.725980] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 16.726166] x11: 0000000000000001 x10: 3ea1f6d484b7e318 x9 : 69631046f78aed23 [ 16.726355] x8 : ffff000800169108 x7 : ffff800082250960 x6 : 00000000000000ff [ 16.726547] x5 : 0000000000000000 x4 : 0000000000000000 x3 : ffff800090000000 [ 16.726738] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff800090000000 Do i need to do enable somethign else in TF-A? I tried adding : pci: pci@40000000 { compatible = "pci-host-ecam-generic"; device_type = "pci"; bus-range = <0x0 0xff>; reg = <0x0 0x40000000 0x0 0x10000000>; ranges = <0x2000000 0x0 0x50000000 0x0 0x50000000 0x0 0x10000000>; }; in plat/arm/board/fvp/fdts/fvp_soc_fw_config.dts but it does not help. Also I see the kernel is not able to bring all the cpu's online: [ 0.040364] smp: Bringing up secondary CPUs ... [ 5.116993] CPU1: failed to come online [ 5.117063] CPU1: failed in unknown state : 0x0 [ 10.266076] CPU2: failed to come online [ 10.266152] CPU2: failed in unknown state : 0x0 [ 15.415178] CPU3: failed to come online [ 15.415247] CPU3: failed in unknown state : 0x0 [ 15.421021] psci: failed to boot CPU4 (-22) [ 15.421099] CPU4: failed to boot: -22 [ 15.425045] psci: failed to boot CPU5 (-22) [ 15.425123] CPU5: failed to boot: -22 [ 15.429079] psci: failed to boot CPU6 (-22) [ 15.429157] CPU6: failed to boot: -22 [ 15.433153] psci: failed to boot CPU7 (-22) [ 15.433227] CPU7: failed to boot: -22 [ 15.433587] smp: Brought up 1 node, 1 CPU [ 15.433672] SMP: Total of 1 processors activated. [ 15.433746] CPU: All CPU(s) started at EL2 I’m still getting familiar with the codebase and community, so apologies if this has already been addressed. I’d really appreciate any guidance or pointers, and if this is a known issue or good for a first-time contributor, I’d be happy to help. Regards, Shaunak

1 year, 1 month

2
2
0 0

Trusted Firmware-A LTS v2.8.33 Release Announcement

by svc_openci_enginfra＠arm.com

Hello, Trusted Firmware-A LTS version 2.8.33 is now available. This release contains the following patches: a95dba188 build(npm): adhere to Husky deprecation notice [1] fc3a26e5f fix(deps): remove deprecated husky commands [2] a96d034d0 fix(cpus): drop esb from the Neoverse N1 [3] 3bd1d85f1 chore(docs): add a SBOM template in CycloneDX format [4] [1] https://review.trustedfirmware.org/q/I18ea1bbaedbb4213cc04c21413d75c9757ff7… [2] https://review.trustedfirmware.org/q/I8b7fa82aa7b5e178554a1b4a650b2b1b80440… [3] https://review.trustedfirmware.org/q/I5775180ec61373cc5d1b9831e3fa0f2fbb19e… [4] https://review.trustedfirmware.org/q/Ia34338854a0eaa4f3a8799c23e46aae382792… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.8.33/change-log.html Thanks, TF-A LTS team

1 year, 1 month

1
0
0 0

Planned Jenkins migration - Friday 30 May 2025, 14:30-18:30 BST

by Chris Kay

Hi folks, We are planning on going live with the migration of the TF.org Open CI tomorrow, Friday 30th May, which will migrate Jenkins (ci.trustedfirmware.org) from on-premises to cloud-managed infrastructure. We expect a downtime of 2-4 hours beginning at 14:30 GMT+1, during which anything which interacts with Jenkins will be unavailable. Please note that the Jenkins build history is not being transferred - if you have Gerrit changes in review with the Allow-CI+1/+2 label, you will need to retrigger the CI once migration is complete by reapplying the label. We will send out a follow-up email once we have restored service availability. Regards, Chris

1 year, 1 month

1
1
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-A