- TF-A - lists.trustedfirmware.org

Deprecation notification of Socionext Uniphier, Arm fvp_ve, Broadcom Stingray platforms

by Boyan Karatotev

Hello, During a recent code ownership cleanup we have identified three platforms that lack designated code owners: Socionext Uniphier, Arm fvp_ve, Broadcom Stingray platforms. All three have not had any significant activity for some time now and as such we are going to mark them as deprecated. The patches to do that are here: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/53842. We will go ahead with them in the next week or so unless we hear any objections. These platforms will not be removed until after the next v2.16 release scheduled for later this year. We will not proceed with removal if code owners are found before then. Thanks, Boyan

2 days, 18 hours

1
0
0 0

SDEI: SDEI_EVENT_0 trigger dropped while PE masked — by design?

by wtliang785

Hi all, I'd like to ask whether the following behavior of SDEI_EVENT_0 is intended, and whether it's a known limitation of the SDEI + GIC SGI semantics. I've read the code carefully but want to confirm the intent before relying on or working around it. ## Setup - TF-A SDEI, event 0 is a "signalable" private event whose backing interrupt is a Secure SGI (on our platform, SGI 9). - include/services/sdei.h, SDEI_DEFINE_EVENT_0(_intr) -> SDEI_PRIVATE_EVENT(SDEI_EVENT_0, _intr, SDEI_MAPF_SIGNALABLE) - services/std_svc/sdei/sdei_main.c: asserts event 0 must be a Secure SGI and may only carry SIGNALABLE|PRIVATE. ## What I observe in code When the PE is SDEI-masked (client called SDEI_PE_MASK) and the SGI backing event 0 fires, the handler does *not* preserve the trigger: 1. The EL3 FIQ is taken and acked in bl31/ehf.c ehf_el3_interrupt_handler() via plat_ic_acknowledge_interrupt() (reads ICC_IAR — interrupt now Active, its Pending bit consumed). 2. It reaches sdei_intr_handler() (services/std_svc/sdei/sdei_intr_mgmt.c). At L463, state->pe_masked is true, so it calls handle_masked_trigger() and returns 0. 3. handle_masked_trigger() : /* Nothing to do for event 0 */ if (map->ev_num == SDEI_EVENT_0) return; i.e. for event 0 it does none of the "freeze for replay" steps that a normal private event takes : plat_ic_disable_interrupt(intr); plat_ic_set_interrupt_pending(intr); plat_ic_end_of_interrupt(intr_raw); state->pending_enables = true; So while the PE is masked, an event-0 trigger is acknowledged and then silently dropped, with nothing stored for replay on the next SDEI_PE_UNMASK. ## Why I think this happens (and want to confirm) The "freeze for replay" mechanism for normal private events relies on re-asserting Pending via plat_ic_set_interrupt_pending(), because the ack already consumed the Pending bit. But for an SGI this is not permitted — plat/common/plat_gicv3.c: asserts it out: void plat_ic_set_interrupt_pending(unsigned int id) { /* Disallow setting SGIs pending */ assert(id >= MIN_PPI_ID); gicv3_set_interrupt_pending(id, plat_my_core_pos()); } So event 0 (backed by an SGI) cannot have its Pending bit re-asserted in software, which is consistent with the "Nothing to do for event 0" early return. Combined with the level/merge semantics of GIC SGIs (a sender firing the same SGI N times is represented as a single Pending, not a count), this means a masked-PE client can at most learn "an event happened while masked", never how many or which — by design. ## My questions 1. Is dropping an event-0 trigger while the PE is masked the intended behaviour (a consequence of "event 0 is a signalable SGI, counting is not guaranteed"), rather than a bug? The "Nothing to do for event 0" comment reads as deliberate, but I'd like explicit confirmation. 2. Is the recommended mitigation simply to avoid firing event 0 while the PE is masked (buffer on the sender side, deliver after unmask), or to use a normal explicit event for anything requiring precise accounting? Or is there a platform hook intended for this case that I'm missing (e.g. plat_sdei_handle_masked_trigger — though that path is only taken for shared ANY-PE events , not event 0)? 3. Separately (not the focus of this question): on this masked path neither handle_masked_trigger() nor sdei_intr_handler() calls plat_ic_end_of_interrupt() for event 0, and neither the EHF top-level handler nor the runtime_exceptions.S dispatch macro performs a fallback EOI. So the acked SGI appears to be left Active with no EOI on this path. Is there a later EOI for this SGI that I've missed, or is that also expected here? I don't want to conflate this with the "drop" question above; I'm just flagging it. For reference, this is on an in-tree SDEI path; the platform only defines event 0 via SDEI_DEFINE_EVENT_0(PLAT_SDEI_SGI_PRIVATE) and does not modify handle_masked_trigger(). Thanks, Tianliang

1 week

1
0
0 0

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

by Olivier Deprez

