This event has been canceled with a note:
"Hi, Cancelling the TF-A Tech Forum as no topic planned. Thanks & Regards,
Olivier. "
TF-A Tech Forum
Thursday Dec 14, 2023 ⋅ 5pm – 6pm
Central European Time - Paris
We run an open technical forum call for anyone to participate and it is not
restricted to Trusted Firmware project members. It will operate under the
guidance of the TF TSC. Feel free to forward this invite to
colleagues. Invites are via the TF-A mailing list and also published on the
Trusted Firmware website. Details are
here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr…
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap
mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US
(San Jose)Dial by your location +1 646 558
8656 US (New York) +1 669 900
9128 US (San Jose) 877 853 5247 US
Toll-free 888 788 0099 US Toll-freeMeeting ID:
915 970 4974Find your local
number: https://zoom.us/u/ad27hc6t7h
Guests
marek.bykowski(a)gmail.com
okash.khawaja(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. To
stop receiving future updates for this event, decline this 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
Hello,
In the file common/bl_common.c and other related files, there are instances where function parameters are being modified. This leads to violations when running the Coverity MISRA-C analysis for the ZynqMP platform.
To address this issue a new variable is declared and used to store the value from the argument in the code. Is it possible to fix by taking a new variable? Please provide your suggestions.
Regards,
Nithin G
Hello,
In the file lib/xlat_tables/xlat_tables_common.c and other related files, the condition clause of the for loop does not use the loop counter variable "mm". This leads to violations when running the Coverity MISRA-C analysis for the ZynqMP platform.
Addressing this issue added mm as part of loop counter and this belongs to core translational table logic and other violations also related to this. Is it possible to address this issue? Please provide your suggestions.
Regards,
Nithin G
Hello,
Trusted Firmware-A LTS version 2.8.13 is now available. This release introduces workarounds for new CPU errata for Cortex-A78C, Cortex-X3, and Neoverse V1/V2. It also adds support for the SLS mitigation.
The complete list of changes can be found here<https://trustedfirmware-a.readthedocs.io/en/lts-v2.8.13/change-log.html>.
Thanks.
Hello,
In the file bl31/bl31_main.c, there is a function named bl31_lib_init with its definition. Simultaneously, the declaration of this function is included in include/bl31/bl31.h since the function bl31_lib_init used only in one translational unit. leading to a violation when running the Coverity MISRA-C analysis for the ZynqMP.
Addressing this issue need to remove the declaration of the function from the bl31.h file and making its definition static. To maintain visibility, included a static declaration in the bl31_main.c file. However, it will may impact in future modifications due to the removal of the declaration in bl31.h. Please provide your suggestions.
Regards,
Nithin
Dear All,
We would like to announce that we have published an experimental project called rust-spmc which is a S-EL1 FF-A Secure Partition Manager Core implementation in Rust. We started this as a free time project and now we had the opportunity to publish it on trustedfirmware.org. In its current state it has a partial implementation of the FF-A protocol, and it is able to run the secure partitions of Trusted Services with all tests passing on Arm FVP. It also provides the required compartmentalization between the S-EL0 secure partitions.
Please note that the project is experimental (i.e. PoC, not suitable for production) and it is currently not scheduled by Arm for further development.
The Rust language is an ideal language for implementing firmware components given its lack of undefined behavior and its memory safety guarantees. Our goal was to demonstrate the capabilities of language in a security critical firmware environment and to gather feedback from partners which could open up the possibility of further development of the project.
The repository is available here: https://git.trustedfirmware.org/rust-spmc/rust-spmc.git/
We also prepared a readme with instructions for testing the project: https://git.trustedfirmware.org/rust-spmc/rust-spmc.git/about/
Please reach out to us if you are interested in the project or if you have any questions.
Regards,
Bálint Dobszay & Imre Kis
This event has been canceled with a note:
"Hi, Cancelling the TF-A Tech Forum as no topic. Thanks & Regards,
Olivier. "
TF-A Tech Forum
Thursday Nov 30, 2023 ⋅ 5pm – 6pm
Central European Time - Paris
We run an open technical forum call for anyone to participate and it is not
restricted to Trusted Firmware project members. It will operate under the
guidance of the TF TSC. Feel free to forward this invite to
colleagues. Invites are via the TF-A mailing list and also published on the
Trusted Firmware website. Details are
here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr…
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap
mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US
(San Jose)Dial by your location +1 646 558
8656 US (New York) +1 669 900
9128 US (San Jose) 877 853 5247 US
Toll-free 888 788 0099 US Toll-freeMeeting ID:
915 970 4974Find your local
number: https://zoom.us/u/ad27hc6t7h
Guests
marek.bykowski(a)gmail.com
okash.khawaja(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. To
stop receiving future updates for this event, decline this 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
When booting my Pine64 Rock64 (rk3328), I see the following warning:
WARNING: BL31: cortex_a53: CPU workaround for 1530924 was missing!
That warning is present in u-boot 2023.01 and also in 2023.07.
Asking on their IRC channel and they indicated it should be fixed in TF-A.
In the source code I saw various commits which all seem a variation of
74665119f04de0cd7c735fa741aff607a4a9fde8
titled "Enable workaround for Cortex-A53 erratum 1530924"
But such a commit seems to be missing for the rk3328 platform.
I guess a patch like this is needed to fix that?
```patch
diff --git a/plat/rockchip/rk3328/platform.mk b/plat/rockchip/rk3328/
platform.mk
index 5b4766d51..bd86a1cc8 100644
--- a/plat/rockchip/rk3328/platform.mk
+++ b/plat/rockchip/rk3328/platform.mk
@@ -65,6 +65,7 @@ include lib/libfdt/libfdt.mk
# Enable workarounds for selected Cortex-A53 errata
ERRATA_A53_855873 := 1
+ERRATA_A53_1530924 := 1
$(eval $(call add_define,PLAT_EXTRA_LD_SCRIPT))
$(eval $(call add_define,PLAT_SKIP_OPTEE_S_EL1_INT_REGISTER))
```
The Contributor’s Guide indicates that it requires a Microsoft Github account,
so I opted to post a patch to this list.
Cheers,
Diederik
PS: https://developer.trustedfirmware.org/ seems to be full of spam; you may
want to look into that.
Hello,
Trusted Firmware-A LTS version 2.8.12 is now available. This release removes the Cryptocell driver support and contains fixes for the Tegra platform, the SMCCC library, and SDEI.
The complete list of changes can be found here<https://ci-builds.trustedfirmware.org/static-files/DcqMVUzlEWpu-LYx_0-RuHeu…>.
Thanks.
TL;DR: move Mandatory features to be runtime checked (value 2)
Month ago there was changeset from Govindraj Raja merged [1]. The plan
was to enable all mandatory features based on architecture version set
by plaform (using ARM_ARCH_{MAJOR,MINOR} variables).
1. https://review.trustedfirmware.org/q/topic:%22gr/build_refactor%22
The idea is nice. But only for final products. If you are working on
silicon bring up or on virtualization platform (QEMU or other) then you
got hit badly...
I am working on SBSA Reference Platform in QEMU. It can have one of
several cpu models. From old v8.0 cores up to v9.0 ones. And then there
is also 'max' core which cannot be mapped to any architecture level
because it contains all Arm cpu features QEMU can emulate. We need to
support all of them in one TF-A binary. Whenever something fails we
have some cpu cores in non-bootable state.
We had to enable FGT to get 'max' boot Linux. Now we have to move DIT to
be runtime checked to boot anything below Neoverse-V1 at all. And HCX to
get 'max' boot Linux again.
At current state of TF-A we cannot handle it. Toplevel Makefile includes
platform.mk which sets ARM_ARCH_{MAJOR,MINOR} and then
make_helpers/arch_features.mk enables mandatory options by setting them
to value "1" which means "present, no need to check".
Due to this we have those changes in Gerrit:
DIT: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/24870
TRF: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/23648
And instead of sending another one to switch FGT, RNG and HCX I decided
to write this email.
I have spent half of day today bisecting TF-A, booting several tools and
operating systems to check how we are and where the problem is. Still
have to get Neoverse-N2 booting properly but other than then I got to
the point where all cpu cores boot into Linux.
We need to change make_helpers/arch_features.mk to stop enabling mandatory
features as "present, no need to check" (value '1') but to use runtime
check (value '2') instead. This way any platform which contains CPU not
yet fully developed can boot TF-A. Or platform where one firmware can boot
different cpu models.
I am sorry that I bring it so late in release cycle but was unable to use
computer for a development for some time.
We have executed below command on terminal to get stack size using ARMCLANG compiler. but we are getting "undefined symbol".
armclang --target=arm-arm-none-eabi -march=armv8-a -c -g file.c -o file.o
armlink file.o --info=stack
armlink file.o --callgraph -o FileImage.axf
Could anyone answer me that how to get stack size using ARMCLANG compiler for TFA code.
This event has been canceled with a note:
"Hi, Cancelling this week as no topic. Thanks & Regards, Olivier."
TF-A Tech Forum
Thursday Nov 16, 2023 ⋅ 5pm – 6pm
Central European Time - Paris
We run an open technical forum call for anyone to participate and it is not
restricted to Trusted Firmware project members. It will operate under the
guidance of the TF TSC. Feel free to forward this invite to
colleagues. Invites are via the TF-A mailing list and also published on the
Trusted Firmware website. Details are
here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr…
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap
mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US
(San Jose)Dial by your location +1 646 558
8656 US (New York) +1 669 900
9128 US (San Jose) 877 853 5247 US
Toll-free 888 788 0099 US Toll-freeMeeting ID:
915 970 4974Find your local
number: https://zoom.us/u/ad27hc6t7h
Guests
marek.bykowski(a)gmail.com
okash.khawaja(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. To
stop receiving future updates for this event, decline this 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
Hello,
Trusted Firmware-A LTS version 2.8.11 is now available. This release contains the workarounds for CPU errata, platform errata, and fixes for Versal/Versal-NET security vulnerabilities.
The complete list of changes can be found here<https://ci-builds.trustedfirmware.org/static-files/NdY070C96xYcXq0KeqQzbFaI…>.
Thanks.
Hi,
Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan.
3 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan.
1 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan.
New defect(s) Reported-by: Coverity Scan
Showing 3 of 3 defect(s)
** CID 405370: Memory - illegal accesses (OVERRUN)
/lib/psci/psci_stat.c: 210 in psci_get_stat()
________________________________________________________________________________________________________
*** CID 405370: Memory - illegal accesses (OVERRUN)
/lib/psci/psci_stat.c: 210 in psci_get_stat()
204 /* Get the index into the stats array */
205 local_state = state_info.pwr_domain_state[pwrlvl];
206 stat_idx = get_stat_idx(local_state, pwrlvl);
207
208 if (pwrlvl > PSCI_CPU_PWR_LVL) {
209 /* Get the power domain index */
>>> CID 405370: Memory - illegal accesses (OVERRUN)
>>> Overrunning array "psci_cpu_pd_nodes" of 16 16-byte elements at element index 4294967295 (byte offset 68719476735) using index "target_idx" (which evaluates to 4294967295).
210 parent_idx = SPECULATION_SAFE_VALUE(psci_cpu_pd_nodes[target_idx].parent_node);
211 for (lvl = PSCI_CPU_PWR_LVL + 1U; lvl < pwrlvl; lvl++)
212 parent_idx = SPECULATION_SAFE_VALUE(psci_non_cpu_pd_nodes[parent_idx].parent_node);
213
214 /* Get the non cpu power domain stats */
215 *psci_stat = psci_non_cpu_stat[parent_idx][stat_idx];
** CID 405369: Memory - illegal accesses (OVERRUN)
/lib/psci/psci_stat.c: 218 in psci_get_stat()
________________________________________________________________________________________________________
*** CID 405369: Memory - illegal accesses (OVERRUN)
/lib/psci/psci_stat.c: 218 in psci_get_stat()
212 parent_idx = SPECULATION_SAFE_VALUE(psci_non_cpu_pd_nodes[parent_idx].parent_node);
213
214 /* Get the non cpu power domain stats */
215 *psci_stat = psci_non_cpu_stat[parent_idx][stat_idx];
216 } else {
217 /* Get the cpu power domain stats */
>>> CID 405369: Memory - illegal accesses (OVERRUN)
>>> Overrunning array "psci_cpu_stat" of 16 32-byte elements at element index 4294967295 (byte offset 137438953471) using index "target_idx" (which evaluates to 4294967295).
218 *psci_stat = psci_cpu_stat[target_idx][stat_idx];
219 }
220
221 return PSCI_E_SUCCESS;
222 }
223
** CID 405368: (NEGATIVE_RETURNS)
/lib/psci/psci_stat.c: 210 in psci_get_stat()
/lib/psci/psci_stat.c: 218 in psci_get_stat()
________________________________________________________________________________________________________
*** CID 405368: (NEGATIVE_RETURNS)
/lib/psci/psci_stat.c: 210 in psci_get_stat()
204 /* Get the index into the stats array */
205 local_state = state_info.pwr_domain_state[pwrlvl];
206 stat_idx = get_stat_idx(local_state, pwrlvl);
207
208 if (pwrlvl > PSCI_CPU_PWR_LVL) {
209 /* Get the power domain index */
>>> CID 405368: (NEGATIVE_RETURNS)
>>> Using variable "target_idx" as an index to array "psci_cpu_pd_nodes".
210 parent_idx = SPECULATION_SAFE_VALUE(psci_cpu_pd_nodes[target_idx].parent_node);
211 for (lvl = PSCI_CPU_PWR_LVL + 1U; lvl < pwrlvl; lvl++)
212 parent_idx = SPECULATION_SAFE_VALUE(psci_non_cpu_pd_nodes[parent_idx].parent_node);
213
214 /* Get the non cpu power domain stats */
215 *psci_stat = psci_non_cpu_stat[parent_idx][stat_idx];
/lib/psci/psci_stat.c: 218 in psci_get_stat()
212 parent_idx = SPECULATION_SAFE_VALUE(psci_non_cpu_pd_nodes[parent_idx].parent_node);
213
214 /* Get the non cpu power domain stats */
215 *psci_stat = psci_non_cpu_stat[parent_idx][stat_idx];
216 } else {
217 /* Get the cpu power domain stats */
>>> CID 405368: (NEGATIVE_RETURNS)
>>> Using variable "target_idx" as an index to array "psci_cpu_stat".
218 *psci_stat = psci_cpu_stat[target_idx][stat_idx];
219 }
220
221 return PSCI_E_SUCCESS;
222 }
223
________________________________________________________________________________________________________
To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…
This event has been canceled with a note:
"Hi, The TF-A Tech Forum is cancelled this week as no topic planned.
Regards, Olivier."
TF-A Tech Forum
Thursday Nov 2, 2023 ⋅ 5pm – 6pm
Central European Time - Paris
We run an open technical forum call for anyone to participate and it is not
restricted to Trusted Firmware project members. It will operate under the
guidance of the TF TSC. Feel free to forward this invite to
colleagues. Invites are via the TF-A mailing list and also published on the
Trusted Firmware website. Details are
here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr…
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap
mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US
(San Jose)Dial by your location +1 646 558
8656 US (New York) +1 669 900
9128 US (San Jose) 877 853 5247 US
Toll-free 888 788 0099 US Toll-freeMeeting ID:
915 970 4974Find your local
number: https://zoom.us/u/ad27hc6t7h
Guests
marek.bykowski(a)gmail.com
okash.khawaja(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. To
stop receiving future updates for this event, decline this 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 there
We recently got our first batch of i.MX 8M Plus QuadLite based SoMs. While NXP downstream works just fine on
them they just hang booting with latest upstream U-Boot (and TF-A). Replacing TF-A with the downstream NXP one
made upstream U-Boot work as well. Further debugging TF-A showed imx_gpc_pm_domain_enable() to be the culprit.
Looking more specifically I discovered the following so far downstream-only commit [1]. So it looks like in
downstream NXP is limiting the to-be-enabled power management domains to HSIOMIX, USB1_PHY and USB2_PHY.
Anybody knows why exactly this is done and why this got never upstreamed?
Thank you very much for any insights into this matter.
[1] https://github.com/nxp-imx/imx-atf/commit/47759cfca10b2286a218062915d4a2808…
Cheers
Marcel
Hello,
I just sent a series to gerrit:
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/23992.
I'm writing this email to add more context to this series, as I didn't
find how to to it with gerrit.
This series is only the TF-A part to add suspend to RAM support for the
TI K3 J7200 target.
Some modifications are also needed in Linux kernel, U-Boot (R5 SPL) and
DM-Firmware.
During the suspend sequence, TF-A save itself in DRAM, in a reserved
memory region dedicated to lpm.
TF-A will be restored by R5 SPL.
We need to save it in DRAM (which will be in retention mode during
suspend) because as it runs in SRAM, it will be lost once the SOC is
powered-off by the PMIC.
Best Regards,
--
Thomas Richard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Hello,
There are multiple occurrences in TFA Code where assert statements are used to handle function arguments. But these assert statements are currently enabled only in debug mode. So, I wanted to know that will there be any harm in continuing to use assert statements in production code as well for handling failures?
Regards,
Nithin S
Hello,
Trusted Firmware-A LTS version 2.8.9 is now available. This release contains the support for the new Errata ABI and Errata Framework along with the conversion patches for all CPUs.
The complete list can be found here<https://ci-builds.trustedfirmware.org/static-files/_5qFfMg2QdoFuFBk6-0oB6Jm…>. We will update the official readthedocs page shortly.
Thanks.
This event has been canceled with a note:
"Hi, Cancelling as no topic proposed for this instance. Regards, Olivier."
TF-A Tech Forum
Thursday Oct 5, 2023 ⋅ 5pm – 6pm
Central European Time - Paris
We run an open technical forum call for anyone to participate and it is not
restricted to Trusted Firmware project members. It will operate under the
guidance of the TF TSC. Feel free to forward this invite to
colleagues. Invites are via the TF-A mailing list and also published on the
Trusted Firmware website. Details are
here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr…
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap
mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US
(San Jose)Dial by your location +1 646 558
8656 US (New York) +1 669 900
9128 US (San Jose) 877 853 5247 US
Toll-free 888 788 0099 US Toll-freeMeeting ID:
915 970 4974Find your local
number: https://zoom.us/u/ad27hc6t7h
Guests
marek.bykowski(a)gmail.com
okash.khawaja(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. To
stop receiving future updates for this event, decline this 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,
We are currently in the process of preparing for an upcoming release v2.10 [1] and are actively seeking out any deprecated platforms within the TF-A source code. We kindly request all platform owners and contributors to dedicate some time to review the TF-A source code for any platforms that may have been deprecated.
If you encounter any platforms that require deprecation but have not yet been labelled as such, we kindly request that you contribute by submitting the required changes to officially mark them as deprecated. You can follow the example provided in [2].
Thank you for your cooperation.
[1]: https://trustedfirmware-a.readthedocs.io/en/latest/about/release-informatio…
[2]: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/17710
Regards,
Manish Badarkhe
Hi ,
When I grep for PLAT_XLAT_TABLES_DYNAMIC in /lib/lib/xlat_tables_v2/ ,
I see most references for PLAT_XLAT_TABLES_DYNAMIC are enclosed in #if directive.
Is there any specific reason why only below mentioned reference for PLAT_XLAT_TABLES_DYNAMIC
is covered with #ifdef and not under #if .
https://github.com/Xilinx/arm-trusted-firmware/blob/master/lib/xlat_tables_…
#ifdef PLAT_XLAT_TABLES_DYNAMIC
#define MAX_PHYS_ADDR tf_xlat_ctx.pa_max_address
#else
#define MAX_PHYS_ADDR tf_xlat_ctx.max_pa
#endif
Regards
Amit
Hi,
I am writing this email to find out any legacy platforms supports in TF-A (upstream or downstream) which does not have any NS-EL2 component running.
Because NS-EL2 is present but unused EL3 also need to do a minimal initialization of EL2. The side effect of this is, TF-A currently has extra code in generic path (e.g. cm_prepare_el3_exit() ) to cater for these platforms which is not required for most others.
The most likely reason why TF-A introduced support for systems without NS-EL2 was because of UEFI implementation for Windows which didn't initialize NS-EL2 properly. Given that the UEFI spec has said "Use the highest 64 bit non secure privilege level available" for a long time now we are safe to assume that any UEFI implementation will handover to windows at NS-EL2. (similar to Linux)
Considering that there are very few platforms which need this code and to keep backward compatibility, we propose to introduce a macro like "INIT_UNUSED_NS_EL2" and guard the code under this[1]. Keep this flag default disabled and get rid of it( along with code) altogether in next couple of releases, if we are certain that none of the platforms using it.
Please let me know if you are aware of any such platform configuration.
[1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/22716
Thanks
Manish
Hello,
Are EHF and OP-TEE (opteed) designed to work together? I'm seeing some strange behavior when NS interrupts are routed to EL3 as FIQs (due to EHF), but before I dig into it further I wanted to confirm if EHF + OP-TEE is a valid combination.
Some background: Our system, which uses OP-TEE, has some "aggregated interrupts" that contain both secure and non-secure sources, for which we wanted to use SDEI to filter and dispatch to Linux (and SDEI requires EHF).
Thanks!
-Brian
Hi everyone,
As you may know, console drivers in TF-A are required to provide a
number of callbacks. One of them is getc() (to read a character from the
console). Even though most platform ports provide a valid implementation
of it, it does not seem to be called anywhere in the code base today,
effectively qualifying it as dead code.
I did a bit of git history digging and from what I've seen, the very
first public version of TF-A (v0.2!) already had a getc() callback in
the Arm PL011 UART driver. So my guess is that all subsequent UART
drivers added after that followed the same approach. When the
multi-console framework was introduced, it naturally catered for this
feature as well.
However, taking a step back, I wonder why we introduced getc() in the
first place... Unlike other firmwares (like U-boot or EDK2), TF-A does
not implement any kind of interactive user shell. And from a security
point of view, getc() constitutes an attack vector into TF-A, which
might allow an attacker to inject arbitrary data. So keeping this
functionality without any valid use case sounds like a bad idea to me.
Now, even though getc() is not used in upstream TF-A code right now, I
realize there might be downstream / internal test setups which need it.
For example, for firmware recovery purposes (receiving a backup firmware
over a serial interface) or automated tests setups (some script driving
a test session using some communication protocol over a serial interface).
Is anyone depending on such use cases?
If not, then I suggest we consider removing getc() feature altogether.
We could always bring it back when there is a real use case for it (it
will survive through git history).
At the very least, I would like to disable getc() by default. Enabling
it would require setting a build flag.
Any thoughts or concerns?
Best regards,
Sandrine
Hello,
We use fiptool extensively to generate the FIP blobs for NVIDIA platforms. But, we encountered the following issues during deployment.
1. fiptool has a dependency on the host machine for OpenSSL and gcc.
2. fiptool resides under the TF-A repo and is used by Hafnium and SPs. This creates a cross-repository dependency.
As a workaround, we ship a prebuilt fiptool. But, due to OS dependency, this approach is not scalable across OS versions. E.g. One OS distribution might be using a lower OpenSSL version compared another, creating an incompatibility.
I was thinking if converting fiptool to a python script might help resolve these issues. Sptool was converted into a Python script, so was wondering if anyone has tried converting fiptool to a Python script too.
-Varun
Hi,
the code is still incorrect after half a year. It has been changed twice, without fixing it. There was no response to the report I created [1].
If there is no interest / lack of response I may get the impression that my contributions are not welcomed at TF-A. Thus, I decided to not report any issues in the future. Sadly, this is how the open source idea dies - at least for this project.
Best Regards,
Matthias
[1] https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.…
[Banner]<http://www.nio.io>
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. You may NOT use, disclose, copy or disseminate this information. If you have received this email in error, please notify the sender and destroy all copies of the original message and all attachments. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
Hi All,
Please review the patch-set that adds the functionality in RMM to manage Scalable Matrix Extension (SME) context. If the CPU supports SME and if Realm accesses FPU/SVE functionality then NS SME state is saved to allow Realm to use FPU/SVE register state.
https://review.trustedfirmware.org/q/topic:%22rmm_sme%22+(status:open%20OR%…
Brief summary of changes made in different components:
RMM:
- Introduces SIMD context and exports APIs to the runtime component of RMM to initialize, save, restore, and switch SIMD context.
- Adds SME support in RMM to manage NS SME context. Supports SVE+SME config and SME only config.
- Handles SVE hint bit passed in RMI SMCs
- Handles SME exceptions from Realms
https://review.trustedfirmware.org/q/topic:%22rmm_sme%22+(status:open%20OR%…
TF-A:
- Enables FEAT_SME for RMM
- Passes SMCCCv1.3 SVE hint bit in SMC function ID to RMM
tf-a-tests:
- There are changes in common lib routines for sve, sme so that testcases running in NS-EL2, S-EL1, R-EL1 can use these helper routines.
- Adds helper routines to read, write, compare FPU and SVE Z, P, FFR registers
- Adds SMCCCv1.3 SVE hint bit support in TFTF framework
- Enables SME/SME2 during arch init
- Adds SME helper routines and extends SVE lib routines to support streaming SVE mode.
https://review.trustedfirmware.org/q/topic:%22rmm_sme%22+(status:open%20OR%…
Thanks,
Arun
Hi,
I am looking at how console flags are used and setup.
In porting guide I see
Function : bl31_plat_runtime_setup() [optional]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
::
Argument : void
Return : void
The purpose of this function is allow the platform to perform any BL31 runtime
setup just prior to BL31 exit during cold boot. The default weak
implementation of this function will invoke ``console_switch_state()`` to switch
console output to consoles marked for use in the ``runtime`` state.
Some platform are calling it but some of them not (like our Xilinx one).
Tegra has in tegra_pwr_domain_power_down_wfi()
console_flush();
console_switch_state(0);
which is what none other has.
Should console_flush() be called by default all the time when console is
switched and also disabled when system goes down?
Why console_switch_state(CONSOLE_FLAG_RUNTIME) is not called from bl31_main()
when before bl31_plat_runtime_setup() is called we have console_flush() already?
The second part of this how console scope is setup.
Implementation is clear and set.
void console_set_scope(console_t *console, unsigned int scope)
{
assert(console != NULL);
console->flags = (console->flags & ~CONSOLE_FLAG_SCOPE_MASK) | scope;
}
The commit cc5859ca19ff ("Multi-console: Deprecate the `finish_console_register`
macro") when finish_console_register is called (DCC is exception here) is
setting up CONSOLE_FLAG_BOOT and CONSOLE_FLAG_CRASH by default.
And most of platforms is calling console registration with calling
console_set_scope() where new flags are recorded BOOT only, BOOT/RUNTIME,
RUNTIME only or BOOT/RUNTIME/CRASH.
I would like to understand what should be the right behavior.
Why are platforms removing CRASH flag after registration? (I see that a lot of
platforms are having private plat_crash_console_init() but pretty much crash
console is the same with regular console).
Why runtime console is setup directly in bl31_early_platform_setup2 when
guidance is saying that it should be done much later?
Also commit 63c52d0071ef ("plat/common/crash_console_helpers.S: Fix
MULTI_CONSOLE_API support") removed CONSOLE_FLAG_CRASH from
plat_crash_console_init but only from 64bit version. In 32bit version there is
still there. It suggest that any C code should be called.
Do we really need CONSOLE_FLAG_CRASH?
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP/Versal ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal/Versal NET SoCs
TF-A maintainer - Xilinx ZynqMP/Versal/Versal NET SoCs
This event has been canceled with a note:
"Hi, The TF-A Tech Forum instance on Sep 21st 2023 is cancelled due to lack
of topic. Thanks & Regards, Olivier. "
TF-A Tech Forum
Thursday Sep 21, 2023 ⋅ 5pm – 6pm
Central European Time - Paris
We run an open technical forum call for anyone to participate and it is not
restricted to Trusted Firmware project members. It will operate under the
guidance of the TF TSC. Feel free to forward this invite to
colleagues. Invites are via the TF-A mailing list and also published on the
Trusted Firmware website. Details are
here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr…
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap
mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US
(San Jose)Dial by your location +1 646 558
8656 US (New York) +1 669 900
9128 US (San Jose) 877 853 5247 US
Toll-free 888 788 0099 US Toll-freeMeeting ID:
915 970 4974Find your local
number: https://zoom.us/u/ad27hc6t7h
Guests
marek.bykowski(a)gmail.com
okash.khawaja(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. To
stop receiving future updates for this event, decline this 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,
Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan.
1 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan.
New defect(s) Reported-by: Coverity Scan
Showing 1 of 1 defect(s)
** CID 401729: Integer handling issues (CONSTANT_EXPRESSION_RESULT)
/drivers/st/ddr/stm32mp_ddr_test.c: 134 in stm32mp_ddr_check_size()
________________________________________________________________________________________________________
*** CID 401729: Integer handling issues (CONSTANT_EXPRESSION_RESULT)
/drivers/st/ddr/stm32mp_ddr_test.c: 134 in stm32mp_ddr_check_size()
128 uint32_t stm32mp_ddr_check_size(void)
129 {
130 uint32_t offset = sizeof(uint32_t);
131
132 mmio_write_32(STM32MP_DDR_BASE, DDR_PATTERN);
133
>>> CID 401729: Integer handling issues (CONSTANT_EXPRESSION_RESULT)
>>> "offset < 4294967296UL" is always true regardless of the values of its operands. This occurs as the logical operand of "while".
134 while (offset < STM32MP_DDR_MAX_SIZE) {
135 mmio_write_32(STM32MP_DDR_BASE + offset, DDR_ANTIPATTERN);
136 dsb();
137
138 if (mmio_read_32(STM32MP_DDR_BASE) != DDR_PATTERN) {
139 break;
________________________________________________________________________________________________________
To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…
Hello,
QEMU 8.1 added support for FEAT_RME. It is experimental, enabled with
'-cpu max,x-rme=on', and requires fixes that will be available in QEMU
8.2. I'm working on adding support to TF-A and TF-RMM.
I just submitted some TF-A patches for review (topic qemu-rme) that enable
the feature for the virt platform, and intend to send the necessary
changes for TF-RMM within a week or so. Without RMM, the Test Realm
Payload is included into the FIP for light testing.
After the TF-A and TF-RMM changes, I'd like to add support for the SBSA
platform as well, which should be a relatively small change once the
common QEMU support is merged.
Thanks,
Jean
---
Building TF-A for QEMU with RME support:
make -j CROSS_COMPILE=aarch64-linux-gnu- PLAT=qemu DEBUG=1
RMM=path/to/rmm/build/Debug/rmm.img ENABLE_RME=1
BL33=path/to/QEMU_EFI.fd QEMU_USE_GIC_DRIVER=QEMU_GICV3
all fip
dd if=tf-a/build/qemu/debug/bl1.bin of=flash.bin bs=4096 conv=notrunc
dd if=tf-a//build/qemu/debug/fip.bin of=flash.bin seek=64 bs=4096 conv=notrunc
Running QEMU, for example:
qemu-system-aarch64 -cpu max,x-rme=on,sme=off -m 3G -smp 8
-M virt,gic-version=3,virtualization=on,secure=on,acpi=off
-bios flash.bin
-kernel linux/arch/arm64/boot/Image
-initrd path/to/initrd
-append console=ttyAMA0
-nographic
...
[ 0.825891] kvm [1]: Using prototype RMM support (version 66.0)
SMC_RMM_FEATURES 0 > RMI_SUCCESS 33403e30
Hi all,
I find that the latest Arm A-profile manual (DDI0487_J_a) mention
several registers/instructions related to memory encryption (e.g.,
MECID-related registers). So can I ask two questions about it?
1. Is the FVP (I use the Base RevC AEM) support Memory Encryption
Context (MEC) and Memory Protection Engine (MPE)? They are critical to
memory encryption. If no, do we have some solutions to simulate them
and verify memory encryption?
2. Does current TF-A support managing MPE, or other hardware related
to memory encryption?
Besides that, one problem for curiosity (only related to FVP).
3. I find some PCI-E device can use hardware encryption (example,
NVIDIA H100 GPU). Can we attach this device to FVP's PCI-E port?
Assume it has already connected to my Host PC via PCI-E.
Sincerely,
WANG Chenxu
Hi All,
Note you may have received another instance of this note but when I
attempted to send to all TF ML's simultaneously it seemed to fail, so
sending to each one at a time. Sorry about that. :/
We've created a Discord Server for real time chats/sharing. This solution
comes at no cost to the project, is set up with channels for each project,
includes a #general channel, and supports direct 1-1 chats between members,
all with the goal of improving collaboration between trustedfirmware.org
developers.
We encourage all to join! :) Instructions for joining can be found on
the TF.org
FAQ page <https://www.trustedfirmware.org/faq/>.
See you all there and please don't hesitate to reach out if you have any
questions!
Don Harbin
TrustedFirmware Community Manager
don.harbin(a)linaro.org
It is observed that several unused functions are present in Trusted Firmware-A code, is it possible to mask those unused functions or leave them as it is to fix MISRA-C Violations? If these functions are not appearing in symbol table, then no need to take actions on violations reported in these functions? Please suggest.
This event has been canceled.
TF-A Tech Forum
Thursday Sep 7, 2023 ⋅ 4pm – 5pm
United Kingdom Time
We run an open technical forum call for anyone to participate and it is not
restricted to Trusted Firmware project members. It will operate under the
guidance of the TF TSC. Feel free to forward this invite to
colleagues. Invites are via the TF-A mailing list and also published on the
Trusted Firmware website. Details are
here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr…
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap
mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US
(San Jose)Dial by your location +1 646 558
8656 US (New York) +1 669 900
9128 US (San Jose) 877 853 5247 US
Toll-free 888 788 0099 US Toll-freeMeeting ID:
915 970 4974Find your local
number: https://zoom.us/u/ad27hc6t7h
Guests
marek.bykowski(a)gmail.com
okash.khawaja(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. To
stop receiving future updates for this event, decline this 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,
SCR_EL3.EA define whether to route External Abort and SError Interrupt to EL3 or EL2/1. ATF have a compile time flag to HANDLE_EA_EL3_FIRST_NS to program SCR_EL3.EA.
Below text from ATF documentation.
- ``HANDLE_EA_EL3_FIRST_NS``: When set to ``1``, External Aborts and SError
Interrupts, resulting from errors in NS world, will be always trapped in
EL3 i.e. in BL31 at runtime. When set to ``0`` (default), these exceptions
will be trapped in the current exception level (or in EL1 if the current
exception level is EL0).
Have question related to forwarding of these errors when External Abort and SError Interrupt are routed to EL3.
In this case will ATF forward Asynchronous SError Interrupt to Linux via RAS?
Thanks
-Bharat
It is observed that functions like macros like NOTICE, WARN and assert are present in the Trusted Firmware-A code. MISRA-C standard treats these as violations. shall we take these as deviation? please suggest.
TFA Guidelines recommends using logging macros. So can we make deviations or need to change the MACRO into function.