Hi,
I would like to restart a discussion that we already had a few years
ago on a thread called "SMC to intentionally trigger a panic in TF-A"
(https://lists.trustedfirmware.org/archives/search?mlist=tf-a%40lists.truste…)
but that petered out without any real resolution (and resulted in me
ultimately not implementing the feature I was hoping to add).
Basically, we are repeatedly stumbling over the problem that we have a
use case for some platform-independent SMC API that we want to
implement in TF-A, but don't have an appropriate SMC FID range to put
it. My request from a few years ago was about implementing a call to
intentionally trigger a panic in TF-A for test-automation purposes.
Today we came up with a use case where a Trusted OS wants to query
BL31 about the location of a shared log buffer:
https://review.trustedfirmware.org/20478 .
Currently, the available SMC ranges are Arm, CPU, SiP, OEM, Standard,
Hypervisor, TA and TOS. The SiP, OEM and TOS ranges are all specific
to a single silicon vendor, OEM or trusted OS implementation, so they
are not good targets to implement APIs that would make sense to be
shared among multiple of these. In theory, the Standard range would
probably be the right target to implement calls that are independently
useful for multiple platforms / OSes... but as far as I understand,
adding a new call to that range requires petitioning Arm to update the
SMC calling convention itself, which is a ridiculously high bar to
implement a small utility API. In practice, the only choice we have
for implementing these kinds of calls is to let every OEM, SiP or TOS
assign its own (different) FID for it and then write separate SMC
handlers for each in TF-A that all end up calling the same underlying
function... which creates a lot of unnecessary code duplication and
identifier soup (especially in the case of SMCs for the non-secure OS
which would then be implemented by a platform-independent Linux driver
that needs a big mapping table to decide which FID to use on which
platform for the same API).
I think it would be very useful if there was another range of easily
allocatable FIDs that developers could just add to with a simple TF-A
CL without having to go through a huge specification update process.
There are still 41 OENs unused in the Arm SMCCC, and I don't think any
new ones were added in the 10 years that the specification existed...
so we are really not going to run out of them any time soon. If we
could get even one of those OENs for this purpose, we would have 64K
FIDs to use up for our small, simple platform-independent API needs,
which should last us a long while. We could maybe call it the "Secure
Monitor range" and say the FIDs are specific to a certain
implementation of Secure Monitor (e.g. TF-A). Then there could just be
a header file in the TF-A sources that serves as the authoritative FID
assignment table for TF-A, and anyone with a sufficiently useful idea
(subject to TF-A maintainer review) for a platform-independent API
like this could add it there by just uploading a patch.
I recently argued for a similar "simple tag allocation" concept on
https://github.com/FirmwareHandoff/firmware_handoff and it found
support there, so I hope I'll be able to convince you that it would be
useful for SMC FIDs as well?
Hello Jonathan and Kevar,
> I also see this issue when switching between Rockchip ATF and Upstream ATF.
>
> Versions:
> Rockchip DDR Blob - rk3399_ddr_800MHz_v1.30.bin
> Rockchip Miniloader - rk3399_miniloader_v1.30.bin
> Rockchip ATF - rk3399_bl31_v1.36.elf
> Upstream ATF - git://git.trustedfirmware.org/TF-A/trusted-firmware-a.git,
> git tag v2.8.0, with RK3399_BAUDRATE changed from 115200 to 1500000 in
> plat/rockchip/rk3399/rk3399_def.h
> U-Boot - git://git.denx.de/u-boot.git, git tag v2022.01
>
> Results:
> Rockchip DDR Blob + Rockchip Miniloader + Rockchip ATF + U-Boot = DMA working
> dma-pl330 ff6d0000.dma-controller: Loaded driver for PL330 DMAC-241330
> dma-pl330 ff6d0000.dma-controller: DBUFF-32x8bytes Num_Chans-6
> Num_Peri-12 Num_Events-12
> dma-pl330 ff6e0000.dma-controller: Loaded driver for PL330 DMAC-241330
> dma-pl330 ff6e0000.dma-controller: DBUFF-128x8bytes
> Num_Chans-8 Num_Peri-20 Num_Events-16
> Rockchip DDR Blob + Rockchip Miniloader + Upstream ATF + U-Boot = DMA
> not working
> OF: amba_device_add() failed (-19) for /bus/dma-controller@ff6d0000
> OF: amba_device_add() failed (-19) for /bus/dma-controller@ff6e0000
>
> I can't check the Rockchip ATF source code as it isn't available.
> Any idea what is different between Rockchip ATF and Upstream ATF for
> DMA to work properly?
@Kevar: It would be really great if you could have a look into it.
I am still having this issue.
Thanks
-- Christoph
Hello,
Recently I wondered who was the Code-Owner of the files in this patch:
fix(pmu): fix breakage on ARMv7 CPUs with SP_min as BL32
(https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/27162)
By the way it still doesn't have the Code-Owner review vote ;-)
But that triggered a more generic question about files and directories
in docs/about/maintainers.rst: are all the paths listed here reflect all
the files in TF-A repository?
The answer is unfortunately no.
I've then ended up writing some shell commands to try to list
unmaintained files:
for p in $(grep ^':|F|' docs/about/maintainers.rst | cut -d" " -f2 |
grep ^[a-zA-Z] | grep -v "drivers/nuvoton" | sed "s;\\\;;g"); do find $p
-type f >> /tmp/find_tf-a_maintained_files.txt; done; sort -u -o
/tmp/find_tf-a_maintained_files.txt{,}; git ls-files | sort -u >
/tmp/tf-a_files.txt; diff /tmp/find_tf-a_maintained_files.txt
/tmp/tf-a_files.txt > /tmp/tf-a_unmaintained_files.txt
Some are easy to correct, e.g. some docs/plat/<platform> files should be
added to the list of files for a given <platform>. Or some
include/drivers paths missing. I may push some patches for this if I
can. The drivers/nuvoton path is listed but it doesn't exist.
Some platforms or drivers are completely missing, and that would be good
their maintainers add a chapter for them.
But some generic & core files are also not listed. The goal of this mail
is to open the discussion about that.
That could be tricky as maintainer may change.
But all of that would ease the contributors way of working.
I've also seen that gerrit automatically adds Code-Owner for the review.
So it seems there is another list for that, and we could somehow try to
align those 2 lists.
Best regards,
Yann
We do nightly testing of our yocto layers against the latest kernel,
uboot, trusted-firmware-a, and optee. On April 12th we started getting
a build failure with trusted-firmware-a. I have tracked the issue down
to this commit:
https://github.com/ARM-software/arm-trusted-firmware/commit/71c42e98bbe900a…
Specifically, the line in make_helpers/utilities.mk:
escape-shell = '$(subst ','\'',$(1))'
On the surface it feels like the ' is overused and might cause issues.
I tried making the line:
escape-shell = $(subst ','\'',$(1))
And the builds went back to working properly. Does that seem like a
change that should be made, or was there a reason for the extra '' wrapper?
I have submitted a GitHub issue about this as well:
https://github.com/TrustedFirmware-A/trusted-firmware-a/issues/7
--
Ryan Eatmon reatmon(a)ti.com
-----------------------------------------
Texas Instruments, Inc. - LCPD - MGTS
Hi,
I'm upgrading the ATF I use from 2.4 to 2.8, and ran into a header
conflict. The change
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/13806
introduced an inclusion of
include/drivers/arm/gicv3.h
in lib/el3_runtime/aarch64/context_mgmt.c, but in my build environment that
.c file also includes
include/drivers/arm/gicv2.h
so now I get macro redefinition of "INT_ID_MASK" errors when compiling. Is
it an error, that in my build environment the gicv2.h gets included ?
I've solved it locally by doing:
diff --git a/lib/el3_runtime/aarch64/context_mgmt.c
b/lib/el3_runtime/aarch64/context_mgmt.c
index 866ac4154..395635a86 100644
--- a/lib/el3_runtime/aarch64/context_mgmt.c
+++ b/lib/el3_runtime/aarch64/context_mgmt.c
@@ -18,7 +18,9 @@
#include <common/bl_common.h>
#include <common/debug.h>
#include <context.h>
+#if CTX_INCLUDE_EL2_REGS
#include <drivers/arm/gicv3.h>
+#endif
#include <lib/el3_runtime/context_mgmt.h>
#include <lib/el3_runtime/pubsub_events.h>
#include <lib/extensions/amu.h>
but I am not sure whether this is the correct fix or not, or if I am doing
something else wrong here. Any suggestions on what would be the correct fix
?
Regards
Jacob
Hi, In the TF-A Tech Forum on Apr 18th at 4.00pm BST, Javier Almansa
Sobrino will present the topic of TF-RMM Stage-1 Memory management, by his
own words: "This week's TF-A Tech Forum will present the TF-RMM Stage 1
Memory Management, where we will discuss the design of the TF-RMM memory
space as well as some implementation details and future work." Regards,
Olivier.
TF-A Tech Forum
Thursday Apr 18, 2024 ⋅ 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/Trusted
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://linaro-org.zoom.us/my/trustedfirmware?pwd=VktXcm5MNUUyVVM4R0k3ZUtvdU84QT09
One 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
tf-a(a)lists.trustedfirmware.org
marek.bykowski(a)gmail.com
okash.khawaja(a)gmail.com
Hi ,
As I understand , there are separate page tables in MMU for EL2 and EL3 .
If a memory region is mapped as secure memory (MT_SECURE , MT_MEMORY, MT_RW) in bl31 code which runs in EL3 ,
and the same memory region is mapped again with same attributes (MT_SECURE , MT_MEMORY, MT_RW ) in EL2 , will EL2 be able to read and write to EL3 secure memory region ?
Regards
Amit
Hi,
I tried to follow the contribution guide but was unable to push the patch
to gerrit for review. "git review" just hangs with nothing happening.
The patch I want to push for review is:
From 198af98d05cfb4704aa2387eaa0a1e606a7968de Mon Sep 17 00:00:00 2001
From: Jacob Kroon <jacob.kroon(a)gmail.com>
Date: Fri, 12 Apr 2024 13:11:36 +0200
Subject: [PATCH] fix(gic): Fix SGIR_NSATT bitshift
See
https://documentation-service.arm.com/static/5f8ff196f86e16515cdbf969?token=
Fixes: dcb31ff79096fc88b45df8068e5de83b93f833ed
Signed-off-by: Jacob Kroon <jacob.kroon(a)gmail.com>
---
include/drivers/arm/gicv2.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drivers/arm/gicv2.h b/include/drivers/arm/gicv2.h
index bebd9ceff..c7c441d78 100644
--- a/include/drivers/arm/gicv2.h
+++ b/include/drivers/arm/gicv2.h
@@ -51,7 +51,7 @@
#define SGIR_TGTLSTFLT_MASK U(0x3)
#define SGIR_TGTLST_SHIFT 16
#define SGIR_TGTLST_MASK U(0xff)
-#define SGIR_NSATT (U(0x1) << 16)
+#define SGIR_NSATT (U(0x1) << 15)
#define SGIR_INTID_MASK ULL(0xf)
#define SGIR_TGT_SPECIFIC U(0)
--
2.39.2
Are there any suggestions on what I should do next ?
Regards
Jacob
This event has been canceled with a note:
"Hi, Cancelling as no topic planned. Regards, Olivier. "
TF-A Tech Forum
Thursday Apr 4, 2024 ⋅ 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/Trusted
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://linaro-org.zoom.us/my/trustedfirmware?pwd=VktXcm5MNUUyVVM4R0k3ZUtvdU84QT09
One 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 424695: Incorrect expression (SIZEOF_MISMATCH)
/services/std_svc/rmmd/rmmd_main.c: 237 in rmmd_setup()
________________________________________________________________________________________________________
*** CID 424695: Incorrect expression (SIZEOF_MISMATCH)
/services/std_svc/rmmd/rmmd_main.c: 237 in rmmd_setup()
231
232 assert((shared_buf_size == SZ_4K) &&
233 ((void *)shared_buf_base != NULL));
234
235 /* Zero out and load the boot manifest at the beginning of the share area */
236 manifest = (struct rmm_manifest *)shared_buf_base;
>>> CID 424695: Incorrect expression (SIZEOF_MISMATCH)
>>> Passing argument "manifest" of type "struct rmm_manifest *" and argument "8UL /* sizeof (manifest) */" to function "memset" is suspicious.
237 memset((void *)manifest, 0, sizeof(manifest));
238
239 rc = plat_rmmd_load_manifest(manifest);
240 if (rc != 0) {
241 ERROR("Error loading RMM Boot Manifest (%i)\n", rc);
242 return rc;
________________________________________________________________________________________________________
To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2…
Hi All,
Please note build option `ENABLE_FEAT_MTE` is now depcreated[1] and not handled
anymore part of TF-A since there is no setting needed in EL3 to enable MTE to be
used at EL0. However please note MTE at EL2/EL1 will require setting of
ENABLE_FEAT_MTE2 build option[2].
This is also a breaking change for platforms and downstream code that uses
MTE at EL2/EL1 without any configuration from TF-A but now SCR_EL3.ATA bit(26)
which was set unconditionally prior to this change[3] is now fixed and moved
correctly under ENABLE_FEAT_MTE2[3].
Going forward use build option `ENABLE_FEAT_MTE2` to use MTE at EL2/EL1.
--
Thanks,
Govindraj R
[1]: https://review.trustedfirmware.org/q/topic:%22mte_fixes%22
[2]: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/27122/19/doc…
[3]: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/26891
Hi ,
I am using TF-A tests tests-single-fault.mk to inject RAS errors on AMD Xilinx platform which is cortex a-78 armv8.2 based.
With this test , I can see RAS exceptions are getting triggered at EL2 .
I want to trap this exception at EL3 and handle RAS errors further using FFH approach.
From code , I could see fvp platform using FAULT_INJECTION_SUPPORT=1 , but from documentation it is meant from ARMv8.4 .
I am following https://www.trustedfirmware.org/docs/RAS_Tech_Forum.pdf .
Another option is RAS_ALLOW_ERR_REC_ACCESS_NS , but in the pdf , for FFH it is mentioned RAS_ALLOW_ERR_REC_ACCESS_NS should be 0.
Can I be advised what should be done to trap the RAS exception at EL3 on armv8.2 cortex a78 platform ?
Regards
Amit
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.
New defect(s) Reported-by: Coverity Scan
Showing 3 of 3 defect(s)
** CID 424609: Parse warnings (PW.PARAM_SET_BUT_NOT_USED)
/plat/nuvoton/npcm845x/npcm845x_bl31_setup.c: 132 in ()
________________________________________________________________________________________________________
*** CID 424609: Parse warnings (PW.PARAM_SET_BUT_NOT_USED)
/plat/nuvoton/npcm845x/npcm845x_bl31_setup.c: 132 in ()
126 * in BL2 & EL3 in BL1) before they are lost (potentially). This needs to be
127 * done before the MMU is initialized so that the memory layout can be used
128 * while creating page tables. BL2 has flushed this information to memory,
129 * so we are guaranteed to pick up good data.
130 *****************************************************************************/
131 void bl31_early_platform_setup2(u_register_t arg0, u_register_t arg1,
>>> CID 424609: Parse warnings (PW.PARAM_SET_BUT_NOT_USED)
>>> parameter "arg2" was set but never used
132 u_register_t arg2, u_register_t arg3)
133 {
134 arg0 = arg1 = arg2 = arg3 = 0;
135 #if RESET_TO_BL31
136 void *from_bl2 = (void *)arg0;
137 void *plat_params_from_bl2 = (void *)arg3;
** CID 424608: Integer handling issues (CONSTANT_EXPRESSION_RESULT)
/drivers/arm/mhu/mhu_v3_x.c: 75 in mhu_v3_x_driver_init()
________________________________________________________________________________________________________
*** CID 424608: Integer handling issues (CONSTANT_EXPRESSION_RESULT)
/drivers/arm/mhu/mhu_v3_x.c: 75 in mhu_v3_x_driver_init()
69 /* Unsupported MHU version */
70 return MHU_V_3_X_ERR_UNSUPPORTED_VERSION;
71 }
72
73 /* Read the MHU Architecture Minor Revision */
74 dev->subversion =
>>> CID 424608: Integer handling issues (CONSTANT_EXPRESSION_RESULT)
>>> "(aidr & (15U /* 0xfU << 0U */)) >> (15U /* 0xfU << 0U */)" is 0 regardless of the values of its operands. This occurs as the operand of assignment.
75 ((aidr & MHU_ARCH_MINOR_REV_MASK) >> MHU_ARCH_MINOR_REV_MASK);
76
77 /* Return error if the MHU minor revision is not 0 */
78 if (dev->subversion != MHU_MINOR_REV_3_0) {
79 /* Unsupported subversion */
80 return MHU_V_3_X_ERR_UNSUPPORTED_VERSION;
** CID 424607: Parse warnings (PW.PARAM_SET_BUT_NOT_USED)
/plat/nuvoton/npcm845x/npcm845x_bl31_setup.c: 131 in ()
________________________________________________________________________________________________________
*** CID 424607: Parse warnings (PW.PARAM_SET_BUT_NOT_USED)
/plat/nuvoton/npcm845x/npcm845x_bl31_setup.c: 131 in ()
125 * Here is an opportunity to copy parameters passed by the calling EL (S-EL1
126 * in BL2 & EL3 in BL1) before they are lost (potentially). This needs to be
127 * done before the MMU is initialized so that the memory layout can be used
128 * while creating page tables. BL2 has flushed this information to memory,
129 * so we are guaranteed to pick up good data.
130 *****************************************************************************/
>>> CID 424607: Parse warnings (PW.PARAM_SET_BUT_NOT_USED)
>>> parameter "arg1" was set but never used
131 void bl31_early_platform_setup2(u_register_t arg0, u_register_t arg1,
132 u_register_t arg2, u_register_t arg3)
133 {
134 arg0 = arg1 = arg2 = arg3 = 0;
135 #if RESET_TO_BL31
136 void *from_bl2 = (void *)arg0;
________________________________________________________________________________________________________
To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2…
This event has been canceled with a note:
"Hi, Cancelling this instance as no topic planned. Regards, Olivier. "
TF-A Tech Forum
Thursday Mar 21, 2024 ⋅ 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/Trusted
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://linaro-org.zoom.us/my/trustedfirmware?pwd=VktXcm5MNUUyVVM4R0k3ZUtvdU84QT09
One 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,
I find that Arm has considered "device for realms" and purposed RME-DA
since last year. This is not only a concept but also includes some
SMMU hardware extensions (e.g., Realm Page MMIO and DPT).
Unfortunately, I only find few contents related to RME-DA in the
latest FVP user guide, and nothing in TF-A/TF-RMM.
Thus, can I ask
1. Does current FVP simulate the RME-DA?
2. Will TF-A/TF-RMM supports RME-DA recently?
Sincerely,
WANG Chenxu
Hi Olivier Deprez,
We use the SPM_MM framework mainly for read/write control of security variables. We do not want to modify the original application code at this time.
At the same time we want to add support for the new SPMD framework based code.
________________________________
Hi Baopeng,
By "code based on the SPM_MM framework" I assume you refer to a secure service running in a S-EL0 partition based on the MM protocol? If you can share this information, what kind of service is this implementing? RAS handling, secure variables, TPM back end, other? What kind of interface is needed to access the service? asynchronous with interrupts? synchronous with SMC from normal world? Another question is why do you need to collocate the SPMD if the MM implementation is already achieving the scenarios you need?
Ideally you'd want to migrate this service to run on top of:
* the EL3 FF-A SPMC https://trustedfirmware-a.readthedocs.io/en/latest/components/el3-spmc.html * or if the HW/chipset implements it, the S-EL2 FF-A SPMC https://hafnium.readthedocs.io/en/latest/secure-partition-manager/index.htm…
Knowing the kind of S-EL0 service would help narrowing the effort for a migration.
FF-A (https://developer.arm.com/documentation/den0077/latest/) is a modern evolution of MM (https://developer.arm.com/documentation/den0060/latest) and any functionality achieved by the MM protocol can be handled by FF-A. For example the MM_COMMUNICATE interface can be easily swapped by the FFA_MSG_SEND_DIRECT_REQ interface.
Regards, Olivier.
________________________________ From: baopeng (A) via TF-A tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Sent: 21 February 2024 07:10 To: tf-a(a)lists.trustedfirmware.org tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Subject: [TF-A] Re: Request for help
Hi Olivier Deprez,
We have developed code based on the SPM_MM framework and do not want to reconstruct the code. However, we want to adapt the code to the SPMD framework.
What should we do?
________________________________
Hi Baopeng,
SPM_MM is the legacy implementation for a secure partition manager relying on the MM protocol. This implementation gets deprecated in favor of FF-A based implementations (what you refer to as SPMD + SPMC). Both implementations aren't compatible and it is discouraged to attempt co-locating both. It may be more palatable and future proof to transition all your SW stack to be compliant to FF-A standard.
We may help you better if you tell a bit more about the reason for mixing both implementations in the same build.
Regards, Olivier.
________________________________ From: baopeng (A) baopeng1@huawei.commailto:baopeng1@huawei.com Sent: 20 February 2024 02:19 To: tf-a-owner(a)lists.trustedfirmware.org tf-a-owner@lists.trustedfirmware.orgmailto:tf-a-owner@lists.trustedfirmware.org Subject: Request for help
Dear Sir/ Madam,
we need to support the simultaneous loading of SPMD and SPM_MM due to project reasons.
However, we notice that the makefile of SPM_MM of ATF does not support the simultaneous loading of SPMD and SPM_MM by default.
I would like to ask what is the main reason for making the current restrictions?
This event has been updated with a note:
"Updating invite link"
Changed: description
TF-A Tech Forum
Every 2 weeks from 9am to 10am on Thursday
Mountain Standard Time - Phoenix
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/Trusted
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://linaro-org.zoom.us/my/trustedfirmware?pwd=VktXcm5MNUUyVVM4R0k3ZUtvdU84QT09
One 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
tf-a(a)lists.trustedfirmware.org
marek.bykowski(a)gmail.com
okash.khawaja(a)gmail.com
View all guest info
https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…
Reply for tf-a(a)lists.trustedfirmware.org and view more details
https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…
Your attendance is optional.
~~//~~
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 415256: Memory - corruptions (ARRAY_VS_SINGLETON)
________________________________________________________________________________________________________
*** CID 415256: Memory - corruptions (ARRAY_VS_SINGLETON)
/qcbor/src/qcbor_decode.c: 3725 in QCBORDecode_ExitBoundedMapOrArray()
3719 that is being exited. If there is no cached value,
3720 from previous map search, then do a dummy search.
3721 */
3722 if(pMe->uMapEndOffsetCache == QCBOR_MAP_OFFSET_CACHE_INVALID) {
3723 QCBORItem Dummy;
3724 Dummy.uLabelType = QCBOR_TYPE_NONE;
>>> CID 415256: Memory - corruptions (ARRAY_VS_SINGLETON)
>>> Passing "&Dummy" to function "MapSearch" which uses it as an array. This might corrupt or misinterpret adjacent memory locations.
3725 uErr = MapSearch(pMe, &Dummy, NULL, NULL, NULL);
3726 if(uErr != QCBOR_SUCCESS) {
3727 goto Done;
3728 }
3729 }
3730
________________________________________________________________________________________________________
To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2…
Hi ,
We want to include ENABLE_LTO option in platform build.
Can you please recommend if this can be passed only on the build command line, or it can be included in the platform makefile (platform.mk) also.
Regards,
Prasad.
Hi,
Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan.
2 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan.
New defect(s) Reported-by: Coverity Scan
Showing 2 of 2 defect(s)
** CID 415033: Memory - corruptions (OVERRUN)
/lib/extensions/amu/aarch64/amu.c: 471 in amu_context_save()
________________________________________________________________________________________________________
*** CID 415033: Memory - corruptions (OVERRUN)
/lib/extensions/amu/aarch64/amu.c: 471 in amu_context_save()
465 for (i = 0U; i < amcgcr_el0_cg0nc; i++) {
466 ctx->group0_cnts[i] = amu_group0_cnt_read(i);
467 }
468
469 #if ENABLE_AMU_AUXILIARY_COUNTERS
470 for (i = 0U; i < amcgcr_el0_cg1nc; i++) {
>>> CID 415033: Memory - corruptions (OVERRUN)
>>> Overrunning array "ctx->group1_cnts" of 16 8-byte elements at element index 254 (byte offset 2039) using index "i" (which evaluates to 254).
471 ctx->group1_cnts[i] = amu_group1_cnt_read(i);
472 }
473 #endif
474
475 /*
476 * Save virtual offsets for counters that offer them.
** CID 415032: Memory - illegal accesses (OVERRUN)
/lib/extensions/amu/aarch64/amu.c: 548 in amu_context_restore()
________________________________________________________________________________________________________
*** CID 415032: Memory - illegal accesses (OVERRUN)
/lib/extensions/amu/aarch64/amu.c: 548 in amu_context_restore()
542 for (i = 0U; i < amcgcr_el0_cg0nc; i++) {
543 amu_group0_cnt_write(i, ctx->group0_cnts[i]);
544 }
545
546 #if ENABLE_AMU_AUXILIARY_COUNTERS
547 for (i = 0U; i < amcgcr_el0_cg1nc; i++) {
>>> CID 415032: Memory - illegal accesses (OVERRUN)
>>> Overrunning array "ctx->group1_cnts" of 16 8-byte elements at element index 254 (byte offset 2039) using index "i" (which evaluates to 254).
548 amu_group1_cnt_write(i, ctx->group1_cnts[i]);
549 }
550 #endif
551
552 /*
553 * Restore virtual offsets for counters that offer them.
________________________________________________________________________________________________________
To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2…