- Hafnium - lists.trustedfirmware.org

by Olivier Deprez

Hi, You must have noticed slowness or breakages with review.trustedfirmware.org or git.trustedfirmware.org during the week. There are high and lows of network bandwidth usage affecting server availability. The issue is being investigated but not yet 100% root caused. Apologies for the frustration and inconvenience that this is causing. Rest assured the team is on board to resolve this unfortunate situation. Regards, Olivier.

1 week, 3 days

1
0
0 0

Notification setup failed log in the latest Linux

by Sungbae Yoo

Hi, I have a couple of questions related to notification. Recently, we are working on kernel upgrade and I found this log while booting. | genirq: Flags mismatch irq 6. 00004401 (ARM-FFA-NPI) vs. 00004400 (IPI) | ARM FF-A: Error registering percpu NPI nIRQ 6 : -16 | ARM FF-A: Notification setup failed -16, not enabled This does not affect the other functionalities when I tested using xtest of OP-TEE. And, I found a commit [1] related this log in linux kernel and it said | If the firmware returns incorrect SRI/NRI number, we fail to set it up | in the kernel which is absolutely fine. So I checked hafnium and I found that hafnium returns "5" as HF_NOTIFICATION_PENDING_INTID [2] and it conflicts with IPI numbers (IPI_TIMER) [3]. So the question is : 1. HF_NOTIFICATION_PENDING_INTID seems to be conflicted. Do you have any plan to change its number greater than MAX_IPI? 2. Or, Is there the other way to avoid IRQ number conflicts? I mean, Did I miss something to configure? 3. Actually, I haven't find any use-case of notification yet. so notification is still working in progress? [1] https://lore.kernel.org/linux-arm-kernel/171396205191.700527.18157351542957… [2] https://github.com/TF-Hafnium/hafnium/blob/main/inc/vmapi/hf/types.h#L62 [3] https://elixir.bootlin.com/linux/v6.14.1/source/arch/arm64/kernel/smp.c#L72

1 week, 4 days

3
3
0 0

Firmware-A v2.13 release code freeze notification

by Olivier Deprez

Hi All, The next release of the Firmware-A bundle of projects tagged v2.13 has an expected code freeze date of May, 2nd 2025. In order to accommodate the Linaro connect event occurring during the week of May 12th we may extend the release completion date up until the week of May 26th. v2.13 release preparation tasks start from now. We want to ensure that planned feature patches for the release are submitted in good time for the review process to conclude. As a kind recommendation and a matter of sharing CI resources, please launch CI jobs with care e.g.: -For simple platform, docs changes, or one liners, use Allow-CI+1 label (no need for a full Allow-CI+2 run). -For large patch stacks use Allow-CI+2 at top of the patch stack (and if required few individual Allow+CI+1 labels in the middle of the patch stack). -Carefully analyze results and fix the change if required, before launching new jobs on the same change. -If after issuing a Allow-CI+1 or Allow-CI+2 label a Build start notice is not added as a gerrit comment on the patch right away please be patient as under heavy load CI jobs can be queued and in extreme conditions it can be over an hour before the Build start notice is issued. Issuing another Allow-CI+1 or Allow-CI+2 label will just result in an additional job being queued. Regards, Olivier.

3 weeks, 4 days

1
0
0 0

Firmware-A v2.12 release follow up - shrinkwrap

by Olivier Deprez

Hi, As a follow up to the Firmware-A v2.12 release [1], we are pleased to share the shrinkwrap tool [2] configurations have been updated to consume latest firmware/upstream ingredients using following tags: TF-A: v2.12.0 TF-a-tests: v2.12.0 Hafnium: v2.12.0 TF-RMM: tf-rmm-v0.6.0 CCA EDK2: 3223_arm_cca_rmm_v1.0_rel0_v3 linux: cca-full/v5+v7 kvmtool: cca/v3 An additional merge request is in queue for kvm-unit-tests update to cca/rmm-v1.0-rel0 tag. Shrinkwrap is a convenient tool for building a fully integrated Arm CCA SW stack running on the Base AEM FVP platform. In particular this is the tool of choice for RMM development to reproduce a 3 or 4 worlds RME based environment. Regards, Olivier. [1] https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.… [2] https://shrinkwrap.docs.arm.com/en/latest/

4 months, 3 weeks

1
0
0 0

Trusted Firmware v2.12 release announcement

by Olivier Deprez

