This event has been canceled with a note:
"Hi, Cancelling as no topic planned this week. Regards, Olivier. "
TF-A Tech Forum
Thursday Jul 23, 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
~~//~~
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
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
This event has been canceled with a note:
"Hi, Cancelling as no topic planned today. Regards, Olivier. "
TF-A Tech Forum
Thursday Jul 9, 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
~~//~~
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