TF-A April 2026

tf-a@lists.trustedfirmware.org

4 participants
6 discussions

Canceled event with note: TF-A Tech Forum @ Thu Apr 30, 2026 5pm - 6pm (GMT+2) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

This event has been canceled with a note: "No topic for this week. Regards, Olivier. " TF-A Tech Forum Thursday Apr 30, 2026 ⋅ 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 qwandor(a)google.com praan(a)google.com jeremimiller(a)google.com jagdish.gediya(a)linaro.org khilman(a)baylibre.com tf-a(a)lists.trustedfirmware.org ~~//~~ 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

1 week, 4 days

Re: [PATCH] fix(st): reset SoC instead of panic() on MMC init failure

by Yann Gautier

Hello, Thanks for the patch and the detailed commit message. For ST boards, we usually treat this kind of issues with watchdog. But I admit some watchdogs patches are still missing upstream. I'll try to send them soon. We are discussing internally to see if this particular use-case could be done as you proposed. I'll get back to you next week about this, when one of my colleagues comes back. Maybe this could be selected with a compilation flag. About the patch submission, TF-A uses gerrit, and we do not merge patches from mailing-list like Linux does. Please check this page: https://trustedfirmware-a.readthedocs.io/en/latest/process/contributing.html Best regards, Yann On 4/29/26 05:21, Chanhong Jung wrote: > A failed eMMC initialization in BL2's boot_mmc() currently calls > panic(), leaving the system spinning forever and forcing an external > power cycle to recover. In production deployments where the eMMC is > the on-board boot medium, transient init failures (power-rail ramp > timing, bus-line noise just after eMMC fast-boot mode entry, RCC > clock-domain settling jitter, etc.) are far more common than hard > failures, and the recovery path for all of them is "boot again from > cold." > > Invoke stm32mp_system_reset() before panic() in the > stm32_sdmmc2_mmc_init() failure path so the SoC restarts and BootROM > re-runs the entire boot chain from scratch. Transient failures that > clear themselves between cold boots are then resolved automatically > without operator intervention. > > stm32mp_system_reset() carries the __dead2 (no-return) attribute, so > control never reaches the following panic() in normal operation. The > panic() call is intentionally retained for two reasons: > > 1. Defensive fallback should the reset circuit / power sequencer > fail to actually issue a reset; staying in a tight panic() loop > is then still preferable to executing past the failure point. > > 2. As an explicit "this branch must not continue" signal to static > analyzers and future readers, so a subsequent edit cannot > accidentally drop the reset call and silently revert the policy. > > This change has been in production on a downstream STM32MP153D board > running a TF-A v2.4 backport for over a year. Only the central > panic-to-reset change is sent here; related debug NOTICE() prints and > an MMC retry-count bump that lived alongside the downstream patch are > intentionally not included, as the unconditional reset fallback > already covers the recovery cases the retry bump targeted. > > Signed-off-by: Chanhong Jung <happycpu(a)gmail.com> > --- > plat/st/common/bl2_io_storage.c | 15 ++++++++++++++- > 1 file changed, 14 insertions(+), 1 deletion(-) > > diff --git a/plat/st/common/bl2_io_storage.c b/plat/st/common/bl2_io_storage.c > index c478b497c..e6a73e0d3 100644 > --- a/plat/st/common/bl2_io_storage.c > +++ b/plat/st/common/bl2_io_storage.c > @@ -28,6 +28,7 @@ > #include <drivers/st/stm32_fmc2_nand.h> > #include <drivers/st/stm32_qspi.h> > #include <drivers/st/stm32_sdmmc2.h> > +#include <drivers/st/stm32mp_reset.h> > #include <drivers/usb_device.h> > #include <lib/fconf/fconf.h> > #include <lib/mmio.h> > @@ -255,7 +256,19 @@ static void boot_mmc(enum mmc_device_type mmc_dev_type, > > params.device_info = &mmc_info; > if (stm32_sdmmc2_mmc_init(&params) != 0) { > - ERROR("SDMMC%u init failed\n", boot_interface_instance); > + ERROR("SDMMC%u init failed - resetting system\n", > + boot_interface_instance); > + /* > + * eMMC init failures here are usually transient (rail-ramp > + * timing, bus-line noise on fast-boot entry, RCC clock-domain > + * settling jitter). panic() leaves the SoC frozen and forces > + * an external power cycle; a system reset lets BootROM re-run > + * the entire boot path, which most transient failures survive. > + * stm32mp_system_reset() is __dead2, so panic() below is a > + * defensive fallback if the reset circuit is itself wedged, > + * and a no-return marker for analyzers. > + */ > + stm32mp_system_reset(); > panic(); > } > > > base-commit: de387341ee73d99446fbbf6a7053d7b759b8b3a6

1 week, 5 days

Firmware-A v2.15 release code freeze notification

by Harrison Mutai

Hi All, The next release of the Firmware-A bundle of projects tagged v2.15 has an expected code freeze date of 15/05/2026. 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.15 release preparation tasks are on-going and well progressed. 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 reminder 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 & Regards, Harrison on behalf of the TF-A team

1 week, 6 days

Canceled event with note: TF-A Tech Forum @ Thu Apr 16, 2026 5pm - 6pm (GMT+2) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

This event has been canceled with a note: "Hi , Cancelling as no topic this week. Thanks, Olivier. " TF-A Tech Forum Thursday Apr 16, 2026 ⋅ 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 qwandor(a)google.com praan(a)google.com jeremimiller(a)google.com jagdish.gediya(a)linaro.org khilman(a)baylibre.com tf-a(a)lists.trustedfirmware.org ~~//~~ 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

3 weeks, 4 days

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

1 month, 1 week

TF-A Tech Forum (April 2nd 2026 4.00pm BST) s2idle-driven Low Power Mode Selection using PSCI on

by Olivier Deprez

Hi, On Apr, 2nd Scaria Kochidanadu @ Texas Instruments will present on the topic "s2idle-driven Low Power Mode Selection using PSCI on AM62L" See the abstract https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.… Regards, Olivier. TF-A Tech Forum Thursday Apr 2, 2026 ⋅ 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 qwandor(a)google.com praan(a)google.com jeremimiller(a)google.com jagdish.gediya(a)linaro.org khilman(a)baylibre.com tf-a(a)lists.trustedfirmware.org

1 month, 1 week

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-A April 2026