Hi All, We are pleased to announce the formal release of Trusted Firmware-A version 2.12 bundle of project deliverables. This includes Trusted Firmware-A, Trusted Firmware-A Tests, Hafnium, RMM, Trusted Services, and TF-A OpenCI scripts/jobs components. These went live on Nov, 21st 2024. Please find references to tags and change logs at the end of this email. Many thanks to the trustedfirmware.org community for the active engagement in delivering this release! Notable features of the release version 2.12 are as follows: TF-A/EL3 * New CPUs support: Cortex-A320 (Arcadia), Cortex-A720AE. * Arch extensions: : FEAT_THE, FEAT_LS64_ACCDATA, FEAT_Debugv8p9, FEAT_SCTLR2, FEAT_FGT2 ; Arm 9.4 : FEAT_D128 support. * Context management: Asymmetric CPU features, EL3 execution context, SVE S/R support. * RME: GPT contiguous descriptor (or GPT large mappings support). * Arm CCA: added attestation generic library, el3 attestation token signing support. Boot flow * Tools: * Introduced the Transfer List Compiler (TLC) Host Tool supporting the FW hand-off specification. * Introduced CoT Device Tree to C File (DT2C) tool. * mbedTLS Improvements: * Resolved random authentication failures with ECDSA. * Enhanced mbedTLS configuration selection. * Maximize usage of mbedTLS library APIs in TF-A. * Upgraded to mbedTLS v3.6.1. * Feature addition/support: * Support for the ECDSA P-384 curve with the PSA Crypto implementation. * Documentation: * Added the DPE Design and Threat Model document to TF-A readthedocs. Errata (CPU/GIC) * Cortex-A720, Cortex-A520, Cortex-X4 errata. TF-A platforms support * New platforms added: TC4, RD-1 AE, RK3566/RK3568. * Platform fixes: FPGA, FVP, Neoverse-RD, TC, Corstone-1000, Allwinner, AST2700, Poplar, Agilex, A3K, MT8188, iMX8M, S32G274A, qemu, Rpi3, Rockchip, STM32MP1, STM32MP2, Versal, ZynqMP. Hafnium/SPM (S-EL2) * FF-A features additions * FF-A v1.2 FFA_MSG_WAIT RX buffer ownership flag. * FF-A v1.2 FFA_VERSION endpoint restriction. * FF-A v1.1 VM availability messages. * Architectural support * vCPU IPI signaling. * Arch timer virtualization. * RME: GPF support and memcpy hardening. * Secure Interrupt Handling for UP S-EL1 partitions. TF-RMM (R-EL2) * REL0 RMM 1.0 support. * Support for alternative attestation token signing via EL3. * Various improvements and bugfixes as listed in the change log. TF-A Tests * Arm arch. extensions: AMU, FEAT_FGT2, LS64_ACCDATA, FEAT_Debugv8p9, LS64 64-byte load/store. * Asymmetric feature testing (FEAT_SPE, FEAT_TRBE, FEAT_TCR2). * EL1 and EL2 context switch tests. * FF-A: v1.2 support, S-EL2 arch timer virtualization, S-EL2+RME hardening, EL3 SPMC TFTF test suite, EL3 SVE test coverage. * RME: RMM v1.0 testing support, PCIe DOE support, RMI support for FEAT_LPA2, SIMD, PAuth. * Platforms: AMD Versal Gen 2 added, Neoverse-RD refactoring, FVP PCIe support. Release tags across repositories: https://git.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/+/r… https://git.trustedfirmware.org/plugins/gitiles/TF-A/tf-a-tests/+/refs/tags… https://git.trustedfirmware.org/plugins/gitiles/ci/tf-a-ci-scripts/+/refs/t… https://git.trustedfirmware.org/plugins/gitiles/ci/tf-a-job-configs/+/refs/… https://git.trustedfirmware.org/plugins/gitiles/hafnium/hafnium/+/refs/tags… https://git.trustedfirmware.org/plugins/gitiles/ci/hafnium-ci-scripts/+/ref… https://git.trustedfirmware.org/plugins/gitiles/ci/hafnium-job-configs/+/re… https://git.trustedfirmware.org/plugins/gitiles/TF-RMM/tf-rmm/+/refs/tags/t… https://git.trustedfirmware.org/plugins/gitiles/TS/trusted-services/+/refs/… Change logs: https://trustedfirmware-a.readthedocs.io/en/v2.12.0/change-log.html#id1 https://trustedfirmware-a-tests.readthedocs.io/en/latest/change-log.html#ve… https://hafnium.readthedocs.io/en/v2.12.0/change-log.html#v2-12 https://tf-rmm.readthedocs.io/en/latest/about/change-log.html#v0-6-0 Regards, Olivier.

5 months, 1 week

1
0
0 0

Firmware-A v2.12 release code freeze notification

by Govindraj Raja