This event has been canceled with a note: "Also cancelling Aug 20th instance as no topic and expected low attendance." TF-A Tech Forum Thursday Aug 20, 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 d82620130(a)gmail.com namyoon(a)google.com shaikadnanafrid(a)gmail.com tf-a(a)lists.trustedfirmware.org ~~//~~ Sent by 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

1
0
0 0

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

by Olivier Deprez

This event has been canceled with a note: "Hi Cancelling as topic on Aug 6th. Regards, Olivier. " TF-A Tech Forum Thursday Aug 6, 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 d82620130(a)gmail.com namyoon(a)google.com shaikadnanafrid(a)gmail.com tf-a(a)lists.trustedfirmware.org ~~//~~ Sent by 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

1
0
0 0

Lava Lab downtime tomorrow 06/06/2026

by Ben Copeland

Hello all, Please be aware that tomorrow, 06/06/2026, the Lava Lab will be down due to a UPS replacement. The time will be 13:00 to 17:00 (UTC+1). Regards Ben

3 weeks, 1 day

1
1
0 0

Trusted Firmware-A LTS v2.14.6 Release Announcement

by svc_openci_enginfra＠arm.com

Hello, Trusted Firmware-A LTS version 2.14.6 is now available. This release contains the following patches: 3bd0e9acb feat(mt8196): add CPU errata workarounds [1] 2c2699824 fix(versal2): enable A78AE errata workarounds [2] 7a5b2b3a0 fix(versal-net): enable A78AE errata workarounds [3] c731d419c fix(xilinx): pass security_flag to eemi_psci_debugfs_handler [4] [1] https://review.trustedfirmware.org/q/Ia1a89c462c2ce600302c54eb5c289ed9501b4… [2] https://review.trustedfirmware.org/q/I598ea03c800ff685d57f97fdc519bda3c53a1… [3] https://review.trustedfirmware.org/q/Id7a0f53595eba6140e131dab529d75cdafa35… [4] https://review.trustedfirmware.org/q/Ie8b5fc95ae83a98d8d9d58562be8407bd4468… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.14.6/change-log.html Thanks, TF-A LTS team

3 weeks, 6 days

1
0
0 0

Trusted Firmware-A LTS v2.12.14 Release Announcement

by svc_openci_enginfra＠arm.com

Hello, Trusted Firmware-A LTS version 2.12.14 is now available. This release contains the following patches: e6f0750c7 fix(xilinx): pass security_flag to eemi_psci_debugfs_handler [1] 80f4f28b8 fix(versal2): enable A78AE errata workarounds [2] 50224b40e fix(versal-net): enable A78AE errata workarounds [3] 327504e3d fix(nxp): move PLAT_FUSE_FIP_* to plat_default_def [4] d3fc9d67d fix(stm32mp1): force soft float ABI and disable NEON [5] 78674e3e9 docs: fill TFV advisory titles [6] bfd109e39 fix(nxp): imx_trdc.h header guard [7] [1] https://review.trustedfirmware.org/q/Ie8b5fc95ae83a98d8d9d58562be8407bd4468… [2] https://review.trustedfirmware.org/q/I598ea03c800ff685d57f97fdc519bda3c53a1… [3] https://review.trustedfirmware.org/q/Id7a0f53595eba6140e131dab529d75cdafa35… [4] https://review.trustedfirmware.org/q/I6777e342a439d484ea52ea851beb15afb2dc6… [5] https://review.trustedfirmware.org/q/Ic9a7da8ec5b2f019a1cf61c82dc058469d1f2… [6] https://review.trustedfirmware.org/q/I17705b3a2ca2a04ee5698fb86b0d2524033e3… [7] https://review.trustedfirmware.org/q/I4767dc4d1c26ebe95d417be724f5cb848f54a… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.12.14/change-log.html Thanks, TF-A LTS team

3 weeks, 6 days

1
0
0 0

Trusted Firmware-A LTS v2.8.45 Release Announcement

by svc_openci_enginfra＠arm.com

3 weeks, 6 days

1
0
0 0

Trusted Firmware-A LTS v2.10.33 Release Announcement

by svc_openci_enginfra＠arm.com

Hello, Trusted Firmware-A LTS version 2.10.33 is now available. This release contains the following patches: 0afda0393 fix(xilinx): pass security_flag to eemi_psci_debugfs_handler [1] [1] https://review.trustedfirmware.org/q/Ie8b5fc95ae83a98d8d9d58562be8407bd4468… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.10.33/change-log.html Thanks, TF-A LTS team

3 weeks, 6 days

1
0
0 0

[TFA][RFC] Relaxing FWU metadata validation to support variable-size metadata

by Maxime MERE

