TF-A Community,
This is to notify that we are planning to target the Trusted Firmware-A 2.6 release during the fourth week of Nov 2021 as part of the regular 6 month cadence.
The aim is to consolidate all TF-A work since the 2.5 release. As part of this, a release candidate tag will be created and release activities will commence from 15th November 2021 across all TF-A repositories.
Essentially we will not merge any major enhancements from this date until the release is made.
Please ensure any patches desired to make the 2.6 release are submitted in good time to be complete by 12th November 2021.
Any major enhancement patches still open after that date will not be merged until after the release.
This will involve the various repositories making up the broader TF-A project including the TF-A mainline, TF-A Tests, Hafnium, TF-A CI Scripts and TF-A CI Jobs.
We will endeavour minimise the disruption on patch merging and complete release activities ASAP after we start.
Thanks
Joanna
Hi all,
What is the resolution for secure memory space with the Trust zone?
Is it dependent on the MMU resolution? Means, for example, If my MMU can set a range of 16 KB so can I set that range as a trusted zone as well?
P.S. I have ARM A35 (I am not sure but I think my MMU supports a resolution of 32KB)
You are welcome to comment if I have any mistakes
Thanks a lot,
Boaz.
________________________________
The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.
I want to know if we have a chance to support the compiler-based CFI(eg clang cfi, kernel support it.) function in tf-a.
I want to know that is anyone doing this, or if everyone is interested in this?
Cheers,
Feng
Hi HPChen
1. Can try setting PLATFORM_MAX_AFFLVL to MPIDR_AFFLVL2? I am assuming your platform has 1 cluster with 2 cores.
2. The project currently supports a limited number of platforms. The default test suite[1] contains several smaller test suites. The tests are designed to auto-detect critical features supported by the platform. Rather than fail, tftf will skip tests if a feature is not supported.
Please refer to the documentation for the tf-a-tests project here: https://trustedfirmware-a-tests.readthedocs.io/en/latest/index.html
[1] https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/tftf/tests/tests-s…
Thanks,
Madhukar
-----Original Message-----
From: TF-A <mailman-bounces(a)lists.trustedfirmware.org> On Behalf Of MS10 HPChen0
Sent: Tuesday, October 12, 2021 10:43 PM
To: tf-a-owner(a)lists.trustedfirmware.org
Subject: TFA affinity power level
Hi,
I'm Nuvoton software engineer. We have an A35 dual core platform. I ported the TFA for this platform.
Now I want test the TFA on test suite. I have some questions. Please help to answer. Thanks!
1. If define 'PLATFORM_MAX_AFFLVL' to MPIDR_AFFLVL1. The tftf test only identify single core no matter 'PLATFORM_CORES_PER_CLUSTER' define to 2.
How should I define 'PLATFORM_MAX_AFFLVL'?
2. How to select the test items? Should our platform need to pass all test items? Now I only test the tftf.
I'm new for TFA. Please help. Thanks!
Best regards,
HPChen
________________________________
________________________________
The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.
I noticed TF-A currently supports passing in 4 parameters and returning
up to 8. But SMCCC 1.1+ supports passing up to 18 and returning 18 in
AArch64 mode, and passing in/out 8 in AArch32.
I was wondering if there are any plans to add support for handling the
full set of parameters?
--
Rebecca Cran
Hi
I'm new to TF-A and OP Tee.
While I am using qemu to start TF-A, I got BL1 detected and failed to load
BL2, due to BL2 size out of bounds.
I changed TF-A BL1 source code to show more information:
diff --git a/common/bl_common.c b/common/bl_common.c
index 2fcb5385d9..a6239a5257 100644
--- a/common/bl_common.c
+++ b/common/bl_common.c
@@ -110,7 +111,7 @@ static int load_image(unsigned int image_id,
image_info_t *image_data)
/* Check that the image size to load is within limit */
if (image_size > image_data->image_max_size) {
- WARN("Image id=%u size out of bounds\n", image_id);
+ WARN("Image id=%u size(%lu, %u) out of bounds\n", image_id,
image_size, image_data->image_max_size);
io_result = -EFBIG;
goto exit;
}
the log shows:
NOTICE: Booting Trusted Firmware
NOTICE: BL1: v2.3():v2.3-dirty
NOTICE: BL1: Built : 15:56:43, Apr 20 2020
INFO: BL1: RAM 0xe04e000 - 0xe056000
VERBOSE: BL1: cortex_a57: CPU workaround for 806969 was not applied
WARNING: BL1: cortex_a57: CPU workaround for 813419 was missing!
VERBOSE: BL1: cortex_a57: CPU workaround for 813420 was not applied
VERBOSE: BL1: cortex_a57: CPU workaround for 814670 was not applied
WARNING: BL1: cortex_a57: CPU workaround for 817169 was missing!
INFO: BL1: cortex_a57: CPU workaround for disable_ldnp_overread was
applied
WARNING: BL1: cortex_a57: CPU workaround for 826974 was missing!
WARNING: BL1: cortex_a57: CPU workaround for 826977 was missing!
WARNING: BL1: cortex_a57: CPU workaround for 828024 was missing!
WARNING: BL1: cortex_a57: CPU workaround for 829520 was missing!
WARNING: BL1: cortex_a57: CPU workaround for 833471 was missing!
WARNING: BL1: cortex_a57: CPU workaround for 859972 was missing!
INFO: BL1: cortex_a57: CPU workaround for cve_2017_5715 was applied
INFO: BL1: cortex_a57: CPU workaround for cve_2018_3639 was applied
INFO: BL1: Loading BL2
VERBOSE: Using Memmap
WARNING: Firmware Image Package header check failed.
VERBOSE: Trying alternative IO
VERBOSE: Using Semi-hosting IO
INFO: Loading image id=1 at address 0xe01b000
WARNING: Image id=1 size(4294967295, 151552) out of bounds
ERROR: Failed to load BL2 firmware.
I'm using yocto (dunfell) + meta-arm to build / test TF-A + OP TEE under
qemuarm64.
meta-arm rev: c4f04f3fb66f8f4365b08b553af8206372e90a63
variables defined inside conf/local.conf ( for test )
23 MACHINE ?= "qemuarm64"
25
26 INSANE_SKIP_pn-optee-examples = "ldflags"
27 COMPATIBLE_MACHINE_pn-optee-examples = "qemuarm64"
28 COMPATIBLE_MACHINE_pn-optee-os = "qemuarm64"
29 COMPATIBLE_MACHINE_pn-optee-client = "qemuarm64"
30 COMPATIBLE_MACHINE_pn-trusted-firmware-a = "qemuarm64"
31
32 TFA_PLATFORM = "qemu"
33 TFA_UBOOT = "1"
34 TFA_DEBUG = "1"
35 TFA_SPD = "opteed"
36 TFA_BUILD_TARGET = "bl1 bl2 bl31"
37
38 OPTEEMACHINE:qemuarm64 = "vexpress-qemu_armv8a"
39 OPTEEOUTPUTMACHINE:qemuarm64 = "vexpress"
40
41 UBOOT_MACHINE_qemuarm64 = "qemu_arm64_defconfig"
I started qemu using following command line:
BIOS=tmp/deploy/images/qemuarm64/bl1.bin \
KERNEL=tmp/deploy/images/qemuarm64/Image-qemuarm64.bin \
runqemu mydefined-image-core-image-dev-optee nographic -d \
qemuparams=" \
-machine secure=on \
-m 4096 \
-d unimp -semihosting -semihosting-config enable=on,target=native \
"
Thanks
Hi all,
We made a few changes to the UFS driver. The proposed patches are posted
here:
https://review.trustedfirmware.org/q/topic:%22ufs_patches%22+(status:open%2…
.
The patches mainly consist of the below changes:
1. Delete asserts. Return error values instead.
2. Add retry logic and timeouts.
3. Reuse ufshc_send_uic_cmd() for DME_GET and DME_SET commands.
Any feedback/comments on these patches would be greatly appreciated.
Thanks!
Jorge Troncoso