Hi All, The next release of the Firmware-A bundle of projects tagged v2.12 has an expected code freeze date of Nov, 8th 2024. Refer to the release cadence section from TF-A documentation (https://trustedfirmware-a.readthedocs.io/en/latest/about/release-informatio…). Closing out the release takes around 6-10 working days after the code freeze. v2.12 release preparation tasks start from now. We want to ensure that planned feature patches for the release are submitted in good time for the review process to conclude. As a kind recommendation and a matter of sharing CI resources, please launch CI jobs with care e.g.: -For simple platform, docs changes, or one liners, use Allow-CI+1 label (no need for a full Allow-CI+2 run). -For large patch stacks use Allow-CI+2 at top of the patch stack (and if required few individual Allow+CI+1 labels in the middle of the patch stack). -Carefully analyze results and fix the change if required, before launching new jobs on the same change. -If after issuing a Allow-CI+1 or Allow-CI+2 label a Build start notice is not added as a gerrit comment on the patch right away please be patient as under heavy load CI jobs can be queued and in extreme conditions it can be over an hour before the Build start notice is issued. Issuing another Allow-CI+1 or Allow-CI+2 label will just result in an additional job being queued. -- Thanks, Govindraj R

5 months, 2 weeks

1
1
0 0

Re: TF-A Tech Forum regular call

by Olivier Deprez

+ other MLs ________________________________ From: Olivier Deprez Sent: 30 October 2024 11:41 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: TF-A Tech Forum regular call Dear TF-A ML members, As mentioned in https://www.trustedfirmware.org/meetings/tf-a-technical-forum/, trustedfirmware.org hosts regular technical calls on Thursdays. It mentions TF-A although in practise a number of Cortex-A projects beyond TF-A were discussed (refer to prior recordings on this page). Unfortunately this slot hasn't been very active recently. By this email I'm kindly emphasizing this forum is open to the community (and beyond trustedfirmware.org members) and you are welcome to propose topics. Presentations/slides are not strictly necessary, and we can also host informal discussions or session of questions. If you think of a topic, please reach to me and I'll be happy to accommodate. Thanks for your contributions in advance! Regards, Olivier.

6 months

1
0
0 0

Hafnium in Industry

by Friedrich

Hi, Can someone explain to me where and why Hafnium is used in the industry? I've only ever seen it being used in academic research. Thanks, Friedrich

7 months, 1 week

2
1
1 0

Current status of NWd driver for secondary VM SMP support

by Sungbae Yoo

Hi, I have a couple of question about SMP support of linux driver. We'd like to run multiple SP that uses secondary cores. The first SP can initialize all secondary vCPUs when linux invokes cpu on for all secondary cores. But the other SP doesn't initialize its secondary vCPUs. If My understanding is correct, they will be initialized when FFA_RUN calls to each vCPUs are called [1] and FFA_RUN calls are called by Normal world driver in linux [2]. But I can't find any implementations regarding this in the latest upstream linux (v6.10). Actually, I found ffa_cpu_ops in linux code [3], but couldn't the place where it is used. I think that ffa_run has to be called in driver to initialize secodary vCPUs of secondary VMs. Am I missing something in the code? Or Is there no implementation yet in upstream? I'd like to know about the current status of secondary VM SMP support in linux. If linux driver doesn't support it yet, Do you have any plan to make an implementation and merge it? Thanks, Sungbae Yoo. [1] https://hafnium.readthedocs.io/en/latest/secure-partition-manager/secure-pa… [2] https://lists.trustedfirmware.org/archives/list/hafnium@lists.trustedfirmwa… [3] https://elixir.bootlin.com/linux/v6.11-rc5/source/drivers/firmware/arm_ffa/…

8 months

2
1
0 0

Could you add a new gicd_set_ctlr() API to set GICD_CTLR to wait until RWP becomes zero?

by magicse7en＠outlook.com

Hi , Could you add below patch to gicv3_helpers.h? --- a/src/arch/aarch64/plat/interrupts/gicv3_helpers.h +++ b/src/arch/aarch64/plat/interrupts/gicv3_helpers.h @@ -203,6 +203,16 @@ static inline void gicd_wait_for_pending_write(uintptr_t gicd_base) } } +static inline void gicd_set_ctlr(uintptr_t base, + unsigned int bitmap, + unsigned int rwp) +{ + gicd_write_ctlr(base, gicd_read_ctlr(base) | bitmap); + if (rwp != 0U) { + gicd_wait_for_pending_write(base); + } +} + static inline uint32_t gicd_read_pidr2(uintptr_t base) { return io_read32(IO32_C(base + GICD_PIDR2_GICV3)); The existed gicd_write_ctlr() just write the GICD_CTLR, but from GIC spec, if write GICD_CTLR, it needs to wait the RWP bit becomes zero. Therefore, I think the gicd_set_ctlr() function of tf-a is a good choice. I tried to push this patch to https://review.trustedfirmware.org/, but I encountered below error. error: RPC failed; HTTP 403 curl 22 The requested URL returned error: 403

10 months

2
1
1 0

2025

2024

2023

2022

2021

2020

Hafnium