Hi all, I'd like some early feedback on an approach before writing it up as patches for Gerrit review. It would relax the generic FWU metadata sanity checks in fwu.c, and let us remove some STM32MP-specific code that would become dead as a result. Motivation On STM32MP platforms we need to support boards that can be flashed either with a GPT/block-device layout (SD/eMMC) or with a raw/MTD layout (NOR/NAND), while reusing the same U-Boot binary/configuration across both. The two layouts don't need to describe the same firmware image set in their FWU metadata: the block-device variant uses an A/B redundant layout covering FIP + BootFS + RootFS (3 images per bank), while the raw-storage variant only ever needs a single FIP per bank (no GPT, no room for a generic BootFS/RootFS A/B scheme). This was highlighted by a 4-patch series by Dario already in TF-A tree ("feat(st): add extended bootloader GUID" / "feat(st): add Linux data partition GUID" / "feat(st): add STM32MP_PSA_FWU_AB_SUPPORT build flag" / "feat(st): enable A/B redundancy support"), which introduces exactly that 3-image A/B layout for GPT-based STM32MP boards by raising NR_OF_IMAGES_IN_FW_BANK to 3. The problem: fwu_metadata_sanity_check() currently requires an exact match between the metadata-declared num_images/size and the platform's compiled configuration, and computes the CRC over sizeof(struct fwu_metadata) instead of the metadata-declared metadata_size. This forces every board variant sharing a single TF-A build to describe exactly the same image set/size in its FWU metadata, which isn't what the spec intends. What the spec says (DEN0118 FWU-1.0 A EAC1 see https://developer.arm.com/documentation/den0118/latest/) Table A3.2 explicitly introduces metadata_size in v2 as "The size in bytes of the complete metadata structure", and defines the CRC as computed over the declared size, not a fixed maximum. Table A3.3 defines num_images as "The number of entries in the img_entry array" (img_entry[num_images]), again variable by design. The spec also explicitly allows #banks < 4, but in the current C struct layout num_banks also determines the byte stride of each img_entry (bank_info_entry_size * num_banks), so relaxing it would require decoding img_entry[] with a runtime-computed stride instead of the fixed compile-time layout so I'd rather keep that out of scope for now. What I'm proposing In the common FWU driver (fwu.c), replace the equality checks with bounds that only reject metadata a platform genuinely cannot handle: - Compute the CRC over metadata.metadata_size instead of sizeof(struct fwu_metadata), matching the spec. - Accept num_images <= NR_OF_IMAGES_IN_FW_BANK instead of requiring strict equality. - Bound metadata_size itself between FWU_FW_STORE_DESC_OFFSET (0x20, the minimum valid v2 size) and sizeof(struct fwu_metadata), to reject malformed metadata and avoid any out-of-bounds read. - Keep num_banks as an exact match against NR_OF_FW_BANKS, for the layout reason above. On the STM32MP side, plat_fwu_set_images_source() currently iterates every image entry described by the metadata and tries to resolve a storage offset for each of them. On raw storage devices (NOR/NAND) only two hardcoded bank GUIDs are known, so any entry other than the FIP (e.g. BootFS/RootFS added by STM32MP_PSA_FWU_AB_SUPPORT) causes a panic, even though BL2 never actually loads BootFS/RootFS itself (only U-Boot/Linux/the update agent do). I'd change it to search explicitly for the FIP image type GUID and resolve only that entry, using metadata.fw_desc.num_images (now safely bounded by point 1) as the search bound instead of the compiled NR_OF_IMAGES_IN_FW_BANK. The function then becomes agnostic of how many, or which, other image types a given metadata instance may describe. As a direct consequence of point 2, the per-image IO policies, image IDs and GUID definitions (XBOOTLDR_GUID, LINUX_FILE_SYSTEM_DATA_GUID) added for BootFS/RootFS become dead code from BL2's point of view (they were only needed so plat_fwu_set_images_source() could resolve those entries). I'd remove them, while keeping the STM32_EXTRA_PARTS accounting fix (load_partition_table() truncates the parsed GPT to a fixed-size list, so the extra bootfs-a/b, rootfs-a/b, vendorfs and u-boot-env partitions still physically present on an A/B board must still be accounted for, even though BL2 no longer resolves them individually). Validation Tested on hardware: - A TF-A build configured for the 3-image A/B layout (NR_OF_IMAGES_IN_FW_BANK = 3, STM32MP_PSA_FWU_AB_SUPPORT=1) booting successfully off FWU metadata that only declares a single image entry (num_images = 1), confirming a platform built for the larger capacity can consume metadata that uses a smaller subset. - The existing single-image configuration (NR_OF_IMAGES_IN_FW_BANK = 1) still boots correctly with unchanged, exact-match metadata, confirming no regression on the base FWU flow. Questions for the list - Is the community comfortable relaxing this check in common code (fwu.c), given it affects every platform enabling PSA_FWU_METADATA_FW_STORE_DESC? - Is anyone aware of a downstream user relying on the current exact-match behaviour that this change would affect? If this sounds reasonable I'll post the actual patches to Gerrit for review. Thanks, Maxime

1 month

3
3
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-A