Hi all,
Hope you are well. I have recently joined this mailing list and am quite
keen to contribute to this project but don't know where to start.
Currently, I am going through Trusted Firmware A Documentation
<https://trustedfirmware-a.readthedocs.io/en/latest/index.html> document
and Gerrit code reviews
<https://review.trustedfirmware.org/q/status:open+-is:wip> to develop some
initial understanding and familiarity about the project.
As a first step, I am trying to understand areas where I can contribute. Is
there any simple issue for me to pick? I am happy to volunteer.
Looking forward to hearing from you,
Waqas
Hi, In the TF-A Tech Forum on July 10th 2025 Mark Dykes from Arm TF-A team
will present the topic of SMC Fuzzing with the agenda: Overview of the TF-A
fuzzer and its basic implementation in practice. Regards, Olivier.
TF-A Tech Forum
Thursday Jul 10, 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
Hello,
Background & Justification:
MISRA C:2012 Rule 11.1 forbids the conversion from a function pointer to any
other type.
However, in the context of TF-A, we encounter scenarios where this conversion
is necessary and performed with full knowledge of the target architecture and
toolchain behavior. A prominent example is in low-level platform code, such as
transferring control between bootloader stages or passing function entry points
for CPU/core bring-up, where the conversion is unavoidable and well-understood.
One such example is the K3 PSCI driver [1] where we pass the k3_sec_entrypoint
which is of type uintptr_t, to the ti_sci_proc_set_boot_cfg
function where the parameter is of type uint64_t.
Another place that triggered the discussions behind this MISRA C issue
was the TI AM62L PSCI driver [2] that needs a 16b aligned function pointer.
We don't have to go into specific case by case discussion of solving these issues,
but just wanted to share example use cases of function pointer conversion.
Request:
I propose we formally document a project-wide MISRA C:2012 Rule 11.1 deviation,
reflecting current and future usage throughout the TF-A codebase. This deviation
allows us to balance MISRA objectives with the practical and architectural
necessities of TF-A development.
Rationale:
* Conversions between function pointers and other types are essential in several
parts of the TF-A codebase, not limited to one module or file.
* Platform-specific code (e.g., power management, bootloader hand-offs) relies
on this pattern for correct operation.
References:
[1] https://github.com/ARM-software/arm-trusted-firmware/blob/master/plat/ti/k3…
[2] https://github.com/ARM-software/arm-trusted-firmware/blob/master/plat/ti/k3…
--
Best regards,
Dhruva Gole
Texas Instruments Incorporated
Hello,
I want to boot Linux on ZynqMP (XCZU15EG).
I follow the standard procedure.
I have generated FSBL using Vitis.
I have compiled bl31 (tag: xilinx-v2025.1).
I have a standard boot.bif configuration looking as follows:
the_ROM_image:
{
[bootloader] fsbl.elf
[pmufw_image] pmufw.elf
[destination_cpu = a53-0, exception_level= el-3, trustzone] bl31.bin
[destination_cpu = a53-0, exception_level= el-2, load = 0x10000000] images/u-boot.bin
}
However, the bl31 reports the following error during the handoff to u-boot:
ASSERT: lib/xlat_tables_v2/xlat_tables_core.c:788
BACKTRACE: START: assert
0: F_FUNCTION: 0x2880
1: F_FUNCTION: 0x4cac
2: F_FUNCTION: 0x2628
3: F_FUNCTION: 0x36e0
4: F_FUNCTION: 0x108
5: F_FUNCTION: 0xfffcd8e8
BACKTRACE: END: assert
This is an assertion for context being uninitialized in the mmap_add_region_ctx function.
/* Static regions must be added before initializing the xlat tables. */
assert(!ctx->initialized);
Does anyone have any idea what might be wrong?
Best regards,
Michał Kruszewski
Sent with [Proton Mail](https://proton.me/mail/home) secure email.