- TF-A - lists.trustedfirmware.org

TF-A Tech Forum on June 12th 2025 - TF-RMM live activation

by Olivier Deprez

Hi, On June 12th 2025, the TF-A Tech forum will take place at 4.00pm UK with the following topic: TF-RMM live activation design discussion Presenters: Andre Przywara Soby Mathew Manish Badarkhe In this meeting, we aim to discuss the details of live firmware activation for TF-RMM. The key topics will include: * Design details of TF-RMM live activation * Rationale for EL3-RMM communication changes: We will explain the motivation behind the proposed changes to the communication mechanism between EL3 and RMM which simplifies internal state migration for LFA, enables sharing of the state across RMM instances that are live-activated, supports localized per-CPU allocations for NUMA and multi-chip configurations, decouples the RMM binary from platform-specifics. * LFA SMC Implementation in EL3: We will also provide an overview of the LFA SMC implementation at EL3. Regards, Olivier. TF-A Tech Forum Thursday Jun 12, 2025 ⋅ 5pm – 6pm Central European Time - Paris Location https://linaro-org.zoom.us/j/93557863987?pwd=56a1l8cBnetDTZ6eazHGaE1Ctk4W34… https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9355786… Trusted Firmware is inviting you to a scheduled Zoom meeting.Topic: TF-A Tech ForumTime: May 15, 2025 02:00 PM London Every 2 weeks on Thu, 78 occurrence(s)Please download and import the following iCalendar (.ics) files to your calendar system.Weekly: https://linaro-org.zoom.us/meeting/tJcocu6gqDgjEtOkyBhSQauR1sUyFwIcNKLa/ics… Zoom Meetinghttps://linaro-org.zoom.us/j/93557863987?pwd=56a1l8cBnetDTZ6eazHGaE1Ctk4W34.1Meeting ID: 935 5786 3987Passcode: 939141---One tap mobile+12532158782,,93557863987# US (Tacoma)+13017158592,,93557863987# US (Washington DC)---Dial by your location• +1 253 215 8782 US (Tacoma)• +1 301 715 8592 US (Washington DC)• +1 305 224 1968 US• +1 309 205 3325 US• +1 312 626 6799 US (Chicago)• +1 346 248 7799 US (Houston)• +1 360 209 5623 US• +1 386 347 5053 US• +1 507 473 4847 US• +1 564 217 2000 US• +1 646 558 8656 US (New York)• +1 646 931 3860 US• +1 669 444 9171 US• +1 669 900 9128 US (San Jose)• +1 689 278 1000 US• +1 719 359 4580 US• +1 253 205 0468 US• 833 548 0276 US Toll-free• 833 548 0282 US Toll-free• 833 928 4608 US Toll-free• 833 928 4609 US Toll-free• 833 928 4610 US Toll-free• 877 853 5247 US Toll-free• 888 788 0099 US Toll-freeMeeting ID: 935 5786 3987Find your local number: https://linaro-org.zoom.us/u/adoz9mILli Guests tf-a(a)lists.trustedfirmware.org

2 days, 23 hours

1
0
0 0

FVP_Base_Cortex-A520 crash

by shaunak saha

Hi All, I'm new to TF-A. While working on enabling Linux on A-520 FVP, I ran into an issue that I wanted to ask about. My stack looks like this:TF-A->U-boot->kernel. Initially I was able to boot on Base FVP(FVP_Base_RevC-2xAEMvA) and get to the linux console. Now we need to enable the same for A-520 FVP as our soc will be A-520. I saw the crash happening very early in "cpu_helpers.S. I made the change in plat/arm/board/fvp/platform.mk by adding lib/cpus/aarch64/cortex_a520.S in one of the FVP_CPU_LIBS and enabling the ERRATA_A520_2938996, ERRATA_A520_2858100 and ERRATA_A520_2630792. These changes helped me get past the TF-A and now i ' m seeing a crash inside kernel in pci. 16.720973] pci-host-generic 40000000.pci: host bridge /pci@40000000 ranges: [ 16.721375] pci-host-generic 40000000.pci: MEM 0x0050000000..0x005fffffff -> 0x0050000000 [ 16.722013] pci-host-generic 40000000.pci: ECAM at [mem 0x40000000-0x4fffffff] for [bus 00-ff] [ 16.723128] pci-host-generic 40000000.pci: PCI host bridge to bus 0000:00 [ 16.723461] pci_bus 0000:00: root bus resource [bus 00-ff] [ 16.723761] pci_bus 0000:00: root bus resource [mem 0x50000000-0x5fffffff] [ 16.724101] Internal error: synchronous external abort: 0000000096000010 [#1] SMP [ 16.724216] Modules linked in: [ 16.724302] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.15.0-rc7-dirty #12 PREEMPT [ 16.724449] Hardware name: FVP Base RevC (DT) [ 16.724531] pstate: 214000c9 (nzCv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 16.724666] pc : pci_generic_config_read+0x38/0xb8 [ 16.724802] lr : pci_generic_config_read+0x24/0xb8 [ 16.724939] sp : ffff80008272b940 [ 16.725012] x29: ffff80008272b940 x28: 0000000000000000 x27: ffff800081dc00b0 [ 16.725205] x26: ffff800081ec9060 x25: ffff800081ec9078 x24: ffff80008266a9a0 [ 16.725401] x23: 0000000000000000 x22: ffff80008272b9f4 x21: ffff000800fa8000 [ 16.725594] x20: ffff80008272b964 x19: 0000000000000004 x18: 0000000000000006 [ 16.725781] x17: 6666666666663478 x16: 302d303030303030 x15: ffff800082edbbbf [ 16.725980] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 16.726166] x11: 0000000000000001 x10: 3ea1f6d484b7e318 x9 : 69631046f78aed23 [ 16.726355] x8 : ffff000800169108 x7 : ffff800082250960 x6 : 00000000000000ff [ 16.726547] x5 : 0000000000000000 x4 : 0000000000000000 x3 : ffff800090000000 [ 16.726738] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff800090000000 Do i need to do enable somethign else in TF-A? I tried adding : pci: pci@40000000 { compatible = "pci-host-ecam-generic"; device_type = "pci"; bus-range = <0x0 0xff>; reg = <0x0 0x40000000 0x0 0x10000000>; ranges = <0x2000000 0x0 0x50000000 0x0 0x50000000 0x0 0x10000000>; }; in plat/arm/board/fvp/fdts/fvp_soc_fw_config.dts but it does not help. Also I see the kernel is not able to bring all the cpu's online: [ 0.040364] smp: Bringing up secondary CPUs ... [ 5.116993] CPU1: failed to come online [ 5.117063] CPU1: failed in unknown state : 0x0 [ 10.266076] CPU2: failed to come online [ 10.266152] CPU2: failed in unknown state : 0x0 [ 15.415178] CPU3: failed to come online [ 15.415247] CPU3: failed in unknown state : 0x0 [ 15.421021] psci: failed to boot CPU4 (-22) [ 15.421099] CPU4: failed to boot: -22 [ 15.425045] psci: failed to boot CPU5 (-22) [ 15.425123] CPU5: failed to boot: -22 [ 15.429079] psci: failed to boot CPU6 (-22) [ 15.429157] CPU6: failed to boot: -22 [ 15.433153] psci: failed to boot CPU7 (-22) [ 15.433227] CPU7: failed to boot: -22 [ 15.433587] smp: Brought up 1 node, 1 CPU [ 15.433672] SMP: Total of 1 processors activated. [ 15.433746] CPU: All CPU(s) started at EL2 I’m still getting familiar with the codebase and community, so apologies if this has already been addressed. I’d really appreciate any guidance or pointers, and if this is a known issue or good for a first-time contributor, I’d be happy to help. Regards, Shaunak

1 week, 2 days

2
2
0 0

Trusted Firmware-A LTS v2.8.33 Release Announcement

by svc_openci_enginfra＠arm.com

Hello, Trusted Firmware-A LTS version 2.8.33 is now available. This release contains the following patches: a95dba188 build(npm): adhere to Husky deprecation notice [1] fc3a26e5f fix(deps): remove deprecated husky commands [2] a96d034d0 fix(cpus): drop esb from the Neoverse N1 [3] 3bd1d85f1 chore(docs): add a SBOM template in CycloneDX format [4] [1] https://review.trustedfirmware.org/q/I18ea1bbaedbb4213cc04c21413d75c9757ff7… [2] https://review.trustedfirmware.org/q/I8b7fa82aa7b5e178554a1b4a650b2b1b80440… [3] https://review.trustedfirmware.org/q/I5775180ec61373cc5d1b9831e3fa0f2fbb19e… [4] https://review.trustedfirmware.org/q/Ia34338854a0eaa4f3a8799c23e46aae382792… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.8.33/change-log.html Thanks, TF-A LTS team

1 week, 3 days

1
0
0 0

Planned Jenkins migration - Friday 30 May 2025, 14:30-18:30 BST

by Chris Kay

Hi folks, We are planning on going live with the migration of the TF.org Open CI tomorrow, Friday 30th May, which will migrate Jenkins (ci.trustedfirmware.org) from on-premises to cloud-managed infrastructure. We expect a downtime of 2-4 hours beginning at 14:30 GMT+1, during which anything which interacts with Jenkins will be unavailable. Please note that the Jenkins build history is not being transferred - if you have Gerrit changes in review with the Allow-CI+1/+2 label, you will need to retrigger the CI once migration is complete by reapplying the label. We will send out a follow-up email once we have restored service availability. Regards, Chris

1 week, 6 days

1
1
0 0

Canceled event with note: TF-A Tech Forum @ Thu May 29, 2025 5pm - 6pm (GMT+2) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

This event has been canceled with a note: "Hi, Cancelling as no topic planned for this week. Regards, Olivier. " TF-A Tech Forum Thursday May 29, 2025 ⋅ 5pm – 6pm Central European Time - Paris Location https://linaro-org.zoom.us/j/93557863987?pwd=56a1l8cBnetDTZ6eazHGaE1Ctk4W34… https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9355786… Trusted Firmware is inviting you to a scheduled Zoom meeting.Topic: TF-A Tech ForumTime: May 15, 2025 02:00 PM London Every 2 weeks on Thu, 78 occurrence(s)Please download and import the following iCalendar (.ics) files to your calendar system.Weekly: https://linaro-org.zoom.us/meeting/tJcocu6gqDgjEtOkyBhSQauR1sUyFwIcNKLa/ics… Zoom Meetinghttps://linaro-org.zoom.us/j/93557863987?pwd=56a1l8cBnetDTZ6eazHGaE1Ctk4W34.1Meeting ID: 935 5786 3987Passcode: 939141---One tap mobile+12532158782,,93557863987# US (Tacoma)+13017158592,,93557863987# US (Washington DC)---Dial by your location• +1 253 215 8782 US (Tacoma)• +1 301 715 8592 US (Washington DC)• +1 305 224 1968 US• +1 309 205 3325 US• +1 312 626 6799 US (Chicago)• +1 346 248 7799 US (Houston)• +1 360 209 5623 US• +1 386 347 5053 US• +1 507 473 4847 US• +1 564 217 2000 US• +1 646 558 8656 US (New York)• +1 646 931 3860 US• +1 669 444 9171 US• +1 669 900 9128 US (San Jose)• +1 689 278 1000 US• +1 719 359 4580 US• +1 253 205 0468 US• 833 548 0276 US Toll-free• 833 548 0282 US Toll-free• 833 928 4608 US Toll-free• 833 928 4609 US Toll-free• 833 928 4610 US Toll-free• 877 853 5247 US Toll-free• 888 788 0099 US Toll-freeMeeting ID: 935 5786 3987Find your local number: https://linaro-org.zoom.us/u/adoz9mILli Guests tf-a(a)lists.trustedfirmware.org ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the 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

2 weeks, 1 day

1
0
0 0

Trusted Firmware-A LTS v2.12.3 Release Announcement

by ci_notify＠trustedfirmware.org

Hello, Trusted Firmware-A LTS version 2.12.3 is now available. This release contains the following patches: 70ed22957 fix(deps): remove deprecated husky commands [1] 1967879b3 chore(cpus): remove in-order checks [2] 5d8f821c5 refactor(cpus): drop unused argument forward_flag [3] 1ca07cd72 refactor(cpus): move errata check to common code [4] 481e161eb refactor(cpus): optimize CVE checking [5] fdd706702 fix(cpus): drop esb from the Neoverse N1 [6] 88da40bcb chore(docs): add a SBOM template in CycloneDX format [7] 1cd56abd8 docs(prerequisites): update mbedtls to v3.6.3 [8] cb3aea9ca feat(mbedtls): update mbedtls to version 3.6.3 [9] [1] https://review.trustedfirmware.org/q/I8b7fa82aa7b5e178554a1b4a650b2b1b80440… [2] https://review.trustedfirmware.org/q/Iee5a8cb49834e9f35c6c2f2a84065430ca1ec… [3] https://review.trustedfirmware.org/q/Ib1fcbe081e94657e21d983e0db59ceec9993b… [4] https://review.trustedfirmware.org/q/I2c6d4468f7125d4d99ccdebc5ea8f9e439036… [5] https://review.trustedfirmware.org/q/I873534e367a35c99461d0a616ff7bf856a000… [6] https://review.trustedfirmware.org/q/I5775180ec61373cc5d1b9831e3fa0f2fbb19e… [7] https://review.trustedfirmware.org/q/Ia34338854a0eaa4f3a8799c23e46aae382792… [8] https://review.trustedfirmware.org/q/I62bc0fd6e40a38143ad3118a2e8e8d63c728a… [9] https://review.trustedfirmware.org/q/Icad24203a36cb7e5b0a6f2275cb3b5346dcd1… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.12.3/change-log.html Thanks, TF-A LTS team

3 weeks

1
0
0 0

Trusted Firmware-A LTS v2.10.17 Release Announcement

by ci_notify＠trustedfirmware.org

Hello, Trusted Firmware-A LTS version 2.10.17 is now available. This release contains the following patches: 93982eb31 build(npm): adhere to Husky deprecation notice [1] 2f7327030 fix(cpus): drop esb from the Neoverse N1 [2] b42c3c05c chore(docs): add a SBOM template in CycloneDX format [3] [1] https://review.trustedfirmware.org/q/I18ea1bbaedbb4213cc04c21413d75c9757ff7… [2] https://review.trustedfirmware.org/q/I5775180ec61373cc5d1b9831e3fa0f2fbb19e… [3] https://review.trustedfirmware.org/q/Ia34338854a0eaa4f3a8799c23e46aae382792… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.10.17/change-log.html Thanks, TF-A LTS team

3 weeks

1
0
0 0

Trusted Firmware-A LTS v2.8.32 Release Announcement

by ci_notify＠trustedfirmware.org

3 weeks

1
0
0 0

Trusted Firmware v2.13 release announcement

by Olivier Deprez

Hi All, We are pleased to announce the formal release of Trusted Firmware-A version 2.13 bundle of project deliverables. This includes Trusted Firmware-A, Trusted Firmware-A Tests, Hafnium, TF-RMM, Trusted Services, and TF-A OpenCI scripts/jobs components. These went live on May, 22nd 2025. 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.13 are as follows: TF-A/EL3 * Alto CPU support * Architecture feature support for PMUv3p9. PAUTH_LR and SPE_FDS. * Refactor PSCI to let each CPU core initialise its own context, allowing TF-A to natively handle asymmetric configurations * PSCI Powerdown abandon feature support * SMCCC_FEATURE_AVAILABILITY support based on SMCCC v1.5 specification * Firmware Handoff * Library enhancements to add more TE types in library * All BL interfaces for FVP are now migrated to use Transfer List along in different boot scenarios (RESET_TO_BL1/BL2/BL31) * TC platform is now using Transfer List for booting * HOB creation Library (from edk2) is now hosted in TF-A * New Platforms: mt8189, mt8196, qcs615, RK3576, AM62L Boot flow * Feature Additions * Added discrete TPM support in BL1/BL2 for the RPi3 platform. * Support for MbedTLS PSA Crypto with ROMLIB on FVP. * Redesigned PSA Crypto Key ID management to avoid repeated key creation/destruction. * Test Additions * Support for MbedTLS PSA Crypto with ROMLIB on FVP. * Added basic boot test for TF-RMM with TF-A and TFTF (Realm Payload) in Jenkins CI. * Integrated DRTM ACS test suite into TF-A Jenkins CI. * Added missing test configuration for ROTPK in register on FVP platform. * Build System * Refactored ROTPK key/hash generation to auto-generate required files during build. * mbedTLS Improvements * Migrated to mbedTLS version 3.6.3. Errata/Security mitigations (CPU/GIC) * CVE-2024-5660, CVE-2024-7881 * Cortex-A510, Cortex-A715, Cortex-X4, Cortex-X925, Neoverse V3 Hafnium/SPM (S-EL2) * FF-A v1.2 completed: indirect messaging with service UUIDs. * FF-A v1.3 early adoption: Update to FFA_MEM_PERM_GET ABIs. * StMM integration: provide HOB structure as boot information. * Power management update: * Bootstrapped secondary vCPUs on secondary cores power on flows. * SP's subscription to the power off event. * SP loading: SP artefacts can be bundled in a TL format. I.e SP binary and SP manifest (DTB). * Resuming ECs for interrupt handling assisted by NWd Scheduler when the SP is in waiting state, with sri-interrupts-policy field in the SP manifest. TF-RMM (R-EL2) * Deprivileging RMM code via EL0 App support * Added some support for some RMMv1.1 APIs - "RMI_DEV_MEM_(UN)MAP", support for device granules in "RMI_GRANULE_DELEGATE" and "RMI_GRANULE_UNDELEGATE". * Additional hardening of RMM via compiler flags `-fstack-protector-strong`, '-Wextra', '-Wstrict-overflow', '-D_FORTIFY_SOURCE=2' and '-Wnull-dereference'. * New platform support for RD-V3-R1 and RD-V3-R1-Cfg1 FVPs. * Dynamic discovery of PCIE Root complex topology and device memory from the Boot manifest. Trusted Services (v1.2.0) * Introduced the fTPM SP. The implementation is experimental. * Introduce the new Arm Reference Design-1 AE platform targeting the Automotive segment. It features high-performance Arm Neoverse V3AE Application Processor compute system, Arm Cortex-R82AE based Safety Island, and a Runtime Security Engine (RSE) for enhanced security. * Updated the se-proxy deployment and added support for the Firmware Update Proxy service. The FWU Proxy implements a Platform Security Firmware Update for the A-profile Arm Architecture<https://developer.arm.com/documentation/den0118/latest/> compliant FWU Agent which runs a PSA Certified Firmware Update API 1.0<https://arm-software.github.io/psa-api/fwu/1.0/> compliant client as its backend. TF-A Tests * Enhancements to fuzzing tests (EL3 vendor specific SMC, SDEI, FF-A interface, capability for randomized fuzzing inputs) * Functionality test * Firmware Handoff : AArch32 tests and event log testing * SMCCC_ARCH_FEATURE_AVAILABILITY * RAS system registers, FPMR, SCTLR2, THE and D128 * validate psci_is_last_cpu_to_idle_at_pwrlvl * SPM/FF-A : HOB generation, PPI timer interrupts, v1.2 RXTX headers * RMM: Tests introduced for majority of features developed in RMM * Platform Support * Versal NET * Versal * Neoverse-RD 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.git/+/refs/… 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.13.0/change-log.html#id1 https://trustedfirmware-a-tests.readthedocs.io/en/v2.13.0/change-log.html#v… https://hafnium.readthedocs.io/en/v2.13.0/change-log.html#v2-13 https://tf-rmm.readthedocs.io/en/latest/about/change-log.html#v0-7-0 https://trusted-services.readthedocs.io/en/stable/project/change-log.html#v… Regards, Olivier.

3 weeks

1
0
0 0

Canceled event with note: TF-A Tech Forum @ Thu May 15, 2025 5pm - 6pm (GMT+2) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

This event has been canceled with a note: "Hi, No topic proposed so cancelling this week. Regards, Olivier. " TF-A Tech Forum Thursday May 15, 2025 ⋅ 5pm – 6pm Central European Time - Paris Location https://linaro-org.zoom.us/j/93557863987?pwd=56a1l8cBnetDTZ6eazHGaE1Ctk4W34… https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9355786… Trusted Firmware is inviting you to a scheduled Zoom meeting.Topic: TF-A Tech ForumTime: May 15, 2025 02:00 PM London Every 2 weeks on Thu, 78 occurrence(s)Please download and import the following iCalendar (.ics) files to your calendar system.Weekly: https://linaro-org.zoom.us/meeting/tJcocu6gqDgjEtOkyBhSQauR1sUyFwIcNKLa/ics… Zoom Meetinghttps://linaro-org.zoom.us/j/93557863987?pwd=56a1l8cBnetDTZ6eazHGaE1Ctk4W34.1Meeting ID: 935 5786 3987Passcode: 939141---One tap mobile+12532158782,,93557863987# US (Tacoma)+13017158592,,93557863987# US (Washington DC)---Dial by your location• +1 253 215 8782 US (Tacoma)• +1 301 715 8592 US (Washington DC)• +1 305 224 1968 US• +1 309 205 3325 US• +1 312 626 6799 US (Chicago)• +1 346 248 7799 US (Houston)• +1 360 209 5623 US• +1 386 347 5053 US• +1 507 473 4847 US• +1 564 217 2000 US• +1 646 558 8656 US (New York)• +1 646 931 3860 US• +1 669 444 9171 US• +1 669 900 9128 US (San Jose)• +1 689 278 1000 US• +1 719 359 4580 US• +1 253 205 0468 US• 833 548 0276 US Toll-free• 833 548 0282 US Toll-free• 833 928 4608 US Toll-free• 833 928 4609 US Toll-free• 833 928 4610 US Toll-free• 877 853 5247 US Toll-free• 888 788 0099 US Toll-freeMeeting ID: 935 5786 3987Find your local number: https://linaro-org.zoom.us/u/adoz9mILli Guests tf-a(a)lists.trustedfirmware.org ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the 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

4 weeks, 1 day

1
0
0 0

Re: Question about memory mapping attributes for MT_DEVICE

by Olivier Deprez

The email was moderated, re-sending on behalf of Andrei. ________________________________ From: Andrei Stefanescu <andrei.stefanescu(a)nxp.com> Sent: 13 May 2025 12:35 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Cc: Ghennadi Procopciuc <ghennadi.procopciuc(a)nxp.com>; Ciprian Marian Costea <ciprianmarian.costea(a)nxp.com>; Alexandru-Catalin Ionita <alexandru-catalin.ionita(a)nxp.com> Subject: Question about memory mapping attributes for MT_DEVICE Hi, I noticed that the memory mapping attributes for MT_DEVICE memory are defined to: nGnRE [1]. Why was nGnRE selected instead of nGnRnE? Platforms which have USE_COHERENT_MEM set to 1 will map the coherent memory area as MT_DEVICE. This area is helpful for cases where a backery lock is shared between cores which have MMU enabled and cores which don’t (whose access is equivalent to nGnRnE). This would generate an access attributes mismatch for the coherent memory area. Would it be ok to send a patch which changes the ATTR_DEVICE to nGnRnE? Best regards, Andrei Stefanescu [1] - https://git.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a.git…

1 month

3
6
0 0

Changelog for v2.13 Release

by Govindraj Raja

Hello Everyone, Ahead of the TF-A v2.13 release, please review the autogenerated changelog for your platform. It’s built from the commit messages of all patches merged since v2.12. If you spot anything that needs a quick manual tweak, just let us know. Patch: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/38170 Rendered Version: https://ci-builds.trustedfirmware.org/static-files/Jr7PSOAIj0pMAfjvJ-b7Y7G7… -- Thanks, Govindraj R

1 month

1
0
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.

1 month

1
1
0 0

Trusted Firmware-A LTS v2.10.16 Release Announcement

by ci_notify＠trustedfirmware.org

Hello, Trusted Firmware-A LTS version 2.10.16 is now available. This release contains the following patches: 3b9e21608 chore(cpus): remove in-order checks [1] d7483aa8f fix(cpus): add missing add_erratum_entry [2] ab526df97 refactor(cpus): drop unused argument forward_flag [3] a86f15fb2 refactor(cpus): move errata check to common code [4] 5a1a6929f refactor(cpus): optimize CVE checking [5] [1] https://review.trustedfirmware.org/q/Iee5a8cb49834e9f35c6c2f2a84065430ca1ec… [2] https://review.trustedfirmware.org/q/I19a484c73ac31a90b3ff1b219f647c88a1c81… [3] https://review.trustedfirmware.org/q/Ib1fcbe081e94657e21d983e0db59ceec9993b… [4] https://review.trustedfirmware.org/q/I2c6d4468f7125d4d99ccdebc5ea8f9e439036… [5] https://review.trustedfirmware.org/q/I873534e367a35c99461d0a616ff7bf856a000… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.10.16/change-log.html Thanks, TF-A LTS team

1 month, 1 week

1
0
0 0

Trusted Firmware-A LTS v2.8.31 Release Announcement

by ci_notify＠trustedfirmware.org

Hello, Trusted Firmware-A LTS version 2.8.31 is now available. This release contains the following patches: 30d688676 fix(cpus): workaround for Cortex-X4 erratum 2957258 [1] b4dd8f62f fix(cpus): workaround for Neoverse-V3 erratum 2970647 [2] 34614e084 fix(cpus): fix a typo in errata doc [3] fa4bdbb57 fix(cpus): declare reset errata correctly [4] 9ec650fc7 refactor(cpus): convert the Cortex-A65 to use the errata framework [5] 88ca67b78 refactor(cpus): convert checker functions to standard helpers [6] f67c3ea96 perf(cpus): inline cpu_rev_var checks [7] 6a6b0bed3 refactor(cpus): directly invoke errata reporter [8] d54e07a25 refactor(cpus): remove cpu specific errata funcs [9] d1ea85820 refactor(cpus): declare runtime errata correctly [10] 7bf485d93 refactor(cpus): register DSU errata with the errata framework's wrappers [11] [1] https://review.trustedfirmware.org/q/I2d8e7f4ce19ca2e1d87527c31e7778d81aff0… [2] https://review.trustedfirmware.org/q/Iedf7d799451f0be58a5da1f93f7f5b6940f2b… [3] https://review.trustedfirmware.org/q/I2332a3fcaf56a7aaab5a04e3d40428cc746d2… [4] https://review.trustedfirmware.org/q/I22c3043ab454ce94b3c122c856e5804bc2ebb… [5] https://review.trustedfirmware.org/q/I91cd6111ccf95d6b7ee2364ac2126cb98ee4b… [6] https://review.trustedfirmware.org/q/Ic1dff2bc5235195f7cfce1709cd42467f88b3… [7] https://review.trustedfirmware.org/q/I51608352f23b2244ea7a99e76c10892d257f1… [8] https://review.trustedfirmware.org/q/Ie4a4fd60429aca37cf434e79c0ce2992a5ff5… [9] https://review.trustedfirmware.org/q/I04fefbde5f0ff63b1f1cd17c864557a14070d… [10] https://review.trustedfirmware.org/q/I316daeee603e86c9f2bdccf91e1b10f7ec6c3… [11] https://review.trustedfirmware.org/q/Iefa36325804ea093e938f867b9a6f49a6984b… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.8.31/change-log.html Thanks, TF-A LTS team

1 month, 1 week

1
0
0 0

Invitation: TF-A Tech Forum @ Every 2 weeks from 4pm to 5pm on Thursday (BST) (tf-a@lists.trustedfirmware.org)

by Shaun Longhorn

TF-A Tech Forum Every 2 weeks from 4pm to 5pm on Thursday United Kingdom Time Location https://linaro-org.zoom.us/j/93557863987?pwd=56a1l8cBnetDTZ6eazHGaE1Ctk4W34… https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9355786… Trusted Firmware is inviting you to a scheduled Zoom meeting.Topic: TF-A Tech ForumTime: May 15, 2025 02:00 PM London Every 2 weeks on Thu, 78 occurrence(s)Please download and import the following iCalendar (.ics) files to your calendar system.Weekly: https://linaro-org.zoom.us/meeting/tJcocu6gqDgjEtOkyBhSQauR1sUyFwIcNKLa/ics… Zoom Meetinghttps://linaro-org.zoom.us/j/93557863987?pwd=56a1l8cBnetDTZ6eazHGaE1Ctk4W34.1Meeting ID: 935 5786 3987Passcode: 939141---One tap mobile+12532158782,,93557863987# US (Tacoma)+13017158592,,93557863987# US (Washington DC)---Dial by your location• +1 253 215 8782 US (Tacoma)• +1 301 715 8592 US (Washington DC)• +1 305 224 1968 US• +1 309 205 3325 US• +1 312 626 6799 US (Chicago)• +1 346 248 7799 US (Houston)• +1 360 209 5623 US• +1 386 347 5053 US• +1 507 473 4847 US• +1 564 217 2000 US• +1 646 558 8656 US (New York)• +1 646 931 3860 US• +1 669 444 9171 US• +1 669 900 9128 US (San Jose)• +1 689 278 1000 US• +1 719 359 4580 US• +1 253 205 0468 US• 833 548 0276 US Toll-free• 833 548 0282 US Toll-free• 833 928 4608 US Toll-free• 833 928 4609 US Toll-free• 833 928 4610 US Toll-free• 877 853 5247 US Toll-free• 888 788 0099 US Toll-freeMeeting ID: 935 5786 3987Find your local number: https://linaro-org.zoom.us/u/adoz9mILli Guests tf-a(a)lists.trustedfirmware.org View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=NnR0NGMyZWJkdnBn… Reply for tf-a(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=NnR0NGMyZWJkdnBn… 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. 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

1 month, 1 week

1
0
0 0

TF-A Tech forum on May 1st - cancelled

by Olivier Deprez

Hi, For some reason the invite disappeared from the shared trustedfirmware.org calendar but this message is to state there is no TF-A tech forum planned tomorrow May 1st due to lack of topics. Thanks & Regards, Olivier.

1 month, 1 week

1
0
0 0

Trusted Firmware-A LTS v2.12.2 Release Announcement

by ci_notify＠trustedfirmware.org

1 month, 2 weeks

1
0
0 0

Adding new platform support for ADI's ADSP-SC598

by Agarwal, Utsav

Hi All, We currently have TF-A/OP-TEE support for a platform (ADSP-SC598, arm cortex A55) in our forked repositories and would like to upstream our past efforts to align better with newer developments within the projects. As per the contributor's guide for TF-A, it mentions that it might be a good idea to start a discussion regarding the same prior to submission of a patch series. Currently, the plan is for the initial patch series to support BL31 followed by another patch series adding support for PSCI. The overarching idea being that BOOTROM passes control to u-boot SPL, which configures required peripherals and loads us into TF-A, then proceeding to load OP-TEE, followed by full uboot/linux. Please let me know your thoughts/concerns and if I should be proceeding with the patch series submission. Regards, Utsav Agarwal

1 month, 2 weeks

2
2
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

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 463142: Memory - illegal accesses (INTEGER_OVERFLOW) /services/std_svc/sdei/sdei_event.c: 79 in get_event_entry_target_pe() ________________________________________________________________________________________________________ *** CID 463142: Memory - illegal accesses (INTEGER_OVERFLOW) /services/std_svc/sdei/sdei_event.c: 79 in get_event_entry_target_pe() 73 */ 74 idx = mapsub; 75 76 /* Base of private mappings for this CPU */ 77 base_idx = (unsigned int) plat_core_pos_by_mpidr(target_pe); 78 base_idx *= nm; >>> CID 463142: Memory - illegal accesses (INTEGER_OVERFLOW) >>> "base_idx", which might have underflowed, is passed to "sdei_private_event_table[base_idx]". 79 cpu_priv_base = &sdei_private_event_table[base_idx]; 80 /* 81 * Return the address of the entry at the same index in the 82 * per-CPU event entry. 83 */ 84 return &cpu_priv_base[idx]; ** CID 463141: Memory - illegal accesses (NEGATIVE_RETURNS) /services/std_svc/sdei/sdei_intr_mgmt.c: 64 in sdei_is_target_pe_masked() ________________________________________________________________________________________________________ *** CID 463141: Memory - illegal accesses (NEGATIVE_RETURNS) /services/std_svc/sdei/sdei_intr_mgmt.c: 64 in sdei_is_target_pe_masked() 58 59 /* SDEI states for all cores in the system */ 60 static sdei_cpu_state_t cpu_state[PLATFORM_CORE_COUNT]; 61 62 bool sdei_is_target_pe_masked(uint64_t target_pe) 63 { >>> CID 463141: Memory - illegal accesses (NEGATIVE_RETURNS) >>> Using variable "plat_core_pos_by_mpidr(target_pe)" as an index to array "cpu_state". 64 const sdei_cpu_state_t *state = sdei_get_target_pe_state(target_pe); 65 66 return state->pe_masked; 67 } 68 69 int64_t sdei_pe_mask(void) ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://scan.coverity.com/projects/arm-software-arm-trusted-firmware?tab=ov…

1 month, 2 weeks

1
0
0 0

Looking for Gerrit admin for my account issue

by Yu-Ping Wu

I need Gerrit admin's help to delete my old Gerrit account. Who should I contact? -- Yu-Ping Wu | Software Engineer | yupingso(a)google.com | +886 937 057 080

1 month, 3 weeks

2
1
0 0

Trusted Firmware-A LTS v2.10.15 Release Announcement

by ci_notify＠trustedfirmware.org

1 month, 3 weeks

1
0
0 0

trustedfirmware git and gerrit slowness

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 month, 3 weeks

1
0
0 0

Canceled event: TF-A Tech Forum @ Thu Apr 17, 2025 5pm - 6pm (GMT+2) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

This event has been canceled. TF-A Tech Forum Thursday Apr 17, 2025 ⋅ 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 ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the 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

1 month, 3 weeks

1
0
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

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 461861: Code maintainability issues (UNUSED_VALUE) /plat/ti/k3low/common/am62l_psci.c: 35 in am62l_pwr_domain_on() ________________________________________________________________________________________________________ *** CID 461861: Code maintainability issues (UNUSED_VALUE) /plat/ti/k3low/common/am62l_psci.c: 35 in am62l_pwr_domain_on() 29 int32_t core, ret; 30 uint8_t proc_id; 31 32 core = plat_core_pos_by_mpidr(mpidr); 33 if (core < 0) { 34 ERROR("Could not get target core id: %d\n", core); >>> CID 461861: Code maintainability issues (UNUSED_VALUE) >>> Assigning value "-6" to "ret" here, but that stored value is overwritten before it can be used. 35 ret = PSCI_E_INTERN_FAIL; 36 } 37 38 proc_id = (uint8_t)(PLAT_PROC_START_ID + (uint32_t)core); 39 40 ret = ti_sci_proc_request(proc_id); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://scan.coverity.com/projects/arm-software-arm-trusted-firmware?tab=ov…

2 months

2
1
0 0

Canceled event: TF-A Tech Forum @ Thu Apr 3, 2025 5pm - 6pm (GMT+2) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

This event has been canceled. TF-A Tech Forum Thursday Apr 3, 2025 ⋅ 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 ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the 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

2 months, 1 week

1
0
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

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 458349: Integer handling issues (INCOMPATIBLE_CAST) ________________________________________________________________________________________________________ *** CID 458349: Integer handling issues (INCOMPATIBLE_CAST) /plat/intel/soc/common/socfpga_sip_svc.c: 2190 in sip_smc_handler_v1() 2184 SMC_RET1(handle, status); 2185 } else { 2186 SMC_RET3(handle, seu_respbuf[0], seu_respbuf[1], seu_respbuf[2]); 2187 } 2188 2189 case INTEL_SIP_SMC_SAFE_INJECT_SEU_ERR: >>> CID 458349: Integer handling issues (INCOMPATIBLE_CAST) >>> Pointer "&x1" points to an object whose effective type is "unsigned long" (64 bits, unsigned) but is dereferenced as a narrower "unsigned int" (32 bits, unsigned). This may lead to unexpected results depending on machine endianness. 2190 status = intel_sdm_safe_inject_seu_err((uint32_t *)&x1, (uint32_t)x2); 2191 SMC_RET1(handle, status); 2192 2193 case INTEL_SIP_SMC_ATF_BUILD_VER: 2194 SMC_RET4(handle, INTEL_SIP_SMC_STATUS_OK, VERSION_MAJOR, 2195 VERSION_MINOR, VERSION_PATCH); ** CID 458348: Integer handling issues (INCOMPATIBLE_CAST) ________________________________________________________________________________________________________ *** CID 458348: Integer handling issues (INCOMPATIBLE_CAST) /plat/intel/soc/common/socfpga_sip_svc.c: 1250 in sip_smc_handler_v3() 1244 0); 1245 SMC_RET1(handle, status); 1246 } 1247 1248 case ALTERA_SIP_SMC_ASYNC_FCS_GET_ATTESTATION_CERT: 1249 { >>> CID 458348: Integer handling issues (INCOMPATIBLE_CAST) >>> Pointer "&x4" points to an object whose effective type is "unsigned long" (64 bits, unsigned) but is dereferenced as a narrower "unsigned int" (32 bits, unsigned). This may lead to unexpected results depending on machine endianness. 1250 status = intel_fcs_get_attestation_cert(smc_fid, x1, x2, x3, 1251 (uint32_t *) &x4, &mbox_error); 1252 SMC_RET1(handle, status); 1253 } 1254 1255 case ALTERA_SIP_SMC_ASYNC_FCS_CREATE_CERT_ON_RELOAD: ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://scan.coverity.com/projects/arm-software-arm-trusted-firmware?tab=ov…

2 months, 1 week

1
0
0 0

Removal of erratum titled “Disabling of data prefetcher with outstanding prefetch TLB miss might cause a deadlock”.

by Govindraj Raja

Hi All, If you're downstream platform maintainer or maintainer for mtk or qti platforms for TF-A, I want to bring to your attention about this patch in review - https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/36700 This patch removes erratum titled “Disabling of data prefetcher with outstanding prefetch TLB miss might cause a deadlock” this should not be handled within TF-A. The static setting of PF_MODE in TF-A does not correctly address the erratum and may introduce unnecessary performance degradation on platforms that adopt it without fully understanding its implications. -- Thanks, Govindraj R

2 months, 2 weeks

1
0
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 49 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 13 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 20 of 49 defect(s) ** CID 457912: Concurrent data access violations (MISSING_LOCK) /services/std_svc/sdei/sdei_event.c: 117 in sdei_get_registered_event_count() ________________________________________________________________________________________________________ *** CID 457912: Concurrent data access violations (MISSING_LOCK) /services/std_svc/sdei/sdei_event.c: 117 in sdei_get_registered_event_count() 111 unsigned int j; 112 int count = 0; 113 114 /* Add up reg counts for each mapping. */ 115 for_each_mapping_type(i, mapping) { 116 iterate_mapping(mapping, j, map) { >>> CID 457912: Concurrent data access violations (MISSING_LOCK) >>> Accessing "map->reg_count" without holding lock "sdei_ev_map.lock". Elsewhere, "sdei_ev_map.reg_count" is written to with "sdei_ev_map.lock" held 2 out of 3 times. 117 count += map->reg_count; 118 } 119 } 120 121 return count; ** CID 457911: Null pointer dereferences (REVERSE_INULL) /plat/mediatek/drivers/cpu_pm/cpcv5_4/mt_cpu_pm.c: 801 in cpupm_invoke() ________________________________________________________________________________________________________ *** CID 457911: Null pointer dereferences (REVERSE_INULL) /plat/mediatek/drivers/cpu_pm/cpcv5_4/mt_cpu_pm.c: 801 in cpupm_invoke() 795 ret = MTK_CPUPM_E_ERR; 796 break; 797 #endif /* CPU_PM_SUSPEND_NOTIFY */ 798 799 #ifdef CPU_PM_PWR_REQ 800 case CPUPM_INVOKE_PWR_REQ_ACTIVE: >>> CID 457911: Null pointer dereferences (REVERSE_INULL) >>> Null-checking "priv" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. 801 if (priv) { 802 if (req->stat.uid == CPUPM_PWR_REQ_UID_MAGIC) 803 req->stat.uid = CPUPM_PWR_STAT_REQ_UID_MAGIC; 804 else 805 ret = MTK_CPUPM_E_ERR; 806 } else ** CID 457910: Integer handling issues (INTEGER_OVERFLOW) /lib/libc/strtoll.c: 128 in strtoll() ________________________________________________________________________________________________________ *** CID 457910: Integer handling issues (INTEGER_OVERFLOW) /lib/libc/strtoll.c: 128 in strtoll() 122 any = 1; 123 acc *= base; 124 acc += c; 125 } 126 } 127 if (any < 0) { >>> CID 457910: Integer handling issues (INTEGER_OVERFLOW) >>> Expression "acc", where "neg ? -9223372036854775808LL : 9223372036854775807LL" is known to be equal to -9223372036854775808, underflows the type of "acc", which is type "unsigned long long". 128 acc = neg ? LLONG_MIN : LLONG_MAX; 129 } else if (neg) 130 acc = -acc; 131 if (endptr != NULL) 132 *endptr = (char *)(any ? s - 1 : nptr); 133 return (acc); ** CID 457909: (INTEGER_OVERFLOW) /drivers/nxp/ddr/nxp-ddr/regs.c: 159 in cal_timing_cfg() /drivers/nxp/ddr/nxp-ddr/regs.c: 128 in cal_timing_cfg() ________________________________________________________________________________________________________ *** CID 457909: (INTEGER_OVERFLOW) /drivers/nxp/ddr/nxp-ddr/regs.c: 159 in cal_timing_cfg() 153 const unsigned int ext_acttopre = picos_to_mclk(clk, 154 pdimm->tras_ps) >> 4U; 155 const unsigned int ext_acttorw = picos_to_mclk(clk, 156 pdimm->trcd_ps) >> 4U; 157 const unsigned int ext_caslat = (2U * cas_latency - 1U) >> 4U; 158 const unsigned int ext_add_lat = additive_latency >> 4U; >>> CID 457909: (INTEGER_OVERFLOW) >>> Expression "picos_to_mclk(clk, pdimm->trfc1_ps) - 8U", where "picos_to_mclk(clk, pdimm->trfc1_ps)" is known to be equal to 0, underflows the type of "picos_to_mclk(clk, pdimm->trfc1_ps) - 8U", which is type "unsigned int". 159 const unsigned int ext_refrec = (picos_to_mclk(clk, 160 pdimm->trfc1_ps) - 8U) >> 4U; 161 const unsigned int ext_wrrec = (picos_to_mclk(clk, pdimm->twr_ps) + 162 (popts->otf_burst_chop_en ? 2U : 0U)) >> 4U; 163 const unsigned int rwt_same_cs = 0U; 164 const unsigned int wrt_same_cs = 0U; /drivers/nxp/ddr/nxp-ddr/regs.c: 128 in cal_timing_cfg() 122 const int acttorw_mclk = picos_to_mclk(clk, pdimm->trcd_ps); 123 const int caslat_ctrl = (cas_latency - 1) << 1; 124 const int trfc1_min = pdimm->die_density >= 0x3 ? 16000 : 125 (pdimm->die_density == 0x4 ? 26000 : 126 (pdimm->die_density == 0x5 ? 35000 : 127 55000)); >>> CID 457909: (INTEGER_OVERFLOW) >>> Expression "refrec_ctrl", where "picos_to_mclk(clk, pdimm->trfc1_ps) - 8U" is known to be equal to 4294967288, overflows the type of "refrec_ctrl", which is type "int const". 128 const int refrec_ctrl = picos_to_mclk(clk, 129 pdimm->trfc1_ps) - 8; 130 int wrrec_mclk = picos_to_mclk(clk, pdimm->twr_ps); 131 const int acttoact_mclk = max(picos_to_mclk(clk, 132 pdimm->trrds_ps), 133 4U); ** CID 457908: (INTEGER_OVERFLOW) /drivers/marvell/amb_adec.c: 70 in amb_check_win() /drivers/marvell/amb_adec.c: 60 in amb_check_win() ________________________________________________________________________________________________________ *** CID 457908: (INTEGER_OVERFLOW) /drivers/marvell/amb_adec.c: 70 in amb_check_win() 64 } 65 66 /* size parameter validity check */ 67 if (!IS_POWER_OF_2(win->win_size)) { 68 WARN("Window %d: window size is not power of 2 (0x%" PRIx64 ")\n", 69 win_num, win->win_size); >>> CID 457908: (INTEGER_OVERFLOW) >>> Expression "win->win_size - 1UL", where "win->win_size" is known to be equal to 0, underflows the type of "win->win_size - 1UL", which is type "unsigned long". 70 win->win_size = ROUND_UP_TO_POW_OF_2(win->win_size); 71 WARN("Rounding size to 0x%" PRIx64 "\n", win->win_size); 72 } 73 } 74 75 static void amb_enable_win(struct addr_map_win *win, uint32_t win_num) /drivers/marvell/amb_adec.c: 60 in amb_check_win() 54 } 55 56 base_addr = win->base_addr << AMB_BASE_OFFSET; 57 /* for AMB The base is always 1M aligned */ 58 /* check if address is aligned to 1M */ 59 if (IS_NOT_ALIGN(base_addr, AMB_WIN_ALIGNMENT_1M)) { >>> CID 457908: (INTEGER_OVERFLOW) >>> Expression "base_addr + 1048576U", where "base_addr" is known to be equal to 4294901760, overflows the type of "base_addr + 1048576U", which is type "unsigned int". 60 win->base_addr = ALIGN_UP(base_addr, AMB_WIN_ALIGNMENT_1M); 61 WARN("Window %d: base address unaligned to 0x%x\n", 62 win_num, AMB_WIN_ALIGNMENT_1M); 63 WARN("Align up the base address to 0x%" PRIx64 "\n", win->base_addr); 64 } 65 ** CID 457907: Control flow issues (DEADCODE) /plat/mediatek/drivers/spm/mt8196/mt_spm_internal.c: 774 in __spm_set_pcm_wdt() ________________________________________________________________________________________________________ *** CID 457907: Control flow issues (DEADCODE) /plat/mediatek/drivers/spm/mt8196/mt_spm_internal.c: 774 in __spm_set_pcm_wdt() 768 /* Enable PCM WDT (normal mode) to start count if needed */ 769 if (en) { 770 mmio_clrsetbits_32(PCM_CON1, REG_PCM_WDT_WAKE_LSB, 771 SPM_REGWR_CFG_KEY); 772 773 if (mmio_read_32(PCM_TIMER_VAL) > PCM_TIMER_MAX) >>> CID 457907: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "mmio_write_32(469779860UL, ...". 774 mmio_write_32(PCM_TIMER_VAL, PCM_TIMER_MAX); 775 mmio_write_32(PCM_WDT_VAL, mmio_read_32(PCM_TIMER_VAL) + 776 PCM_WDT_TIMEOUT); 777 mmio_setbits_32(PCM_CON1, SPM_REGWR_CFG_KEY | 778 REG_PCM_WDT_EN_LSB); 779 } else { ** CID 457906: Integer handling issues (INTEGER_OVERFLOW) /plat/intel/soc/common/soc/socfpga_reset_manager.c: 1274 in socfpga_cpurstrelease() ________________________________________________________________________________________________________ *** CID 457906: Integer handling issues (INTEGER_OVERFLOW) /plat/intel/soc/common/soc/socfpga_reset_manager.c: 1274 in socfpga_cpurstrelease() 1268 cpurstrelease_status = mmio_read_32(SOCFPGA_RSTMGR(CPURSTRELEASE)); 1269 1270 if ((cpurstrelease_status & RSTMGR_CPUSTRELEASE_CPUx) == cpu_id) { 1271 return RSTMGR_RET_OK; 1272 } 1273 udelay(1000); >>> CID 457906: Integer handling issues (INTEGER_OVERFLOW) >>> Expression "timeout--", where "timeout" is known to be equal to 0, underflows the type of "timeout--", which is type "unsigned int". 1274 } while (timeout-- > 0); 1275 1276 return RSTMGR_RET_ERROR; ** CID 457905: Parse warnings (PARSE_ERROR) /mbedtls/library/common.h: 23 in () ________________________________________________________________________________________________________ *** CID 457905: Parse warnings (PARSE_ERROR) /mbedtls/library/common.h: 23 in () 17 #include <assert.h> 18 #include <stddef.h> 19 #include <stdint.h> 20 #include <stddef.h> 21 22 #if defined(__ARM_NEON) >>> CID 457905: Parse warnings (PARSE_ERROR) >>> cannot open source file "arm_neon.h" 23 #include <arm_neon.h> 24 #define MBEDTLS_HAVE_NEON_INTRINSICS 25 #elif defined(MBEDTLS_PLATFORM_IS_WINDOWS_ON_ARM64) 26 #include <arm64_neon.h> 27 #define MBEDTLS_HAVE_NEON_INTRINSICS 28 #endif ** CID 457904: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /plat/rockchip/rk3576/scmi/rk3576_clk.c: 517 in rk3576_lpll_get_rate() ________________________________________________________________________________________________________ *** CID 457904: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /plat/rockchip/rk3576/scmi/rk3576_clk.c: 517 in rk3576_lpll_get_rate() 511 512 rate64 *= m; 513 rate64 = rate64 / p; 514 515 if (k != 0) { 516 /* fractional mode */ >>> CID 457904: Integer handling issues (OVERFLOW_BEFORE_WIDEN) >>> Potentially overflowing expression "24000000U * k" with type "unsigned int" (32 bits, unsigned) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "uint64_t" (64 bits, unsigned). 517 uint64_t frac_rate64 = 24000000 * k; 518 519 postdiv = p * 65536; 520 frac_rate64 = frac_rate64 / postdiv; 521 rate64 += frac_rate64; 522 } ** CID 457903: Integer handling issues (INTEGER_OVERFLOW) /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1905 in mv_ddr_load_dm_pattern_to_odpg() ________________________________________________________________________________________________________ *** CID 457903: Integer handling issues (INTEGER_OVERFLOW) /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1905 in mv_ddr_load_dm_pattern_to_odpg() 1899 data_low = pattern_table_get_word(0, pattern, (u8)(pattern_len * 2)); 1900 data_high = pattern_table_get_word(0, pattern, (u8)(pattern_len * 2 + 1)); 1901 } 1902 1903 /* odpg mbus dm definition is opposite to ddr4 protocol */ 1904 if (dm_dir == DM_DIR_INVERSE) >>> CID 457903: Integer handling issues (INTEGER_OVERFLOW) >>> Expression "dm_data", where "~((data_low & 0xfU) | (data_high & 0xf0U))" is known to be equal to 255, overflows the type of "dm_data", which is type "u8". 1905 dm_data = ~((data_low & LOW_NIBBLE_BYTE_MASK) | (data_high & HIGH_NIBBLE_BYTE_MASK)); 1906 else 1907 dm_data = (data_low & LOW_NIBBLE_BYTE_MASK) | (data_high & HIGH_NIBBLE_BYTE_MASK); 1908 1909 ddr3_tip_if_write(0, access_type, 0, ODPG_DATA_WR_DATA_LOW_REG, data_low, MASK_ALL_BITS); 1910 ddr3_tip_if_write(0, access_type, 0, ODPG_DATA_WR_DATA_HIGH_REG, data_high, MASK_ALL_BITS); ** CID 457902: Insecure data handling (INTEGER_OVERFLOW) ________________________________________________________________________________________________________ *** CID 457902: Insecure data handling (INTEGER_OVERFLOW) /lib/libfdt/fdt_rw.c: 495 in fdt_pack() 489 int mem_rsv_size; 490 491 FDT_RW_PROBE(fdt); 492 493 mem_rsv_size = (fdt_num_mem_rsv(fdt)+1) 494 * sizeof(struct fdt_reserve_entry); >>> CID 457902: Insecure data handling (INTEGER_OVERFLOW) >>> "mem_rsv_size", which might have overflowed, is passed to "fdt_packblocks_(fdt, fdt, mem_rsv_size, fdt32_ld(&((struct fdt_header const *)fdt)->size_dt_struct), fdt32_ld(&((struct fdt_header const *)fdt)->size_dt_strings))". 495 fdt_packblocks_(fdt, fdt, mem_rsv_size, fdt_size_dt_struct(fdt), 496 fdt_size_dt_strings(fdt)); 497 fdt_set_totalsize(fdt, fdt_data_size_(fdt)); 498 499 return 0; ** CID 457901: Integer handling issues (INTEGER_OVERFLOW) /plat/mediatek/drivers/spmi/pmif_common.c: 111 in pmif_spmi_read_cmd() ________________________________________________________________________________________________________ *** CID 457901: Integer handling issues (INTEGER_OVERFLOW) /plat/mediatek/drivers/spmi/pmif_common.c: 111 in pmif_spmi_read_cmd() 105 ret = pmif_check_idle(arb->mstid); 106 if (ret) 107 goto done; 108 109 /* Send the command. */ 110 offset = arb->regs[PMIF_SWINF_3_ACC]; >>> CID 457901: Integer handling issues (INTEGER_OVERFLOW) >>> Expression "opc << 30", where "opc" is known to be equal to 2, overflows the type of "opc << 30", which is type "int". 111 mmio_write_32((uintptr_t)(arb->base + offset), PMIF_RW_CMD_SET(opc, 0, sid, bc, addr)); 112 /* 113 * Wait for Software Interface FSM state to be WFVLDCLR, 114 * read the data and clear the valid flag. 115 */ 116 ret = pmif_check_vldclr(arb->mstid); ** CID 457900: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /lib/extensions/amu/aarch32/amu.c: 51 in amu_enable() ________________________________________________________________________________________________________ *** CID 457900: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /lib/extensions/amu/aarch32/amu.c: 51 in amu_enable() 45 /* Enable all architected counters by default */ 46 write_amcntenset0(AMCNTENSET0_Pn_MASK); 47 if (is_feat_amu_aux_supported()) { 48 unsigned int core_pos = plat_my_core_pos(); 49 50 /* Something went wrong if we're trying to write higher bits */ >>> CID 457900: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "get_amu_aux_enables(core_pos) & 4294901760U /* ~0xffffU */" is always 0 regardless of the values of its operands. This occurs as a value. 51 assert((get_amu_aux_enables(core_pos) & ~AMCNTENSET1_Pn_MASK) == 0); 52 write_amcntenset1(get_amu_aux_enables(core_pos)); 53 } 54 55 /* Bail out if FEAT_AMUv1p1 features are not present. */ 56 if (!is_feat_amuv1p1_supported()) { ** CID 457899: (INTEGER_OVERFLOW) /lib/libfdt/fdt_rw.c: 476 in fdt_open_into() ________________________________________________________________________________________________________ *** CID 457899: (INTEGER_OVERFLOW) /lib/libfdt/fdt_rw.c: 474 in fdt_open_into() 468 /* Try right after the old tree instead */ 469 tmp = (char *)(uintptr_t)fdtend; 470 if ((tmp + newsize) > ((char *)buf + bufsize)) 471 return -FDT_ERR_NOSPACE; 472 } 473 >>> CID 457899: (INTEGER_OVERFLOW) >>> "mem_rsv_size", which might have overflowed, is passed to "fdt_packblocks_(fdt, tmp, mem_rsv_size, struct_size, fdt32_ld(&((struct fdt_header const *)fdt)->size_dt_strings))". 474 fdt_packblocks_(fdt, tmp, mem_rsv_size, struct_size, 475 fdt_size_dt_strings(fdt)); 476 memmove(buf, tmp, newsize); 477 478 fdt_set_magic(buf, FDT_MAGIC); 479 fdt_set_totalsize(buf, bufsize); /lib/libfdt/fdt_rw.c: 476 in fdt_open_into() 470 if ((tmp + newsize) > ((char *)buf + bufsize)) 471 return -FDT_ERR_NOSPACE; 472 } 473 474 fdt_packblocks_(fdt, tmp, mem_rsv_size, struct_size, 475 fdt_size_dt_strings(fdt)); >>> CID 457899: (INTEGER_OVERFLOW) >>> "newsize", which might have underflowed, is passed to "memmove(buf, tmp, newsize)". [Note: The source code implementation of the function has been overridden by a builtin model.] 476 memmove(buf, tmp, newsize); 477 478 fdt_set_magic(buf, FDT_MAGIC); 479 fdt_set_totalsize(buf, bufsize); 480 fdt_set_version(buf, 17); 481 fdt_set_last_comp_version(buf, 16); ** CID 457898: Control flow issues (UNREACHABLE) /plat/socionext/synquacer/sq_psci.c: 142 in sq_system_off() ________________________________________________________________________________________________________ *** CID 457898: Control flow issues (UNREACHABLE) /plat/socionext/synquacer/sq_psci.c: 142 in sq_system_off() 136 gpio[1] |= 0x2; /* set high */ 137 dmbst(); 138 139 mdelay(100); 140 } 141 >>> CID 457898: Control flow issues (UNREACHABLE) >>> This code cannot be reached: "wfi();". 142 wfi(); 143 ERROR("SQ System Off: operation not handled.\n"); 144 panic(); 145 #endif 146 } 147 ** CID 457897: Integer handling issues (INTEGER_OVERFLOW) /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 640 in ddr3_tip_ip_training() ________________________________________________________________________________________________________ *** CID 457897: Integer handling issues (INTEGER_OVERFLOW) /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 640 in ddr3_tip_ip_training() 634 CHECK_STATUS(ddr3_tip_configure_odpg 635 (dev_num, access_type, interface_num, direction, 636 pattern_table[pattern].num_of_phases_tx, tx_burst_size, 637 pattern_table[pattern].num_of_phases_rx, 638 delay_between_burst, rd_mode, effective_cs, STRESS_NONE, 639 DURATION_SINGLE)); >>> CID 457897: Integer handling issues (INTEGER_OVERFLOW) >>> Expression "reg_data", where "(direction == OPER_READ) ? 0 : -1073741824" is known to be equal to -1073741824, overflows the type of "reg_data", which is type "u32". 640 reg_data = (direction == OPER_READ) ? 0 : (0x3 << 30); 641 reg_data |= (direction == OPER_READ) ? 0x60 : 0xfa; 642 CHECK_STATUS(ddr3_tip_if_write 643 (dev_num, access_type, interface_num, 644 ODPG_WR_RD_MODE_ENA_REG, reg_data, 645 MASK_ALL_BITS)); ** CID 457896: Integer handling issues (INTEGER_OVERFLOW) /plat/mediatek/mt8183/drivers/devapc/devapc.c: 69 in set_master_domain_remap_infra() ________________________________________________________________________________________________________ *** CID 457896: Integer handling issues (INTEGER_OVERFLOW) /plat/mediatek/mt8183/drivers/devapc/devapc.c: 69 in set_master_domain_remap_infra() 63 domain_emi_view = domain_emi_view - DOMAIN_11; 64 clr_bit = 0x7 << (domain_emi_view * 3 + 1); 65 set_bit = domain_infra_view << (domain_emi_view * 3 + 1); 66 mmio_clrsetbits_32(base, clr_bit, set_bit); 67 } else { 68 base = DEVAPC_INFRA_DOM_RMP_0; >>> CID 457896: Integer handling issues (INTEGER_OVERFLOW) >>> Expression "clr_bit", where "3 << domain_emi_view * 3U" is known to be equal to -1073741824, overflows the type of "clr_bit", which is type "uint32_t". 69 clr_bit = 0x3 << (domain_emi_view * 3); 70 set_bit = domain_infra_view << (domain_emi_view * 3); 71 mmio_clrsetbits_32(base, clr_bit, set_bit); 72 73 base = DEVAPC_INFRA_DOM_RMP_1; 74 set_bit = (domain_infra_view & 0x4) >> 2; ** CID 457895: (DEADCODE) /drivers/nxp/ddr/phy-gen2/phy.c: 296 in get_cdd_val() /drivers/nxp/ddr/phy-gen2/phy.c: 241 in get_cdd_val() /drivers/nxp/ddr/phy-gen2/phy.c: 270 in get_cdd_val() ________________________________________________________________________________________________________ *** CID 457895: (DEADCODE) /drivers/nxp/ddr/phy-gen2/phy.c: 296 in get_cdd_val() 290 } 291 292 tmp = rwmax; 293 c = &cdd[25]; 294 rwmax = findmax(c, 16U); 295 if (tmp > rwmax) { >>> CID 457895: (DEADCODE) >>> Execution cannot reach this statement: "rwmax = tmp;". 296 rwmax = tmp; 297 } 298 299 wrmax = wwmax; 300 301 break; /drivers/nxp/ddr/phy-gen2/phy.c: 241 in get_cdd_val() 235 236 switch (rank) { 237 case 1U: 238 tmp = rwmax; 239 rwmax = cdd[40]; 240 if (tmp > rwmax) { >>> CID 457895: (DEADCODE) >>> Execution cannot reach this statement: "rwmax = tmp;". 241 rwmax = tmp; 242 } 243 244 break; 245 246 case 2U: /drivers/nxp/ddr/phy-gen2/phy.c: 270 in get_cdd_val() 264 buf[1] = cdd[39]; 265 buf[2] = cdd[36]; 266 buf[3] = cdd[35]; 267 tmp = rwmax; 268 rwmax = findmax(buf, 4U); 269 if (tmp > rwmax) { >>> CID 457895: (DEADCODE) >>> Execution cannot reach this statement: "rwmax = tmp;". 270 rwmax = tmp; 271 } 272 273 wrmax = wwmax; 274 275 break; ** CID 457894: Integer handling issues (INTEGER_OVERFLOW) /lib/libc/strtol.c: 127 in strtol() ________________________________________________________________________________________________________ *** CID 457894: Integer handling issues (INTEGER_OVERFLOW) /lib/libc/strtol.c: 127 in strtol() 121 any = 1; 122 acc *= base; 123 acc += c; 124 } 125 } 126 if (any < 0) { >>> CID 457894: Integer handling issues (INTEGER_OVERFLOW) >>> Expression "acc", where "neg ? -9223372036854775808L : 9223372036854775807L" is known to be equal to -9223372036854775808, underflows the type of "acc", which is type "unsigned long". 127 acc = neg ? LONG_MIN : LONG_MAX; 128 } else if (neg) 129 acc = -acc; 130 if (endptr != NULL) 131 *endptr = (char *)(any ? s - 1 : nptr); 132 return (acc); ** CID 457893: (INTEGER_OVERFLOW) /plat/rockchip/rk3399/drivers/dram/dfs.c: 973 in gen_rk3399_ctl_params_f1() /plat/rockchip/rk3399/drivers/dram/dfs.c: 976 in gen_rk3399_ctl_params_f1() ________________________________________________________________________________________________________ *** CID 457893: (INTEGER_OVERFLOW) /plat/rockchip/rk3399/drivers/dram/dfs.c: 973 in gen_rk3399_ctl_params_f1() 967 tmp = 0; 968 else if (tmp1 < 5) 969 tmp = tmp1 - 1; 970 else 971 tmp = tmp1 - 5; 972 } else { >>> CID 457893: (INTEGER_OVERFLOW) >>> Expression "tmp1 - 2U", where "tmp1" is known to be equal to 0, underflows the type of "tmp1 - 2U", which is type "unsigned int". 973 tmp = tmp1 - 2; 974 } 975 976 mmio_clrsetbits_32(CTL_REG(i, 314), 0xffu << 24, tmp << 24); 977 978 /* CTL_314 TDFI_RDCSLAT_F1:RW:16:8 */ /plat/rockchip/rk3399/drivers/dram/dfs.c: 976 in gen_rk3399_ctl_params_f1() 970 else 971 tmp = tmp1 - 5; 972 } else { 973 tmp = tmp1 - 2; 974 } 975 >>> CID 457893: (INTEGER_OVERFLOW) >>> Expression "tmp << 24", where "tmp" is known to be equal to 4294967294, overflows the type of "tmp << 24", which is type "uint32_t". 976 mmio_clrsetbits_32(CTL_REG(i, 314), 0xffu << 24, tmp << 24); 977 978 /* CTL_314 TDFI_RDCSLAT_F1:RW:16:8 */ 979 if ((timing_config->freq <= TDFI_LAT_THRESHOLD_FREQ) && 980 (pdram_timing->cl >= 5)) 981 tmp = pdram_timing->cl - 5; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://scan.coverity.com/projects/arm-software-arm-trusted-firmware?tab=ov…

2 months, 3 weeks

2
1
0 0

Canceled event with note: TF-A Tech Forum @ Thu Mar 20, 2025 5pm - 6pm (GMT+1) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

This event has been canceled with a note: "Hi, Cancelling as no topic proposed. Regards, Olivier. " TF-A Tech Forum Thursday Mar 20, 2025 ⋅ 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 ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the 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

2 months, 3 weeks

1
0
0 0

Coverity scan infra

by Bollapalli, Maheedhar Sai

[AMD Official Use Only - AMD Internal Distribution Only] Hi TF-A Team, With our internal Coverity infrastructure we are seeing multiple MISRA C issues reported (enforced) for transfer-list, while TF-A upstream CI pipeline reports only subset of those violation issues. Could you please share Coverity configuration used in TF-A upstream CI pipeline ? Regards, Maheedhar.

2 months, 3 weeks

3
3
0 0

Canceled event with note: TF-A Tech Forum @ Thu Mar 6, 2025 5pm - 6pm (GMT+1) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

This event has been canceled with a note: "Hi, Cancelling as no topic proposed. Regards, Olivier. " TF-A Tech Forum Thursday Mar 6, 2025 ⋅ 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 ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the 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

3 months, 1 week

1
0
0 0

Trusted Firmware-A LTS v2.10.14 Release Announcement

by ci_notify＠trustedfirmware.org

Hello, Trusted Firmware-A LTS version 2.10.14 is now available. This release contains the following patches: 926f86bac refactor(build): allow mandatory feats disabling [1] 48b41b441 refactor(build): refactor mandatory options [2] eb26e7855 fix(build): march handling with arch-features [3] 9e469a880 refactor(build): remove enabling feat [4] f0d197618 refactor(build): minor updates [5] c7d9465b9 feat(trbe): introduce trbe_disable() function [6] b9e252aee feat(cpus): add ENABLE_ERRATA_ALL flag [7] [1] https://review.trustedfirmware.org/q/I6fdca1a3d0b405a88cd7a20309e0c1eecd57a… [2] https://review.trustedfirmware.org/q/I8b0dd076c168a647de43b8618fbbe607412f7… [3] https://review.trustedfirmware.org/q/Ifaf99af5f371fd28db376a12657ccf4f36329… [4] https://review.trustedfirmware.org/q/I8565ac4ebb3ced29835be65ea5b043a088108… [5] https://review.trustedfirmware.org/q/I12a4940e82ca5df72af5421ddab43bc6a1628… [6] https://review.trustedfirmware.org/q/If3e3bd621684b3c28f44c3ed2fe3df30b143f… [7] https://review.trustedfirmware.org/q/I2b456d304d7bf3215c7c4f4fd70b56ecbcb09… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.10.14/change-log.html Thanks, TF-A LTS team

3 months, 2 weeks

1
0
0 0

Trusted Firmware-A LTS v2.12.1 Release Announcement

by ci_notify＠trustedfirmware.org

3 months, 2 weeks

1
0
0 0

Trusted Firmware-A LTS v2.12.0 Release Announcement

by ci_notify＠trustedfirmware.org

Hello, Trusted Firmware-A LTS version 2.12.0 is now available. This release contains the following patches: Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.12.0/change-log.html Thanks, TF-A LTS team

3 months, 2 weeks

1
0
0 0

Trusted Firmware-A LTS v2.12.1 Release Announcement

by ci_notify＠trustedfirmware.org

Hello, Trusted Firmware-A LTS version 2.12.1 is now available. This release contains the following patches: Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.12.1/change-log.html Thanks, TF-A LTS team

3 months, 3 weeks

1
0
0 0

Trusted Firmware-A LTS v2.8.30 Release Announcement

by ci_notify＠trustedfirmware.org

Hello, Trusted Firmware-A LTS version 2.8.30 is now available. This release contains the following patches: 983f4c8ed chore(cpus): fix incorrect header macro [1] 1a2a26897 refactor(errata-abi): move EXTRACT_PARTNUM to arch.h [2] 37db9abef refactor(cm): move remaining EL2 save/restore into C [3] f2a263ed8 fix(cm): update gic el2 sysregs save/restore mechanism [4] 8c6068fab fix(cpus): workaround for accessing ICH_VMCR_EL2 [5] c32e3a38d fix(cpus): workaround for Cortex-A710 erratum 3701772 [6] 3b8a3ad15 fix(cpus): workaround for Cortex-A715 erratum 3699560 [7] c7d5de9fe fix(cpus): workaround for Cortex-A720 erratum 3699561 [8] 2296df6fe fix(cpus): workaround for Cortex-X2 erratum 3701772 [9] ed4bd3c61 fix(cpus): workaround for Cortex-X3 erratum 3701769 [10] 395f67e87 fix(cpus): workaround for Cortex-X4 erratum 3701758 [11] 2414a852a fix(cpus): workaround for Neoverse-N2 erratum 3701773 [12] 35caff979 fix(cpus): workaround for Neoverse-V3 erratum 3701767 [13] 55589ce29 chore(smccc): bump up SMCCC version to 1.4 [14] [1] https://review.trustedfirmware.org/q/I6a4a8ec6546adb41e24d8885cb445fa8be830… [2] https://review.trustedfirmware.org/q/Id8bbaf21566f3145a75cfa0dafec6823ed2df… [3] https://review.trustedfirmware.org/q/If690f792e70b97fd4b4cd5f43847a71719b12… [4] https://review.trustedfirmware.org/q/I8d55c3dc6a17c4749748822d4a738912c1e13… [5] https://review.trustedfirmware.org/q/I9f0403601c6346276e925f02eab55908b009d… [6] https://review.trustedfirmware.org/q/I997c9cfaa75321f22b4f690c4d3f234c0b51c… [7] https://review.trustedfirmware.org/q/I183aa921b4b6f715d64eb6b70809de2566017… [8] https://review.trustedfirmware.org/q/I7ea3aaf3e7bf6b4f3648f6872e505a41247b1… [9] https://review.trustedfirmware.org/q/I2ffc5e7d7467f1bcff8b895fea52a1daa7d14… [10] https://review.trustedfirmware.org/q/Ifd722e1bb8616ada2ad158297a7ca80b19a33… [11] https://review.trustedfirmware.org/q/I4ee941d1e7653de7a12d69f538ca05f7f9f99… [12] https://review.trustedfirmware.org/q/If95bd67363228c8083724b31f630636fb27f3… [13] https://review.trustedfirmware.org/q/I5be0de881f408a9e82a07b8459d79490e9065… [14] https://review.trustedfirmware.org/q/Ie5476c4601bd504d3f3e8433e1d672ebd0a75… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.8.30/change-log.html Thanks, TF-A LTS team

3 months, 3 weeks

1
0
0 0

Canceled event with note: TF-A Tech Forum @ Thu Feb 20, 2025 5pm - 6pm (GMT+1) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

This event has been canceled with a note: "Hi, No topic planned for today. Thanks & Regards, Olivier." TF-A Tech Forum Thursday Feb 20, 2025 ⋅ 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 ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the 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

3 months, 3 weeks

1
0
0 0

Trusted Firmware-A LTS v2.10.13 Release Announcement

by ci_notify＠trustedfirmware.org

Hello, Trusted Firmware-A LTS version 2.10.13 is now available. This release contains the following patches: b2be8b051 fix(security): enable WORKAROUND_CVE_2024_7881 build option [1] 8618e9d8f fix(security): add CVE-2024-7881 mitigation to Cortex-X4 [2] 81476ada1 fix(security): add CVE-2024-7881 mitigation to Cortex-X925 [3] 6caef6a1f fix(security): add CVE-2024-7881 mitigation to Neoverse-V2 [4] a7371652e fix(security): add CVE-2024-7881 mitigation to Neoverse-V3 [5] 023e80d4c fix(security): add CVE-2024-7881 mitigation to Cortex-X3 [6] b5386661a fix(security): add support in cpu_ops for CVE-2024-7881 [7] 64618d664 fix(security): apply SMCCC_ARCH_WORKAROUND_4 to affected cpus [8] f823cc74e fix(cm): update gic el2 sysregs save/restore mechanism [9] 053bdc35f refactor(fvp): move cpus with nomodel [10] 813f66774 chore: rename hermes to neoverse-n3 [11] 86b37315e chore(cpus): fix incorrect header macro [12] 57ab066a2 refactor(errata-abi): move EXTRACT_PARTNUM to arch.h [13] 57bdc57e3 fix(cpus): workaround for accessing ICH_VMCR_EL2 [14] 8f709377f fix(cpus): workaround for Cortex-A710 erratum 3701772 [15] 857cfc2e9 fix(cpus): workaround for Cortex-A715 erratum 3699560 [16] 36b53f90f fix(cpus): workaround for Cortex-A720 erratum 3699561 [17] 17b8a8a33 fix(cpus): workaround for Cortex-A725 erratum 3699564 [18] 3e9433d76 fix(cpus): workaround for Cortex-X2 erratum 3701772 [19] 1852f608b fix(cpus): workaround for Cortex-X3 erratum 3701769 [20] db3048d54 fix(cpus): workaround for Cortex-X4 erratum 3701758 [21] c8a6cc0a1 fix(cpus): workaround for Cortex-X925 erratum 3701747 [22] 1d17578bd fix(cpus): workaround for Neoverse-N2 erratum 3701773 [23] e2a5da1c0 fix(cpus): workaround for Neoverse-N3 erratum 3699563 [24] fc497736f fix(cpus): workaround for Neoverse-V3 erratum 3701767 [25] [1] https://review.trustedfirmware.org/q/Id77f82a4dfaa4422729f7e3f2429f47cc90d9… [2] https://review.trustedfirmware.org/q/I0bec96d4f71a08a89c6612e272ecfb173f80d… [3] https://review.trustedfirmware.org/q/I53e72e4dbc8937cea3c344a5ba04664c50a07… [4] https://review.trustedfirmware.org/q/I129814eb3494b287fd76a3f7dbc50f76553b2… [5] https://review.trustedfirmware.org/q/Ib5c644895b8c76d3c7e8b5e6e98d7b9afef7f… [6] https://review.trustedfirmware.org/q/I410517d175a80fc6f459fa6ce5c30c0a38db9… [7] https://review.trustedfirmware.org/q/I417389f040c6ead7f96f9b720d29061833f43… [8] https://review.trustedfirmware.org/q/I1b1ffaa1f806f07472fd79d5525f81764d99b… [9] https://review.trustedfirmware.org/q/I8d55c3dc6a17c4749748822d4a738912c1e13… [10] https://review.trustedfirmware.org/q/I3da12d2f8d9c246b435b31adfac61c79dc1ab… [11] https://review.trustedfirmware.org/q/I912d4c824c5004a8c1909c68fef77f1f5e202… [12] https://review.trustedfirmware.org/q/I6a4a8ec6546adb41e24d8885cb445fa8be830… [13] https://review.trustedfirmware.org/q/Id8bbaf21566f3145a75cfa0dafec6823ed2df… [14] https://review.trustedfirmware.org/q/I9f0403601c6346276e925f02eab55908b009d… [15] https://review.trustedfirmware.org/q/I997c9cfaa75321f22b4f690c4d3f234c0b51c… [16] https://review.trustedfirmware.org/q/I183aa921b4b6f715d64eb6b70809de2566017… [17] https://review.trustedfirmware.org/q/I7ea3aaf3e7bf6b4f3648f6872e505a41247b1… [18] https://review.trustedfirmware.org/q/Ifad1f6c3f5b74060273f897eb5e4b79dd9f08… [19] https://review.trustedfirmware.org/q/I2ffc5e7d7467f1bcff8b895fea52a1daa7d14… [20] https://review.trustedfirmware.org/q/Ifd722e1bb8616ada2ad158297a7ca80b19a33… [21] https://review.trustedfirmware.org/q/I4ee941d1e7653de7a12d69f538ca05f7f9f99… [22] https://review.trustedfirmware.org/q/I080296666f89276b3260686c2bdb8de63fc17… [23] https://review.trustedfirmware.org/q/If95bd67363228c8083724b31f630636fb27f3… [24] https://review.trustedfirmware.org/q/I77aaf8ae0afff3adde9a85f4a1a13ac9d1daf… [25] https://review.trustedfirmware.org/q/I5be0de881f408a9e82a07b8459d79490e9065… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.10.13/change-log.html Thanks, TF-A LTS team

3 months, 4 weeks

1
0
0 0

Trusted Firmware-A LTS v2.8.29 Release Announcement

by ci_notify＠trustedfirmware.org

Hello, Trusted Firmware-A LTS version 2.8.29 is now available. This release contains the following patches: 772bdd3bc style: normalize linker script code style [1] cf5e7d8d4 build: always prefix section names with `.` [2] e2084abfc fix(services): disable workaround discovery on aarch32 for now [3] cc04eac23 fix(security): enable WORKAROUND_CVE_2024_7881 build option [4] 2ef768d4a fix(security): add CVE-2024-7881 mitigation to Cortex-X4 [5] 172ccad6a fix(security): add CVE-2024-7881 mitigation to Neoverse-V2 [6] cbf4a4e3c fix(security): add CVE-2024-7881 mitigation to Neoverse-V3 [7] a7f53d34f fix(security): add CVE-2024-7881 mitigation to Cortex-X3 [8] 8fc0fa7c0 fix(security): add support in cpu_ops for CVE-2024-7881 [9] 337aa3bf1 fix(security): apply SMCCC_ARCH_WORKAROUND_4 to affected cpus [10] 1e4b43644 feat(fvp): allow configurable FVP Trusted SRAM size [11] [1] https://review.trustedfirmware.org/q/Ibee2afad0d543129c9ba5a8a22e3ec17d77e3… [2] https://review.trustedfirmware.org/q/I51c13c5266d5975fbd944ef4961328e72f82f… [3] https://review.trustedfirmware.org/q/Ic19973a8e4d50a97f274d4461794c117b3373… [4] https://review.trustedfirmware.org/q/Id77f82a4dfaa4422729f7e3f2429f47cc90d9… [5] https://review.trustedfirmware.org/q/I0bec96d4f71a08a89c6612e272ecfb173f80d… [6] https://review.trustedfirmware.org/q/I129814eb3494b287fd76a3f7dbc50f76553b2… [7] https://review.trustedfirmware.org/q/Ib5c644895b8c76d3c7e8b5e6e98d7b9afef7f… [8] https://review.trustedfirmware.org/q/I410517d175a80fc6f459fa6ce5c30c0a38db9… [9] https://review.trustedfirmware.org/q/I417389f040c6ead7f96f9b720d29061833f43… [10] https://review.trustedfirmware.org/q/I1b1ffaa1f806f07472fd79d5525f81764d99b… [11] https://review.trustedfirmware.org/q/I8344d3718564cd2bd53f1e6860e2fe341ae24… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.8.29/change-log.html Thanks, TF-A LTS team

3 months, 4 weeks

1
0
0 0

TBBR: Question about the available Non Volatile Counters

by Rares Constantin

Hi, I have a question regarding the TBBR implementation for non-volatile counters in TF-A. While looking through the code and documentation for Trusted Boot authentication options, it was not clear why there are only two non-volatile counters for the Trusted and Non-Trusted worlds (`TRUSTED_FW_NVCOUNTER` and `NON_TRUSTED_FW_NVCOUNTER`). This is true for the Arm DEN0006D specification, but it was retired and ARM DEN0072 is the current specification. Is there any specific reason why there isn't a counter for each authenticated image declared and created by `cert_create` or is the retired specification the only reason? This limits the non-volatile counter extensions for all certificates, meaning that the Trusted OS content certificate for example cannot be authenticated with another extension, unless I add a custom certificate with another non-volatile counter extension and a new command line option. To quote the ARM DEN0072 TBBR specification [source: https://developer.arm.com/documentation/den0072/latest]: "It is recommended to implement as many version counters as there are images, where each image can use a separate counter without affecting other images. However, the number of rollback counters that can practically be supported is implementation dependent.". Thank you!

3 months, 4 weeks

2
3
0 0

Canceled event with note: TF-A Tech Forum @ Thu Feb 6, 2025 5pm - 6pm (GMT+1) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

This event has been canceled with a note: "Hi, Cancelling as no topic proposed this week. Regards, Olivier. " TF-A Tech Forum Thursday Feb 6, 2025 ⋅ 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 ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the 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

4 months, 1 week

1
0
0 0

Trusted Firmware-A LTS v2.8.28 Release Announcement

by ci_notify＠trustedfirmware.org

Hello, Trusted Firmware-A LTS version 2.8.28 is now available. This release contains the following patches: d4ce532c6 fix(arm): add extra hash config to validate ROTPK [1] 0f7eed07d refactor(mbedtls): rename default mbedtls confs [2] ae45ec9d4 docs(prerequisites): update mbedtls to version 3.6.2 [3] 8c37a4b7f feat(mbedtls): mbedtls config update for v3.6.2 [4] bf358fef7 docs: add inital lts doc [5] 633fc7323 docs: updates to LTS [6] 0330b630a chore(deps): bump jinja2 in the pip group across 1 directory [7] b3d5cc387 chore(deps): bump cross-spawn [8] 2c6035419 docs(maintainers): update LTS maintainers [9] [1] https://review.trustedfirmware.org/q/Ib3128ce7b0fb5c0858624ecbc998d456968be… [2] https://review.trustedfirmware.org/q/I1f665c2471877ecc833270c511749ff845046… [3] https://review.trustedfirmware.org/q/Ibc4a8712c92019648fe0e75390cd3540d86b7… [4] https://review.trustedfirmware.org/q/I79027f6c741ab3f419f7b555321507e6a78b9… [5] https://review.trustedfirmware.org/q/I1434c29f0236161d2a127596e2cc528bf4cc3… [6] https://review.trustedfirmware.org/q/Iafc606a66ea3ea69c51b433867b5025b8debe… [7] https://review.trustedfirmware.org/q/I4502ed17a6ce37f53ac64370a5d7fe756875f… [8] https://review.trustedfirmware.org/q/I78624d7ef8c3842a2271d091bf2d3213d9455… [9] https://review.trustedfirmware.org/q/Ibf087c6b0e24d6faa9dafb6f8a0955a47f583… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.8.28/change-log.html Thanks, TF-A LTS team

4 months, 2 weeks

1
0
0 0

Trusted Firmware-A LTS v2.10.12 Release Announcement

by ci_notify＠trustedfirmware.org

Hello, Trusted Firmware-A LTS version 2.10.12 is now available. This release contains the following patches: 8b2c88573 fix(arm): add extra hash config to validate ROTPK [1] 0ac65e7aa refactor(mbedtls): rename default mbedtls confs [2] 44161dcb1 docs(prerequisites): update mbedtls to version 3.6.2 [3] 564922601 feat(mbedtls): mbedtls config update for v3.6.2 [4] 13657a3f3 docs: add inital lts doc [5] 3d85a19f2 docs: updates to LTS [6] 7c8c034e5 chore(deps): bump jinja2 in the pip group across 1 directory [7] 924c7f42c chore(deps): bump cross-spawn [8] 8355ef772 docs(maintainers): update LTS maintainers [9] [1] https://review.trustedfirmware.org/q/Ib3128ce7b0fb5c0858624ecbc998d456968be… [2] https://review.trustedfirmware.org/q/I1f665c2471877ecc833270c511749ff845046… [3] https://review.trustedfirmware.org/q/Ibc4a8712c92019648fe0e75390cd3540d86b7… [4] https://review.trustedfirmware.org/q/I79027f6c741ab3f419f7b555321507e6a78b9… [5] https://review.trustedfirmware.org/q/I1434c29f0236161d2a127596e2cc528bf4cc3… [6] https://review.trustedfirmware.org/q/Iafc606a66ea3ea69c51b433867b5025b8debe… [7] https://review.trustedfirmware.org/q/I4502ed17a6ce37f53ac64370a5d7fe756875f… [8] https://review.trustedfirmware.org/q/I78624d7ef8c3842a2271d091bf2d3213d9455… [9] https://review.trustedfirmware.org/q/Ibf087c6b0e24d6faa9dafb6f8a0955a47f583… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.10.12/change-log.html Thanks, TF-A LTS team

4 months, 2 weeks

1
0
0 0

question about encryption

by 林觀明

Hi I tried to turn on encryption in BL31. And, I met some trouble. Here is my code. ``` static struct plat_io_policy policies[] = { ... [BL31_IMAGE_ID] = {&enc_dev_handle, &bl31_uuid_spec, check_enc_fip}, .... [ENC_IMAGE_ID] = {&fip_dev_handle, NULL, check_fip} } int plat_get_image_source(...) { ... policy = &policies[image_id]; ret = policy->check[policy->image_spec]; ... } static int check_fip(const uintptr_t spec) { int ret; ret = io_dev_open(fip_dev_con, (uintptr_t)NULL, &fip_dev_handle); if (ret) { ERROR("io_dev_open failed for FIP (%d)\n", ret); return ret; } ret = io_dev_init(fip_dev_handle, fip_image_id); if (ret) { ERROR("io_dev_init failed for FIP image id %lu (%d)\n", fip_image_id, ret); io_dev_close(fip_dev_handle); } return ret; } static int check_enc_fip(const uintptr_t spec) { int result; uintptr_t local_image_handle; /* See if a Firmware Image Package is available */ result = io_dev_open(enc_dev_con, (uintptr_t)NULL, &enc_dev_handle); if (result) { ERROR("io_dev_open failed for FIP (%d)\n", result); return result; } result = io_dev_init(enc_dev_handle, (uintptr_t)ENC_IMAGE_ID); if (result != 0) return result; return result; } ``` But, I can't boot successfully. Below is log. ``` INFO: Image id=3 loaded: 0x40800000 - 0x4080e299 INFO: BL2: Loading image id 5 WARNING: ===== allocate_dev_info 1 ===== WARNING: ==== -12 ==== ERROR: io_dev_open failed for FIP (-12) ERROR: Image id 11 open failed with -12 WARNING: Failed to obtain reference to image id=11 (-12) ERROR: BL2: Failed to load image id 5 (-12) ``` And, I found root cause in `allocate_dev_info` and `free_dev_info` in `drivers/io/io_fip.c` In `allocate_dev_info`, there is a count, `fip_dev_count`, increasing by 1 after calling `fip_dev_open` There is a check. The value of MAX_FIP_DEVICES is 1. ``` if (fip_dev_count < (unsigned int)MAX_FIP_DEVICES) { unsigned int index = 0; result = find_first_fip_state(0, &index); assert(result == 0); /* initialize dev_info */ dev_info_pool[index].funcs = &fip_dev_funcs; dev_info_pool[index].info = (uintptr_t)&state_pool[index]; *dev_info = &dev_info_pool[index]; ++fip_dev_count; } ``` And, in `fip_dev_close`, The `fip_dev_count` will be decreased by 1. However, The root casue is it call fip_dev_open but not calling fip_dev_close. It cause the `fip_dev_count` not be decreased by 1. Now, I have two solution. 1. Increasing the MAX_FIP_DEVICES, it will be working. 2. Add the io_dev_close in `enc_dev_close` in `driver/io_/io_encrypted.c`. And, it will call the fip_dev_close. It will be working. Do you have any idea in this solution ? Which solution is more general ? Thanks !

4 months, 3 weeks

2
1
0 0

TF-A Tech Forum - Jan 23rd 2025 - RMM design of EL0 applications support

by Olivier Deprez

Hi, On Jan 23rd 2025, in the TF-A Tech forum, Mate Toth-Pal and Soby Mathew will present the RMM design of EL0 applications support. The TF-A Tech forum is a regular open forum for anyone from the open source community to participate. Feel free to reach if you have a topic you'd want to present. It can be a design review with slides, walking through RFC patches, or more generic discussion around open source projects. Regards, Olivier. TF-A Tech Forum Thursday Jan 23, 2025 ⋅ 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

4 months, 3 weeks

1
0
0 0

Trusted Firmware-A LTS v2.8.27 Release Announcement

by ci_notify＠trustedfirmware.org

Hello, Trusted Firmware-A LTS version 2.8.27 is now available. This release contains the following patches: 03d2ef8b0 fix(cpus): workaround for CVE-2024-5660 for Cortex-X4 [1] 85b4f4595 fix(cpus): workaround for CVE-2024-5660 for Neoverse-V3 [2] 9761fcc4d fix(cpus): workaround for CVE-2024-5660 for Cortex-X3 [3] cfa1200ff fix(cpus): workaround for CVE-2024-5660 for Neoverse-V2 [4] 5625d9e28 fix(cpus): workaround for CVE-2024-5660 for Cortex-A710 [5] ca1a7aaf7 fix(cpus): workaround for CVE-2024-5660 for Neoverse-N2 [6] feb80a641 fix(cpus): workaround for CVE-2024-5660 for Cortex-X1 [7] de65c9fc4 fix(cpus): workaround for CVE-2024-5660 for Cortex-A78 [8] d87e44989 fix(cpus): workaround for CVE-2024-5660 for Cortex-A78C [9] 5e9988827 fix(cpus): workaround for CVE-2024-5660 for Cortex-A78_AE [10] ba5453ca4 fix(cpus): workaround for CVE-2024-5660 for Neoverse-V1 [11] 1f48d849e fix(cpus): workaround for CVE-2024-5660 for Cortex-A77 [12] 07a4df505 fix(cpus): workaround for CVE-2024-5660 for Cortex-X2 [13] 9f342211f chore(cpus): optimise runtime errata applications [14] 3edd92a1f fix(cpus): workaround for Cortex-X4 erratum 2923985 [15] [1] https://review.trustedfirmware.org/q/I378cb4978919cced03e7febc2ad431c572eac… [2] https://review.trustedfirmware.org/q/I9ed2590bf1215bf6a692f01dfd351e469ff07… [3] https://review.trustedfirmware.org/q/Ibe90313948102ece3469f2cfe3faccc7f4bee… [4] https://review.trustedfirmware.org/q/If66687add52d16f68ce54fe5433dd3b3f067e… [5] https://review.trustedfirmware.org/q/I10feea238600dcceaac7bb75a59db7913ca65… [6] https://review.trustedfirmware.org/q/I2b9dea78771cc159586a03ff563c0ec79591e… [7] https://review.trustedfirmware.org/q/I3124db3980f2786412369a010ca6abbbbaa3b… [8] https://review.trustedfirmware.org/q/I4e40388bef814481943b2459fe35dd7267c62… [9] https://review.trustedfirmware.org/q/Ieb8d7b122320d16bf8987a43dc683ca41227b… [10] https://review.trustedfirmware.org/q/I33ac653fcb45f687fe9ace1c76a3eb2000459… [11] https://review.trustedfirmware.org/q/Ia59452ea38c66b291790956d7f2880bfcd56d… [12] https://review.trustedfirmware.org/q/Ic71b163883ea624e9f2f77deb8b30c6961293… [13] https://review.trustedfirmware.org/q/If28804e154617a39d7d52c40b3a00a14a39df… [14] https://review.trustedfirmware.org/q/I02f9dd7d0619feb54c870938ea186be5e3a6c… [15] https://review.trustedfirmware.org/q/I9207802ad479919a7f77c1271019fa2479e07… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.8.27/change-log.html Thanks, TF-A LTS team

5 months

1
0
0 0

Trusted Firmware-A LTS v2.10.11 Release Announcement

by ci_notify＠trustedfirmware.org

Hello, Trusted Firmware-A LTS version 2.10.11 is now available. This release contains the following patches: 96498991d chore: rename Chaberton to Cortex-A725 [1] b229b47bd chore: rename Blackhawk to Cortex-X925 [2] 698e68fe1 fix(cpus): workaround for CVE-2024-5660 for Cortex-X925 [3] e42abf298 fix(cpus): workaround for CVE-2024-5660 for Cortex-X4 [4] a6375e1fe fix(cpus): workaround for CVE-2024-5660 for Neoverse-V3 [5] 17e17ed3f fix(cpus): workaround for CVE-2024-5660 for Cortex-X3 [6] 3efc9e130 fix(cpus): workaround for CVE-2024-5660 for Neoverse-V2 [7] f7ae819f0 fix(cpus): workaround for CVE-2024-5660 for Cortex-A710 [8] 282e63544 fix(cpus): workaround for CVE-2024-5660 for Neoverse-N2 [9] c7d3c9eb2 fix(cpus): workaround for CVE-2024-5660 for Cortex-X1 [10] 30c57c58a fix(cpus): workaround for CVE-2024-5660 for Cortex-A78 [11] 87250d2bb fix(cpus): workaround for CVE-2024-5660 for Cortex-A78C [12] a02a863d3 fix(cpus): workaround for CVE-2024-5660 for Cortex-A78_AE [13] 4fd2a6702 fix(cpus): workaround for CVE-2024-5660 for Neoverse-V1 [14] 5673d345a fix(cpus): workaround for CVE-2024-5660 for Cortex-A77 [15] ad9dfdc58 fix(cpus): workaround for CVE-2024-5660 for Cortex-X2 [16] 0eed05ee7 chore(cpus): optimise runtime errata applications [17] 196984e65 fix(cpus): workaround for Cortex-X4 erratum 2923985 [18] [1] https://review.trustedfirmware.org/q/I981b22d3b37f1aa6e25ff1f35aa156fff9c30… [2] https://review.trustedfirmware.org/q/I51e40a7bc6b8871c53c40d1f341853b1fd7fd… [3] https://review.trustedfirmware.org/q/I9d5a07ca6b89b27d8876f4349eff2af26c962… [4] https://review.trustedfirmware.org/q/I378cb4978919cced03e7febc2ad431c572eac… [5] https://review.trustedfirmware.org/q/I9ed2590bf1215bf6a692f01dfd351e469ff07… [6] https://review.trustedfirmware.org/q/Ibe90313948102ece3469f2cfe3faccc7f4bee… [7] https://review.trustedfirmware.org/q/If66687add52d16f68ce54fe5433dd3b3f067e… [8] https://review.trustedfirmware.org/q/I10feea238600dcceaac7bb75a59db7913ca65… [9] https://review.trustedfirmware.org/q/I2b9dea78771cc159586a03ff563c0ec79591e… [10] https://review.trustedfirmware.org/q/I3124db3980f2786412369a010ca6abbbbaa3b… [11] https://review.trustedfirmware.org/q/I4e40388bef814481943b2459fe35dd7267c62… [12] https://review.trustedfirmware.org/q/Ieb8d7b122320d16bf8987a43dc683ca41227b… [13] https://review.trustedfirmware.org/q/I33ac653fcb45f687fe9ace1c76a3eb2000459… [14] https://review.trustedfirmware.org/q/Ia59452ea38c66b291790956d7f2880bfcd56d… [15] https://review.trustedfirmware.org/q/Ic71b163883ea624e9f2f77deb8b30c6961293… [16] https://review.trustedfirmware.org/q/If28804e154617a39d7d52c40b3a00a14a39df… [17] https://review.trustedfirmware.org/q/I02f9dd7d0619feb54c870938ea186be5e3a6c… [18] https://review.trustedfirmware.org/q/I9207802ad479919a7f77c1271019fa2479e07… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.10.11/change-log.html Thanks, TF-A LTS team

5 months

1
0
0 0

Canceled event with note: TF-A Tech Forum @ Thu Jan 9, 2025 5pm - 6pm (GMT+1) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

This event has been canceled with a note: "Hi, No topic planned for this week. Regards, Olivier. " TF-A Tech Forum Thursday Jan 9, 2025 ⋅ 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 ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the 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

5 months

1
0
0 0

Re: Linker errors with ENABLE_LTO and LD overriding

by Bollapalli, Maheedhar Sai

Hi, Adding further details: build command, error log and linker version. Build command : make -j12 CC=aarch64-none-elf-gcc LD=aarch64-none-elf-ld CROSS_COMPILE=aarch64-none-elf- PLAT=zynqmp RESET_TO_BL31=1 DEBUG=1 ZYNQMP_CONSOLE=dtb bl31 Error Log: usr/bin/aarch64-xilinx-elf/aarch64-xilinx-elf-ld.real: build/zynqmp/debug/bl31/bl31_entrypoint.o: in function `bl31_entrypoint': bl31/aarch64/bl31_entrypoint.S:79:(.text.asm.bl31_entrypoint+0x108): undefined reference to `bl31_setup' bl31/aarch64/bl31_entrypoint.S:93:(.text.asm.bl31_entrypoint+0x10c): undefined reference to `bl31_main' build/zynqmp/debug/bl31/cpu_data.o: in function `_cpu_data_by_index': lib/el3_runtime/aarch64/cpu_data.S:44:(.text.asm._cpu_data_by_index+0x8): undefined reference to `percpu_data' usr/bin/aarch64-xilinx-elf/aarch64-xilinx-elf-ld.real: lib/el3_runtime/aarch64/cpu_data.S:45:(.text.asm._cpu_data_by_index+0xc): undefined reference to `percpu_data' usr/bin/aarch64-xilinx-elf/aarch64-xilinx-elf-ld.real: build/zynqmp/debug/bl31/context.o: in function `el3_exit': arm-trusted-firmware$ aarch64-none-elf-ld --version GNU ld (GNU Binutils) 2.42.0.20240620 arm-trusted-firmware$ aarch64-none-elf-gcc --version aarch64-xilinx-elf-gcc.real (GCC) 13.3.0 Regards, Maheedhar.

5 months, 1 week

3
4
0 0

Erratum 1530924 handling

by Bollapalli, Maheedhar Sai

Hi, On AMD-Xilinx ZynqMP platform there is a erratum (1530924) which is mentioned as applied as shown in the log below: " INFO: BL31: cortex_a53: CPU workaround for erratum 1530924 was applied " Refer to the code comments mentioned below, there is no "erratum has no workaround in the CPU. Generic code must take care " https://gitenterprise.xilinx.com/Linux/arm-trusted-firmware/blob/master/lib… However, we found no handling in the generic code either. Can we be guided further regarding the handling of erratum 1530924 ? Regards, Maheedhar.

5 months, 1 week

2
2
0 0

Canceled event: TF-A Tech Forum @ Thu Dec 26, 2024 5pm - 6pm (GMT+1) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

This event has been canceled. TF-A Tech Forum Thursday Dec 26, 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 ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the 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

5 months, 3 weeks

1
0
0 0

Re: Query regarding the test coverage thru tf-a-tests

by Nagal, Amit

Hi , I am referring to the code coverage as below : https://ci-builds.trustedfirmware.org/static-files/htxSEy4sEOQXtuGetFtzHqAm… I see a lot of files from non plat code getting covered with code coverage . can somebody help me with further information : 1. Where are cputests related unit test scripts hosted for non plat files like bl31_main.c ? 2. can we use the unit test & code coverage infra for other platforms say AMD-Xilinx? 3. How is the code coverage achieved for assembly .S files like bl31_entrypoint.S ? Regards Amit From: Nagal, Amit Sent: Wednesday, December 11, 2024 1:23 PM To: Gyorgy Szing <Gyorgy.Szing(a)arm.com>; Mark Dykes <Mark.Dykes(a)arm.com>; Thangaraj, Senthil Nathan <SenthilNathan.Thangaraj(a)amd.com>; Olivier Deprez <Olivier.Deprez(a)arm.com>; tf-a-tests(a)lists.trustedfirmware.org; Joanna Farley <Joanna.Farley(a)arm.com> Cc: Jain, Ronak <ronak.jain(a)amd.com>; Simek, Michal <michal.simek(a)amd.com> Subject: RE: Query regarding the test coverage thru tf-a-tests Hi Everyone, I see very limited number of unit tests cpp files hosted at https://git.trustedfirmware.org/plugins/gitiles/TF-A/tf-a-unit-tests/+/refs… Do we have more unit tests implemented for TF-A and available publicly anywhere ? Regards Amit From: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>> Sent: Wednesday, November 20, 2024 2:44 PM To: Nagal, Amit <amit.nagal(a)amd.com<mailto:amit.nagal@amd.com>>; Mark Dykes <Mark.Dykes(a)arm.com<mailto:Mark.Dykes@arm.com>>; Thangaraj, Senthil Nathan <SenthilNathan.Thangaraj(a)amd.com<mailto:SenthilNathan.Thangaraj@amd.com>>; Olivier Deprez <Olivier.Deprez(a)arm.com<mailto:Olivier.Deprez@arm.com>>; tf-a-tests(a)lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org>; Joanna Farley <Joanna.Farley(a)arm.com<mailto:Joanna.Farley@arm.com>> Cc: Jain, Ronak <ronak.jain(a)amd.com<mailto:ronak.jain@amd.com>>; Simek, Michal <michal.simek(a)amd.com<mailto:michal.simek@amd.com>> Subject: Re: Query regarding the test coverage thru tf-a-tests Hi Amit, “can this be utilized to perform unit testing for platforms other than fvp” Unit-tests executables are running on the “build host” which often is the X86 based PC of the developer (or a CI worker). UT is favoring low cost and sacrificing some level of test correctness. It assumes the compiled C code is fully portable and works the same on all platforms. Moreover, it focuses on C function correctness, and checks if a specific function works as designed. Verifying higher level operation is out of scope (e.g. function implements any feature correctly or is behaving correctly when called by other functions in the system). In turn the complexity of embedded development is removed (managing the target, updating the firmware, using a JTAG interface for debugging, etc…), and the resource constraints of the embedded target is not present. The code coverage executed on the fvp platform is a system test, it exercises the product on an emulated target. It verifies the correctness of the code as it executes like it will in a real-world scenario. This is a higher value test, but it is much more expensive in terms of time and complexity than UT. “Is c-picker tool available inside arm still as of now ?” No, it is public, although it is a bit hidden. It lives on the c-picker branch to the Trusted Services repository (see [1) Similarly, Firmware Test Builder lives on the fwtb branch (see 2). This branch is independent of TS code and contains only the two tools. We have plans to move each to dedicated repositories, but I don’t know when I will have the time to do this. (FWTB and c-picker was developed by my team (TS) and is used and maintained by both projects. Before the TS project was started, we were working on TF-A. I can help with the tools, but I am not familiar to TF-A specifics like, how the tools are integrated to TF-A or which parts of TF-A are covered by UT cases.) 1: https://review.trustedfirmware.org/plugins/gitiles/TS/trusted-services/+/re… 2: https://review.trustedfirmware.org/plugins/gitiles/TS/trusted-services/+/re… /George On 2024-11-20, 06:05, "Nagal, Amit via TF-A-Tests" <tf-a-tests(a)lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org>> wrote: Hi Mark, From unit test prospective , I saw this document https://www.trustedfirmware.org/docs/TF-A-UnitLevelTesting.pdf. can this be utilized to perform unit testing for platforms other than fvp ? Is c-picker tool available inside arm still as of now ? Regards Amit From: Mark Dykes <Mark.Dykes(a)arm.com<mailto:Mark.Dykes@arm.com>> Sent: Tuesday, October 29, 2024 9:20 PM To: Nagal, Amit <amit.nagal(a)amd.com<mailto:amit.nagal@amd.com>>; Thangaraj, Senthil Nathan <SenthilNathan.Thangaraj(a)amd.com<mailto:SenthilNathan.Thangaraj@amd.com>>; Olivier Deprez <Olivier.Deprez(a)arm.com<mailto:Olivier.Deprez@arm.com>>; tf-a-tests(a)lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org>; Joanna Farley <Joanna.Farley(a)arm.com<mailto:Joanna.Farley@arm.com>> Cc: Jain, Ronak <ronak.jain(a)amd.com<mailto:ronak.jain@amd.com>>; Simek, Michal <michal.simek(a)amd.com<mailto:michal.simek@amd.com>> Subject: Re: Query regarding the test coverage thru tf-a-tests Amit, It appears I was incorrect in getting coverage outside of the flows we have internally. I apologize for the confusion... Mark ________________________________ From: Nagal, Amit <amit.nagal(a)amd.com<mailto:amit.nagal@amd.com<mailto:amit.nagal@amd.com%3cmailto:amit.nagal@amd.com>>> Sent: Friday, October 25, 2024 12:07 AM To: Thangaraj, Senthil Nathan <SenthilNathan.Thangaraj(a)amd.com<mailto:SenthilNathan.Thangaraj@amd.com<mailto:SenthilNathan.Thangaraj@amd.com%3cmailto:SenthilNathan.Thangaraj@amd.com>>>; Mark Dykes <Mark.Dykes(a)arm.com<mailto:Mark.Dykes@arm.com<mailto:Mark.Dykes@arm.com%3cmailto:Mark.Dykes@arm.com>>>; Olivier Deprez <Olivier.Deprez(a)arm.com<mailto:Olivier.Deprez@arm.com<mailto:Olivier.Deprez@arm.com%3cmailto:Olivier.Deprez@arm.com>>>; tf-a-tests(a)lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org%3cmailto:tf-a-tests@lists.trustedfirmware.org>> <tf-a-tests(a)lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org%3cmailto:tf-a-tests@lists.trustedfirmware.org>>>; Joanna Farley <Joanna.Farley(a)arm.com<mailto:Joanna.Farley@arm.com<mailto:Joanna.Farley@arm.com%3cmailto:Joanna.Farley@arm.com>>> Cc: Jain, Ronak <ronak.jain(a)amd.com<mailto:ronak.jain@amd.com<mailto:ronak.jain@amd.com%3cmailto:ronak.jain@amd.com>>>; Simek, Michal <michal.simek(a)amd.com<mailto:michal.simek@amd.com<mailto:michal.simek@amd.com%3cmailto:michal.simek@amd.com>>> Subject: RE: Query regarding the test coverage thru tf-a-tests Hi @Mark Dykes<mailto:Mark.Dykes@arm.com> , Can you please share insights about how to get coverage information using manual tests run for FVP platform . That will help us to atleast get the coverage information for non platform code ( we are interested for bl31) . Regards Amit From: Thangaraj, Senthil Nathan <SenthilNathan.Thangaraj(a)amd.com<mailto:SenthilNathan.Thangaraj@amd.com<mailto:SenthilNathan.Thangaraj@amd.com%3cmailto:SenthilNathan.Thangaraj@amd.com>>> Sent: Tuesday, September 10, 2024 12:23 AM To: Mark Dykes <Mark.Dykes(a)arm.com<mailto:Mark.Dykes@arm.com<mailto:Mark.Dykes@arm.com%3cmailto:Mark.Dykes@arm.com>>>; Olivier Deprez <Olivier.Deprez(a)arm.com<mailto:Olivier.Deprez@arm.com<mailto:Olivier.Deprez@arm.com%3cmailto:Olivier.Deprez@arm.com>>>; tf-a-tests(a)lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org%3cmailto:tf-a-tests@lists.trustedfirmware.org>>; joanna.farley(a)arm.com<mailto:joanna.farley@arm.com<mailto:joanna.farley@arm.com%3cmailto:joanna.farley@arm.com>> Cc: Jain, Ronak <ronak.jain(a)amd.com<mailto:ronak.jain@amd.com<mailto:ronak.jain@amd.com%3cmailto:ronak.jain@amd.com>>>; Nagal, Amit <amit.nagal(a)amd.com<mailto:amit.nagal@amd.com<mailto:amit.nagal@amd.com%3cmailto:amit.nagal@amd.com>>>; Simek, Michal <michal.simek(a)amd.com<mailto:michal.simek@amd.com<mailto:michal.simek@amd.com%3cmailto:michal.simek@amd.com>>> Subject: RE: Query regarding the test coverage thru tf-a-tests Thank you Joanna and Mark, for your insights and response. I wasn’t aware that these tests are running on a Virtual Platform and that’s how the coverage is being measured. I’ll look into this further, decide how we want to integrate it into our project, and get back to you. I appreciate your help and support here. Best regards, Senthil From: Mark Dykes <Mark.Dykes(a)arm.com<mailto:Mark.Dykes@arm.com<mailto:Mark.Dykes@arm.com%3cmailto:Mark.Dykes@arm.com>>> Sent: Wednesday, August 28, 2024 9:03 AM To: Olivier Deprez <Olivier.Deprez(a)arm.com<mailto:Olivier.Deprez@arm.com<mailto:Olivier.Deprez@arm.com%3cmailto:Olivier.Deprez@arm.com>>>; tf-a-tests(a)lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org%3cmailto:tf-a-tests@lists.trustedfirmware.org>>; Thangaraj, Senthil Nathan <SenthilNathan.Thangaraj(a)amd.com<mailto:SenthilNathan.Thangaraj@amd.com<mailto:SenthilNathan.Thangaraj@amd.com%3cmailto:SenthilNathan.Thangaraj@amd.com>>> Cc: Jain, Ronak <ronak.jain(a)amd.com<mailto:ronak.jain@amd.com<mailto:ronak.jain@amd.com%3cmailto:ronak.jain@amd.com>>>; Nagal, Amit <amit.nagal(a)amd.com<mailto:amit.nagal@amd.com<mailto:amit.nagal@amd.com%3cmailto:amit.nagal@amd.com>>>; Simek, Michal <michal.simek(a)amd.com<mailto:michal.simek@amd.com<mailto:michal.simek@amd.com%3cmailto:michal.simek@amd.com>>> Subject: RE: Query regarding the test coverage thru tf-a-tests Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding. Senthil, I do have a way to get coverage for manual test runs using FVP if that helps. I can assist if needed…. Mark From: Olivier Deprez <Olivier.Deprez(a)arm.com<mailto:Olivier.Deprez@arm.com<mailto:Olivier.Deprez@arm.com%3cmailto:Olivier.Deprez@arm.com>>> Sent: Wednesday, August 28, 2024 12:53 AM To: Mark Dykes <Mark.Dykes(a)arm.com<mailto:Mark.Dykes@arm.com<mailto:Mark.Dykes@arm.com%3cmailto:Mark.Dykes@arm.com>>>; tf-a-tests(a)lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org%3cmailto:tf-a-tests@lists.trustedfirmware.org>>; Thangaraj, Senthil Nathan <SenthilNathan.Thangaraj(a)amd.com<mailto:SenthilNathan.Thangaraj@amd.com<mailto:SenthilNathan.Thangaraj@amd.com%3cmailto:SenthilNathan.Thangaraj@amd.com>>> Cc: Jain, Ronak <ronak.jain(a)amd.com<mailto:ronak.jain@amd.com<mailto:ronak.jain@amd.com%3cmailto:ronak.jain@amd.com>>>; Nagal, Amit <amit.nagal(a)amd.com<mailto:amit.nagal@amd.com<mailto:amit.nagal@amd.com%3cmailto:amit.nagal@amd.com>>>; Simek, Michal <michal.simek(a)amd.com<mailto:michal.simek@amd.com<mailto:michal.simek@amd.com%3cmailto:michal.simek@amd.com>>> Subject: Re: Query regarding the test coverage thru tf-a-tests Hi Senthil, * Is there a way to get code coverage for manual test runs? Sorry, I'm not aware of such capability. As you say code coverage implies use of CI scripting that isn't possible to reproduce locally out of the box (afaik). Regards, Olivier. ________________________________ From: Thangaraj, Senthil Nathan via TF-A-Tests <tf-a-tests(a)lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org%3cmailto:tf-a-tests@lists.trustedfirmware.org>>> Sent: 26 August 2024 23:58 To: Mark Dykes <Mark.Dykes(a)arm.com<mailto:Mark.Dykes@arm.com<mailto:Mark.Dykes@arm.com%3cmailto:Mark.Dykes@arm.com>>>; Olivier Deprez <Olivier.Deprez(a)arm.com<mailto:Olivier.Deprez@arm.com<mailto:Olivier.Deprez@arm.com%3cmailto:Olivier.Deprez@arm.com>>>; tf-a-tests(a)lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org%3cmailto:tf-a-tests@lists.trustedfirmware.org>> <tf-a-tests(a)lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org%3cmailto:tf-a-tests@lists.trustedfirmware.org>>> Cc: Jain, Ronak <ronak.jain(a)amd.com<mailto:ronak.jain@amd.com<mailto:ronak.jain@amd.com%3cmailto:ronak.jain@amd.com>>>; Nagal, Amit <amit.nagal(a)amd.com<mailto:amit.nagal@amd.com<mailto:amit.nagal@amd.com%3cmailto:amit.nagal@amd.com>>>; Simek, Michal <michal.simek(a)amd.com<mailto:michal.simek@amd.com<mailto:michal.simek@amd.com%3cmailto:michal.simek@amd.com>>> Subject: [Tf-a-tests] Re: Query regarding the test coverage thru tf-a-tests Hi Mark and Oliver, A gentle reminder on the below request. Thanks, Senthil From: Thangaraj, Senthil Nathan Sent: Tuesday, August 20, 2024 3:44 PM To: Mark Dykes <Mark.Dykes(a)arm.com<mailto:Mark.Dykes@arm.com<mailto:Mark.Dykes@arm.com%3cmailto:Mark.Dykes@arm.com>>>; Olivier Deprez <Olivier.Deprez(a)arm.com<mailto:Olivier.Deprez@arm.com<mailto:Olivier.Deprez@arm.com%3cmailto:Olivier.Deprez@arm.com>>>; tf-a-tests(a)lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org%3cmailto:tf-a-tests@lists.trustedfirmware.org>> Cc: Jain, Ronak <ronak.jain(a)amd.com<mailto:ronak.jain@amd.com<mailto:ronak.jain@amd.com%3cmailto:ronak.jain@amd.com>>>; Nagal, Amit <amit.nagal(a)amd.com<mailto:amit.nagal@amd.com<mailto:amit.nagal@amd.com%3cmailto:amit.nagal@amd.com>>>; Simek, Michal <michal.simek(a)amd.com<mailto:michal.simek@amd.com<mailto:michal.simek@amd.com%3cmailto:michal.simek@amd.com>>> Subject: RE: Query regarding the test coverage thru tf-a-tests Thanks a lot Mark and Oliver for your inputs and pointers. All of these seem to be more closely integrated with the CI/CD builds. Is there a way to get code coverage for manual test runs? Specifically, I'm looking to get coverage results after loading and executing all the tests from a developer build (e.g., using a binary like tftf.bin). Best regards, Senthil From: Mark Dykes <Mark.Dykes(a)arm.com<mailto:Mark.Dykes@arm.com<mailto:Mark.Dykes@arm.com%3cmailto:Mark.Dykes@arm.com<mailto:Mark.Dykes@arm.com%3cmailto:Mark.Dykes@arm.com%3cmailto:Mark.Dykes@arm.com%3cmailto:Mark.Dykes@arm.com>>>> Sent: Tuesday, August 20, 2024 3:16 PM To: Olivier Deprez <Olivier.Deprez(a)arm.com<mailto:Olivier.Deprez@arm.com<mailto:Olivier.Deprez@arm.com%3cmailto:Olivier.Deprez@arm.com<mailto:Olivier.Deprez@arm.com%3cmailto:Olivier.Deprez@arm.com%3cmailto:Olivier.Deprez@arm.com%3cmailto:Olivier.Deprez@arm.com>>>>; tf-a-tests(a)lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org%3cmailto:tf-a-tests@lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org%3cmailto:tf-a-tests@lists.trustedfirmware.org%3cmailto:tf-a-tests@lists.trustedfirmware.org%3cmailto:tf-a-tests@lists.trustedfirmware.org>>>; Thangaraj, Senthil Nathan <SenthilNathan.Thangaraj(a)amd.com<mailto:SenthilNathan.Thangaraj@amd.com<mailto:SenthilNathan.Thangaraj@amd.com%3cmailto:SenthilNathan.Thangaraj@amd.com<mailto:SenthilNathan.Thangaraj@amd.com%3cmailto:SenthilNathan.Thangaraj@amd.com%3cmailto:SenthilNathan.Thangaraj@amd.com%3cmailto:SenthilNathan.Thangaraj@amd.com>>>> Subject: RE: Query regarding the test coverage thru tf-a-tests Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding. All, This link is more current. The overall coverage numbers are not being reported due to an issue that is being worked on now. However you can see the individual coverage metrics if you click on a particular config where is says "success". The next page will have the link "Build Artifacts" at the top and so click that to the next where you will see the directory "trace_report". Click this and you will see a list of contents one of which should be index.html. If you click this you will see the individual coverage report for that config(test). tf-a-ci-coverage-gateway #72 [Jenkins] (trustedfirmware.org)<https://ci.trustedfirmware.org/job/tf-a-ci-coverage-gateway/72/> Let me know if you have questions... Mark From: Olivier Deprez <Olivier.Deprez(a)arm.com<mailto:Olivier.Deprez@arm.com<mailto:Olivier.Deprez@arm.com%3cmailto:Olivier.Deprez@arm.com<mailto:Olivier.Deprez@arm.com%3cmailto:Olivier.Deprez@arm.com%3cmailto:Olivier.Deprez@arm.com%3cmailto:Olivier.Deprez@arm.com>>>> Sent: Tuesday, August 20, 2024 2:27 AM To: tf-a-tests(a)lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org%3cmailto:tf-a-tests@lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org%3cmailto:tf-a-tests@lists.trustedfirmware.org%3cmailto:tf-a-tests@lists.trustedfirmware.org%3cmailto:tf-a-tests@lists.trustedfirmware.org>>>; Thangaraj, Senthil Nathan <SenthilNathan.Thangaraj(a)amd.com<mailto:SenthilNathan.Thangaraj@amd.com<mailto:SenthilNathan.Thangaraj@amd.com%3cmailto:SenthilNathan.Thangaraj@amd.com<mailto:SenthilNathan.Thangaraj@amd.com%3cmailto:SenthilNathan.Thangaraj@amd.com%3cmailto:SenthilNathan.Thangaraj@amd.com%3cmailto:SenthilNathan.Thangaraj@amd.com>>>>; Mark Dykes <Mark.Dykes(a)arm.com<mailto:Mark.Dykes@arm.com<mailto:Mark.Dykes@arm.com%3cmailto:Mark.Dykes@arm.com<mailto:Mark.Dykes@arm.com%3cmailto:Mark.Dykes@arm.com%3cmailto:Mark.Dykes@arm.com%3cmailto:Mark.Dykes@arm.com>>>> Subject: Re: Query regarding the test coverage thru tf-a-tests Hi, You can refer to this job showing code coverage results aggregation from multiple test configurations: https://ci.trustedfirmware.org/job/tf-a-ci-coverage-gateway/67/ https://ci-builds.trustedfirmware.org/static-files/IK1tucCNXFdhS4AAQth8N7zW… I don't think there is a test level granularity. @Mark Dykes<mailto:Mark.Dykes@arm.com> may know better. Regards, Olivier. ________________________________ From: Thangaraj, Senthil Nathan via TF-A-Tests <tf-a-tests(a)lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org%3cmailto:tf-a-tests@lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org%3cmailto:tf-a-tests@lists.trustedfirmware.org%3cmailto:tf-a-tests@lists.trustedfirmware.org%3cmailto:tf-a-tests@lists.trustedfirmware.org>>>> Sent: 20 August 2024 08:40 To: tf-a-tests(a)lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org%3cmailto:tf-a-tests@lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org%3cmailto:tf-a-tests@lists.trustedfirmware.org%3cmailto:tf-a-tests@lists.trustedfirmware.org%3cmailto:tf-a-tests@lists.trustedfirmware.org>>> <tf-a-tests(a)lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org%3cmailto:tf-a-tests@lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org%3cmailto:tf-a-tests@lists.trustedfirmware.org%3cmailto:tf-a-tests@lists.trustedfirmware.org%3cmailto:tf-a-tests@lists.trustedfirmware.org>>>> Subject: [Tf-a-tests] Query regarding the test coverage thru tf-a-tests Dear TF-A team, I have a query regarding the TF-A test. Specifically, I would like to know if there is a method to find out the code coverage for a specific test or for all the tests in current run? Your direction in this regard will be really appreciated. Thank you, Senthil -- TF-A-Tests mailing list -- tf-a-tests(a)lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org%3cmailto:tf-a-tests@lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org%3cmailto:tf-a-tests@lists.trustedfirmware.org%3cmailto:tf-a-tests@lists.trustedfirmware.org%3cmailto:tf-a-tests@lists.trustedfirmware.org>>> To unsubscribe send an email to tf-a-tests-leave(a)lists.trustedfirmware.org<mailto:tf-a-tests-leave@lists.trustedfirmware.org<mailto:tf-a-tests-leave@lists.trustedfirmware.org%3cmailto:tf-a-tests-leave@lists.trustedfirmware.org<mailto:tf-a-tests-leave@lists.trustedfirmware.org%3cmailto:tf-a-tests-leave@lists.trustedfirmware.org%3cmailto:tf-a-tests-leave@lists.trustedfirmware.org%3cmailto:tf-a-tests-leave@lists.trustedfirmware.org>>> -- TF-A-Tests mailing list -- tf-a-tests(a)lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org%3cmailto:tf-a-tests@lists.trustedfirmware.org>> To unsubscribe send an email to tf-a-tests-leave(a)lists.trustedfirmware.org<mailto:tf-a-tests-leave@lists.trustedfirmware.org<mailto:tf-a-tests-leave@lists.trustedfirmware.org%3cmailto:tf-a-tests-leave@lists.trustedfirmware.org>> -- TF-A-Tests mailing list -- tf-a-tests(a)lists.trustedfirmware.org<mailto:tf-a-tests@lists.trustedfirmware.org> To unsubscribe send an email to tf-a-tests-leave(a)lists.trustedfirmware.org<mailto:tf-a-tests-leave@lists.trustedfirmware.org>

5 months, 3 weeks

2
4
0 0

Canceled event with note: TF-A Tech Forum @ Thu Dec 12, 2024 5pm - 6pm (GMT+1) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

This event has been canceled with a note: "Hi, Cancelling as no topic proposed. Regards, Olivier. " TF-A Tech Forum Thursday Dec 12, 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 ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the 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

6 months

1
0
0 0

Unable to merge gerrit#33536

by Amarinder Singh Sethi (QUIC)

Hi, I recently uploaded the patch (https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/33536) to add qti platform support for qcs615. The patch is fully isolated and doesn't touch any common code and doesn't get included in any other platform compilation. On enabling basic CI, I see some failures which are unrelated to my patch. I wonder what the next step should be. If somebody can help me, it will be greatly appreciated. Thanks Amarinder

6 months

2
2
0 0

Trusted Firmware-A LTS v2.8.26 Release Announcement

by ci_notify＠trustedfirmware.org

Hello, Trusted Firmware-A LTS version 2.8.26 is now available. This release contains the following patches: a449c1360 build(npm): bump word-wrap from 1.2.3 to 1.2.4 [1] ceb400895 build(npm): update Node.js and all packages [2] 0abe5d571 build(deps): bump braces [3] 3de9d3abd chore(deps): bump micromatch [4] [1] https://review.trustedfirmware.org/q/I9a383e6d6ae907858028980eadccfa2070f42… [2] https://review.trustedfirmware.org/q/[1, "always", "Change-Id:"], /* Warning */ [3] https://review.trustedfirmware.org/q/I7e2a543a3bc67d426a69fc25f93b878c9b5a3… [4] https://review.trustedfirmware.org/q/I783a6838616c570a41a5a0f58db3e6430c43c… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.8.26/change-log.html Thanks, TF-A LTS team

6 months, 1 week

1
0
0 0

Trusted Firmware-A LTS v2.10.10 Release Announcement

by ci_notify＠trustedfirmware.org

Hello, Trusted Firmware-A LTS version 2.10.10 is now available. This release contains the following patches: 3ea256c36 build(deps): bump pip from 23.1.2 to 23.3 [1] f8a06a0f8 build(deps): bump urllib3 from 2.0.2 to 2.2.2 [2] 93ad43e79 build(deps): bump jinja2 from 3.1.2 to 3.1.4 [3] ebf6430a0 build(deps): bump idna from 3.4 to 3.7 [4] c5d2a030a build(deps): bump braces [5] 6c6e986bf build(npm): update Node.js and all packages [6] 395ef3534 chore(deps): bump micromatch [7] c9f3fb582 build(deps): bump setuptools in the pip group across 1 directory [8] [1] https://review.trustedfirmware.org/q/I40b0219fe5e6797fc2a2534d8ea8c9480af36… [2] https://review.trustedfirmware.org/q/I4f3a1ffe0cf374f433ac59b20b7d60ee77009… [3] https://review.trustedfirmware.org/q/I69248b2c17f8edfe7dfd27952aae688e7d424… [4] https://review.trustedfirmware.org/q/I78f5052e20572d92f1bc21213bb29b5549f34… [5] https://review.trustedfirmware.org/q/I7e2a543a3bc67d426a69fc25f93b878c9b5a3… [6] https://review.trustedfirmware.org/q/[1, "always", "Change-Id:"], /* Warning */ [7] https://review.trustedfirmware.org/q/I783a6838616c570a41a5a0f58db3e6430c43c… [8] https://review.trustedfirmware.org/q/Ibd4e4730bfc5cce8d85ec55021983d6f748ff… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.10.10/change-log.html Thanks, TF-A LTS team

6 months, 1 week

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/

6 months, 1 week

1
0
0 0

Re: Interaction with TF-a from NS World

by Tamas Ban

Hi Max, > Can we say this presentation (2022) is there and ready to use? Yes, there are multiple measured boot and attestation schemes are implemented in TF-A and Trusted Services. What to use is depends on your use case and your system capability: - A class core only - A+M system where the M core is in a secure enclave > By the way, you mentioned that attestation is not handled in TF-a (EL3), but the below EL3 handler handles it (RMM_ATTEST_GET_PLAT_TOKEN). Does it just send the request to the "Trusted Service" you were referencing? No, they are different. The available options/schemes: * -If you have a single A class core and you want something similar to psa_initial_attest_get_token() then read this: https://trusted-services.readthedocs.io/en/latest/services/attest-service-d… Here the token is created by a secure service running in SEL0/1. EL3 only responsible for making the world switch (S<->NS). This is callable from Linux user space, with the libs and kernel driver pointed out by George. * What you mentioned above (RMM_ATTEST_GET_PLAT_TOKEN) is basically the CCA attestation scheme, where there are two halves tokens. It is targeting the RME capable systems which otherwise have A+M cores. One half of the token is produced by the M class secure enclave(HES) the other half by the RMM running in REL2 on the A core. There is a hash link between the half tokens. Please elaborate your use case then I can help more! Regards, Tamas From: Gyorgy Szing <Gyorgy.Szing(a)arm.com> Sent: Monday, December 2, 2024 11:43 AM To: Max Adam <maxadamcamb(a)gmail.com>; Tamas Ban <Tamas.Ban(a)arm.com> Subject: Re: [TF-A] Interaction with TF-a from NS World Hi, "By the way, you mentioned that attestation is not handled in TF-a (EL3)," Sorry, my bad. Since you mentioned PSA I got the impression you are after PSA Initial Attestation, and that is out of scope for TF-A. Tamas: Can you please respond to the RMM related attestation question? /George On 2024-12-02, 11:38, "Max Adam" <maxadamcamb(a)gmail.com<mailto:maxadamcamb@gmail.com>> wrote: Hi Gyorgy, Thank you for the detailed comment. It is really helpful, especially this link seems good to chase: https://git.yoctoproject.org/meta-arm/about/documentation/trusted-services.… Basically, I was following this link from @Tamas.ban@arm.com<mailto:Tamas.ban@arm.com>; "CCA attestation and measured both" https://www.trustedfirmware.org/docs/Attestation_and_Measured_Boot.pdf Can we say this presentation (2022) is there and ready to use? By the way, you mentioned that attestation is not handled in TF-a (EL3), but the below EL3 handler handles it (RMM_ATTEST_GET_PLAT_TOKEN). Does it just send the request to the "Trusted Service" you were referencing? Error! Filename not specified. Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>>, 2 Ara 2024 Pzt, 09:29 tarihinde şunu yazdı: Hi Max, Please check this picture [1]. It shows the exception levels on an aarch64 platforms, and typical components executing at each exception level. TF-A is a Secure Monitor implementation. It is the most privileged component, and its main goal is to route calls between the NWd and SWd. Each call to SWd must go through this component. E.g. if an "aarch64 App" wishes to use a service provided by a Trusted Service, a call has to be made into EL1 (e.g. Linux Kernel), then if a Hypervisor is present to EL2, then to the Monitor at EL3 (TF-A), then to optional S-EL2 (e.g. Hafnium), S-EL1 (e.g. OP_TEE) and finally to S-EL0. TF-A does not implement the PSA APIs. OP-TEE is a Trusted OS, and a reference implementation of the Global Platforms standards [2]. PSA is not part of GP, and AFAIK there is no TA implementing PSA APIs. The PSA reference implementation for Cortex-A is developed in the Trusted Services project. The project implements all services required for PSA certification (Crypto, ITS, PS, Attestation) plus a few non-psa ones like Firmware Update Service or UEFI Variable service. We developed a Linux kernel driver called tstee (up-stream since v6.10) , and two shared libraries which can be used by linux user-space applications to access the services. Libts implements service discovery and the TS RPC components, and "libtspsa" carries easy to use PSA client implementations (basically the C PSA API). Trusted Services follows the Firmware Framework for A-Profile standard (FF-A) which defines a protocol to be used between exception levels and a runtime model. PSA services are deployed to S-EL0 Secure Partitions and need a Secure Partition Manager implementation executing at a higher exception levels. The reference SPMD implementation is part of the TF-A project, the S-EL2 reference SPMC is Hafnium [5], and the S-EL1 reference implementation is OP-TEE SPMC [6]. (Only one SPMC implementation can be present on a system.) A major difference between the Cortex-M and the Cortex-A ecosystem is the level of diversity. While a Cortex-M stack is typically implemented using components from one or maximum a few stakeholders, a Cortex-A stack is built from components owned by a vast set of owners. As a result, integration of a Cortex-A software stack is much more complex. There are multiple integration systems targeting the problem like Buildroot and Yocto. Trusted Services supports two integration systems currently. The OP-TEE integration system, which is a gnumake and Buildroot based solution (see [7]) and Yocto where the meta-arm layer [8] hosts TS recipes. Please find some TS specific meta-arm documentation here: [9] For more help and information, about PSA on Cortex-A and TS feel free to drop an email to the TS mailing list [10], and/or to me. /George 1: https://documentation-service.arm.com/static/63a065c41d698c4dc521cb1b 2: https://globalplatform.org/about-globalplatform/ 3: https://trusted-services.readthedocs.io/en/stable/overview/index.html 4: https://developer.arm.com/architectures/Firmware%20Framework%20for%20A-Prof… 5: https://hafnium.readthedocs.io/en/latest/secure-partition-manager/index.html 6: https://optee.readthedocs.io/en/latest/architecture/spmc.html 7: https://github.com/OP-TEE/build 8: https://git.yoctoproject.org/meta-arm 9: https://git.yoctoproject.org/meta-arm/about/documentation/trusted-services.… 10: https://lists.trustedfirmware.org/mailman3/lists/trusted-services.lists.tru… On 2024-12-01, 21:14, "Max Adam via TF-A" <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> wrote: Hello All, I am coming from the TF-m domain, and now I am struggling with TF-a as I am not a Linux expert. I am just looking for the interactions with TF-a, such as getting psa attestation token etc. How can I find example these interactions from NS World (Linux) or lower privilege Secure World Executions such as OP-TEE or OP-TEE TAs? I suppose there shall be drivers and APIs provided by TF-a? Thanks Max

6 months, 1 week

3
3
0 0

Interaction with TF-a from NS World

by Max Adam

Hello All, I am coming from the TF-m domain, and now I am struggling with TF-a as I am not a Linux expert. I am just looking for the interactions with TF-a, such as getting psa attestation token etc. How can I find example these interactions from NS World (Linux) or lower privilege Secure World Executions such as OP-TEE or OP-TEE TAs? I suppose there shall be drivers and APIs provided by TF-a? Thanks Max

6 months, 1 week

2
1
0 0

Addition of mbedTLS as a submodule dependency to TF-A-Tests

by Soby Mathew

Hi Everyone, In order to facilitate development for Device Assignment tests for RME-DA, we have added MbedTLS repo as a submodule dependency to tf-a-tests. The merge commit can be found here : https://review.trustedfirmware.org/plugins/gitiles/TF-A/tf-a-tests/+/3e72cd… The patch is done in such a way that existing build of TF-A-Tests or Test run is not affected due to the additional dependency. Only tests which depend on MbedTLS will be affected in that they will either be skipped or fail at runtime due to the missing dependency. Also, the change allows to use the config `MBEDTLS_DIR` to point to a MbedTLS directory outside the tf-a-tests source tree. This aligns with the TF-A mechanism for MbedTLS dependancy in case the submodule mechanism is not preferred. We expect existing CI and testing infrastructure to be unaffected by this change. Please let us know if you have any comments. Best Regards Soby Mathew

6 months, 2 weeks

1
0
0 0

Trusted Firmware-A LTS v2.8.25 Release Announcement

by ci_notify＠trustedfirmware.org

Hello, Trusted Firmware-A LTS version 2.8.25 is now available. This release contains the following patches: 3e1ecab9a build(deps): bump pip from 23.1.2 to 23.3 [1] 73421e1df build(deps): bump urllib3 from 2.0.2 to 2.2.2 [2] b607e5481 build(deps): bump jinja2 from 3.1.2 to 3.1.4 [3] 720d7ea22 build(deps): bump idna from 3.4 to 3.7 [4] [1] https://review.trustedfirmware.org/q/I40b0219fe5e6797fc2a2534d8ea8c9480af36… [2] https://review.trustedfirmware.org/q/I4f3a1ffe0cf374f433ac59b20b7d60ee77009… [3] https://review.trustedfirmware.org/q/I69248b2c17f8edfe7dfd27952aae688e7d424… [4] https://review.trustedfirmware.org/q/I78f5052e20572d92f1bc21213bb29b5549f34… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.8.25/change-log.html Thanks, TF-A LTS team

6 months, 2 weeks

1
0
0 0

Canceled event: TF-A Tech Forum @ Thu Nov 28, 2024 5pm - 6pm (GMT+1) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

This event has been canceled. TF-A Tech Forum Thursday Nov 28, 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 ~~//~~ 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

6 months, 2 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.

6 months, 3 weeks

1
0
0 0

Changelog for v2.12 Release

by Govindraj Raja

Hello Everyone, Please take a look at the changelog for your respective platforms ahead of the TF-A v2.12 release. The changelog is autogenerated from the commit messages of the patches that have been merged since the v2.11 release. Here's your chance to give us guidance on any small manual adjustments you would like to see. Patch: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/33483 Rendered Version: https://ci-builds.trustedfirmware.org/static-files/pAvWwn44kBOyAVI04_7T9WjV… -- Thanks, Govindraj R

7 months

1
0
0 0

Canceled event: TF-A Tech Forum @ Thu Nov 14, 2024 5pm - 6pm (GMT+1) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

This event has been canceled. TF-A Tech Forum Thursday Nov 14, 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 ~~//~~ 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

7 months

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

7 months

1
1
0 0

Reference Secure Partition Code with FF-A

by Belsare, Akshay

Hello everyone, I'm seeking a reference code for a Standalone Secure Partition using FF-A. Any guidance or suggestions would be greatly appreciated! TIA, Akshay

7 months, 1 week

3
2
0 0

TF-A: Compilation issues for Rockchip platforms

by Quentin Schulz

Hi all, I've sent a few patches for fixing some compilation warnings or issues on Rockchip platforms [1][2][3][4][5] but I'm left with a few still... [1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/33080 [2] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/33081 [3] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/33082 [4] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/33083 [5] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/33084 1) RK3588 symbol redefinition in assembly ======================================================================== commit fc3b98b2124c2b773322da0201e9ad7a697e6323 Author: Quentin Schulz <quentin.schulz(a)cherry.de> Date: Mon Oct 28 12:40:18 2024 +0100 fix(rk3588): pmu: fix assembly symbol redefinition Somehow cpus_pd_req_enter_wfi() gets called multiple times and clang isn't happy about redefining the same label multiple times (it is an inline function). An option could be to force the code to not be inlined (with __attribute__((noinline))) as removing the explicit inline still made the compiler inline the code. Recreate the while loop without a label to fix the clang build issue: plat/rockchip/rk3588/drivers/pmu/pmu.c:763:7: error: symbol 'wfi_loop' is already defined 763 | "wfi_loop:\n" | ^ <inline asm>:5:1: note: instantiated into assembly here 5 | wfi_loop: | ^ Signed-off-by: Quentin Schulz <quentin.schulz(a)cherry.de> Change-Id: Ie9f55135b2f95a78deb7cbb94f9a62d3ba61e808 diff --git a/plat/rockchip/rk3588/drivers/pmu/pmu.c b/plat/rockchip/rk3588/drivers/pmu/pmu.c index f693dbdf0..f05d3e58f 100644 --- a/plat/rockchip/rk3588/drivers/pmu/pmu.c +++ b/plat/rockchip/rk3588/drivers/pmu/pmu.c @@ -760,10 +760,10 @@ static inline void cpus_pd_req_enter_wfi(void) "mrs x0, S3_0_C15_C2_7\n" "orr x0, x0, #0x1\n" "msr S3_0_C15_C2_7, x0\n" - "wfi_loop:\n" + "ldr x0, .+4\n" "isb\n" "wfi\n" - "b wfi_loop\n"); + "br x0\n"); } static void nonboot_cpus_off(void) ========================================================================= This only happens for clang and I'm a bit confused as to why. Applying the above patch fixing that issue but inspecting the assembly code reveals something really odd. **With** that patch, with gcc: 25c8c: d510149f msr dbgprcr_el1, xzr 25c90: d538f2e0 mrs x0, s3_0_c15_c2_7 25c94: b2400000 orr x0, x0, #0x1 25c98: d518f2e0 msr s3_0_c15_c2_7, x0 25c9c: 58000020 ldr x0, 0x25ca0 25ca0: d5033fdf isb 25ca4: d503207f wfi 25ca8: d61f0000 br x0 **with** that patch, with clang: 26d2c: d510149f msr dbgprcr_el1, xzr 26d30: d538f2e0 mrs x0, s3_0_c15_c2_7 26d34: b2400000 orr x0, x0, #0x1 26d38: d518f2e0 msr s3_0_c15_c2_7, x0 26d3c: 58000020 ldr x0, 0x26d40 <--- "my" ldr 26d40: d5033fdf isb 26d44: d503207f wfi 26d48: d61f0000 br x0 <--- "my" br 26d4c: 94000e76 bl 0x2a724 26d50: d510149f msr dbgprcr_el1, xzr 26d54: d538f2e0 mrs x0, s3_0_c15_c2_7 26d58: b2400000 orr x0, x0, #0x1 26d5c: d518f2e0 msr s3_0_c15_c2_7, x0 26d60: 58000020 ldr x0, 0x26d64 <--- "my" ldr 26d64: d5033fdf isb 26d68: d503207f wfi 26d6c: d61f0000 br x0 <--- "my" br So I think the above patch is just a band-aid on what the actually is but I have no idea what could be going on. If I use this patch instead, to match the other assembly instructions in this file ========================================================================= diff --git a/plat/rockchip/rk3588/drivers/pmu/pmu.c b/plat/rockchip/rk3588/drivers/pmu/pmu.c index f693dbdf0..a4128b214 100644 --- a/plat/rockchip/rk3588/drivers/pmu/pmu.c +++ b/plat/rockchip/rk3588/drivers/pmu/pmu.c @@ -760,10 +760,10 @@ static inline void cpus_pd_req_enter_wfi(void) "mrs x0, S3_0_C15_C2_7\n" "orr x0, x0, #0x1\n" "msr S3_0_C15_C2_7, x0\n" - "wfi_loop:\n" + "1:\n" "isb\n" "wfi\n" - "b wfi_loop\n"); + "b 1b\n"); } static void nonboot_cpus_off(void) ========================================================================= It happily compiles, though the binary still seems to contain this loop twice. Using __attribute__((noinline)) the code is not duplicated, but I assume this is expected as it would now simply be a function. 2) RK3399 warning array subscript 0 is outside array bounds of 'volatile unsigned int[0]' [-Warray-bounds=] """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" In file included from src/dram.c:12: src/dram.c: In function 'm0_main': include/rk3399_mcu.h:15:34: warning: array subscript 0 is outside array bounds of 'volatile unsigned int[0]' [-Warray-bounds=] 15 | (*(volatile unsigned int *)(c)); __v; }) | ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ include/rk3399_mcu.h:16:69: note: in definition of macro 'mmio_write_32' 16 | #define mmio_write_32(c, v) ((*(volatile unsigned int *)(c)) = (v)) | ^ src/dram.c:67:23: note: in expansion of macro 'mmio_read_32' 67 | mmio_read_32(PARAM_ADDR + PARAM_FREQ_SELECT)); | ^~~~~~~~~~~~ cc1: note: source object is likely at address zero In function 'ddr_set_pll', inlined from 'm0_main' at src/dram.c:71:2: include/rk3399_mcu.h:14:40: warning: array subscript 0 is outside array bounds of 'volatile unsigned int[0]' [-Warray-bounds=] 14 | #define mmio_read_32(c) ({unsigned int __v = \ | ^~~ include/rk3399_mcu.h:16:69: note: in definition of macro 'mmio_write_32' 16 | #define mmio_write_32(c, v) ((*(volatile unsigned int *)(c)) = (v)) | ^ src/dram.c:47:23: note: in expansion of macro 'mmio_read_32' 47 | mmio_read_32(PARAM_ADDR + PARAM_DPLL_CON0)); | ^~~~~~~~~~~~ In function 'm0_main': cc1: note: source object is likely at address zero In function 'ddr_set_pll', inlined from 'm0_main' at src/dram.c:71:2: include/rk3399_mcu.h:14:40: warning: array subscript 0 is outside array bounds of 'volatile unsigned int[0]' [-Warray-bounds=] 14 | #define mmio_read_32(c) ({unsigned int __v = \ | ^~~ include/rk3399_mcu.h:16:69: note: in definition of macro 'mmio_write_32' 16 | #define mmio_write_32(c, v) ((*(volatile unsigned int *)(c)) = (v)) | ^ src/dram.c:49:23: note: in expansion of macro 'mmio_read_32' 49 | mmio_read_32(PARAM_ADDR + PARAM_DPLL_CON1)); | ^~~~~~~~~~~~ In function 'm0_main': cc1: note: source object is likely at address zero include/rk3399_mcu.h:16:35: warning: array subscript 0 is outside array bounds of 'volatile unsigned int[0]' [-Warray-bounds=] 16 | #define mmio_write_32(c, v) ((*(volatile unsigned int *)(c)) = (v)) | ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ src/dram.c:80:9: note: in expansion of macro 'mmio_write_32' 80 | mmio_write_32(PARAM_ADDR + PARAM_M0_DONE, M0_DONE_FLAG); | ^~~~~~~~~~~~~ cc1: note: source object is likely at address zero """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" This function is used in many places, but only in very specific places is it triggering a warning, when PARAM_ADDR is used, but only when accessed from m0 C files. PARAM_ADDR is set to 0xc0. From !m0 files, access to PARAM_ADDR seems to be done through the M0_PARAM_ADDR which is M0_BINCODE_BASE + PARAM_ADDR. For m0 files, it's directly accessing PARAM_ADDR. I honestly don't really know why it's complaining for m0 files but not the !m0 ones. 3) RK3399 expected string in '.incbin' directive This is only for clang. """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" <instantiation>:6:10: error: expected string in '.incbin' directive .incbin /home/qschulz/work/upstream/trusted-firmware-a/build/rk3399/release/m0/rk3399m0.bin ^ plat/rockchip/rk3399/drivers/pmu/pmu_fw.S:20:1: note: while in macro instantiation INCBIN """/home/qschulz/work/upstream/trusted-firmware-a/build/rk3399/release/m0/rk3399m0.bin""", "rk3399m0_bin", ".sram.incbin" ^ <instantiation>:6:10: error: expected string in '.incbin' directive .incbin /home/qschulz/work/upstream/trusted-firmware-a/build/rk3399/release/m0/rk3399m0pmu.bin ^ plat/rockchip/rk3399/drivers/pmu/pmu_fw.S:21:1: note: while in macro instantiation INCBIN """/home/qschulz/work/upstream/trusted-firmware-a/build/rk3399/release/m0/rk3399m0pmu.bin""", "rk3399m0pmu_bin", ".pmusram.incbin" ^ """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" With the following patch: ========================================================================= diff --git a/plat/rockchip/rk3399/drivers/pmu/pmu_fw.S b/plat/rockchip/rk3399/drivers/pmu/pmu_fw.S index 26f331317..ed70cba1f 100644 --- a/plat/rockchip/rk3399/drivers/pmu/pmu_fw.S +++ b/plat/rockchip/rk3399/drivers/pmu/pmu_fw.S @@ -11,7 +11,7 @@ .type \sym, @object .align 4 \sym : - .incbin \file + .incbin "\file" .size \sym , .-\sym .global \sym\()_end \sym\()_end : ========================================================================= clang seems happy with that error but the linker triggers another one: ld.lld: warning: ignoring memory region assignment for non-allocatable section '.incbin_sram' ld.lld: error: section '.pmusram' will not fit in region 'PMUSRAM': overflowed by 3928 bytes Would appreciate some guidance there :) Cheers, Quentin

7 months, 1 week

3
15
0 0

Re: TF-A: Compilation issues for Rockchip platforms

by Chris Kay

I’m afraid I’ve not been able to reproduce the .incbin error – it all links fine for me. $ clang --version Ubuntu clang version 18.1.3 (1ubuntu1) Target: aarch64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/bin

7 months, 1 week

1
0
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

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 447712: Integer handling issues (NO_EFFECT) /plat/arm/board/fvp/fvp_pm.c: 332 in fvp_node_hw_state() ________________________________________________________________________________________________________ *** CID 447712: Integer handling issues (NO_EFFECT) /plat/arm/board/fvp/fvp_pm.c: 332 in fvp_node_hw_state() 326 int ret = 0; 327 328 /* 329 * The format of 'power_level' is implementation-defined, but 0 must 330 * mean a CPU. We also allow 1 to denote the cluster 331 */ >>> CID 447712: Integer handling issues (NO_EFFECT) >>> This less-than-zero comparison of an unsigned value is never true. "power_level < 0ULL". 332 if ((power_level < ARM_PWR_LVL0) || (power_level > ARM_PWR_LVL1)) 333 return PSCI_E_INVALID_PARAMS; 334 335 /* 336 * Read the status of the given MPDIR from FVP power controller. The 337 * power controller only gives us on/off status, so map that to expected ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2…

7 months, 2 weeks

1
0
0 0

Canceled event: TF-A Tech Forum @ Thu Oct 31, 2024 5pm - 6pm (GMT+1) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

This event has been canceled. TF-A Tech Forum Thursday Oct 31, 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 ~~//~~ 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

7 months, 2 weeks

1
0
0 0

TF-A Tech Forum regular call

by Olivier Deprez

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.

7 months, 2 weeks

1
0
0 0

How to configure TZC-400 in ATF?

by 钱非凡

I tried to add two new tzc regions in ATF's source code, and test the memory access in the new region. ```cpp #define ARM_TZC_REGIONS_DEF \ {ARM_AP_TZC_DRAM1_BASE, ARM_EL3_TZC_DRAM1_END + ARM_L1_GPT_SIZE, TZC_REGION_S_RDWR, 0}, \ {ARM_NS_DRAM1_BASE, 0xA0000000-1, ARM_TZC_NS_DRAM_S_ACCESS, PLAT_ARM_TZC_NS_DEV_ACCESS}, \ {0xA0000000, 0xB0000000-1, ARM_TZC_NS_DRAM_S_ACCESS, PLAT_ARM_TZC_NS_DEV_ACCESS}, \ {0xB0000000, 0xC0000000-1, ARM_TZC_NS_DRAM_S_ACCESS, PLAT_ARM_TZC_NS_DEV_ACCESS}, \ {0xC0000000, ARM_NS_DRAM1_END, ARM_TZC_NS_DRAM_S_ACCESS, PLAT_ARM_TZC_NS_DEV_ACCESS}, \ {ARM_DRAM2_BASE, ARM_DRAM2_END, ARM_TZC_NS_DRAM_S_ACCESS, PLAT_ARM_TZC_NS_DEV_ACCESS} ``` But FVP throws some warnings: ``` Info: FVP_Base_RevC_2xAEMvA: FVP_Base_RevC_2xAEMvA.bp.tzc_400: common_reset starts Info: FVP_Base_RevC_2xAEMvA: FVP_Base_RevC_2xAEMvA.bp.tzc_400: build config register value 0x3003f08 4 filters, 9 regions, address width 64 Info: FVP_Base_RevC_2xAEMvA: FVP_Base_RevC_2xAEMvA.bp.flashloader0: FlashLoader: Loaded 3164 kB from file '/home/bea1e/functionality-prototype/build/../trusted-firmware-a/build/fvp/release/fip.bin' Info: FVP_Base_RevC_2xAEMvA: FVP_Base_RevC_2xAEMvA.bp.secureflashloader: FlashLoader: Loaded 25 kB from file '/home/bea1e/functionality-prototype/build/../trusted-firmware-a/build/fvp/release/bl1.bin' Info: FVP_Base_RevC_2xAEMvA: FVP_Base_RevC_2xAEMvA.bp.tzc_400: common_reset starts Info: FVP_Base_RevC_2xAEMvA: FVP_Base_RevC_2xAEMvA.bp.tzc_400: build config register value 0x3003f08 4 filters, 9 regions, address width 64 Warning: FVP_Base_RevC_2xAEMvA: FVP_Base_RevC_2xAEMvA.bp.tzc_400: attempt to write invalid address 220 In file: (unknown):0 In process: FVP_Base_RevC_2xAEMvA.thread_p_32 @ 5126760 ns Warning: FVP_Base_RevC_2xAEMvA: FVP_Base_RevC_2xAEMvA.bp.tzc_400: attempt to write invalid address 224 In file: (unknown):0 In process: FVP_Base_RevC_2xAEMvA.thread_p_32 @ 5126760 ns Warning: FVP_Base_RevC_2xAEMvA: FVP_Base_RevC_2xAEMvA.bp.tzc_400: attempt to write invalid address 228 In file: (unknown):0 In process: FVP_Base_RevC_2xAEMvA.thread_p_32 @ 5126760 ns Warning: FVP_Base_RevC_2xAEMvA: FVP_Base_RevC_2xAEMvA.bp.tzc_400: attempt to write invalid address 22c In file: (unknown):0 In process: FVP_Base_RevC_2xAEMvA.thread_p_32 @ 5126760 ns Warning: FVP_Base_RevC_2xAEMvA: FVP_Base_RevC_2xAEMvA.bp.tzc_400: attempt to write invalid address 230 In file: (unknown):0 In process: FVP_Base_RevC_2xAEMvA.thread_p_32 @ 5126760 ns Warning: FVP_Base_RevC_2xAEMvA: FVP_Base_RevC_2xAEMvA.bp.tzc_400: attempt to write invalid address 234 In file: (unknown):0 In process: FVP_Base_RevC_2xAEMvA.thread_p_32 @ 5126760 ns Warning: FVP_Base_RevC_2xAEMvA: FVP_Base_RevC_2xAEMvA.bp.tzc_400: attempt to write invalid address 240 In file: (unknown):0 In process: FVP_Base_RevC_2xAEMvA.thread_p_32 @ 5127800 ns Warning: FVP_Base_RevC_2xAEMvA: FVP_Base_RevC_2xAEMvA.bp.tzc_400: attempt to write invalid address 244 In file: (unknown):0 In process: FVP_Base_RevC_2xAEMvA.thread_p_32 @ 5127800 ns Warning: FVP_Base_RevC_2xAEMvA: FVP_Base_RevC_2xAEMvA.bp.tzc_400: attempt to write invalid address 248 In file: (unknown):0 In process: FVP_Base_RevC_2xAEMvA.thread_p_32 @ 5127800 ns Warning: FVP_Base_RevC_2xAEMvA: FVP_Base_RevC_2xAEMvA.bp.tzc_400: attempt to write invalid address 24c In file: (unknown):0 In process: FVP_Base_RevC_2xAEMvA.thread_p_32 @ 5127800 ns Warning: FVP_Base_RevC_2xAEMvA: FVP_Base_RevC_2xAEMvA.bp.tzc_400: attempt to write invalid address 250 In file: (unknown):0 In process: FVP_Base_RevC_2xAEMvA.thread_p_32 @ 5127800 ns Warning: FVP_Base_RevC_2xAEMvA: FVP_Base_RevC_2xAEMvA.bp.tzc_400: attempt to write invalid address 254 In file: (unknown):0 In process: FVP_Base_RevC_2xAEMvA.thread_p_32 @ 5127800 ns ``` It seems the configuration registers for the two new regions are invalid. But I dont know how to solve this problem. Here are the arguments of FVP: ``` -C bp.ve_sysregs.exit_on_shutdown=1 \ -C cache_state_modelled=0 \ -C pctl.startup=0.0.0.0 \ -C cluster0.NUM_CORES=4 \ -C cluster1.NUM_CORES=4 \ -C bp.secure_memory=1 \ -C bp.dram_size=8 \ -C bp.tzc_400.diagnostics=1 \ -C bp.secureflashloader.fname=$(TF_A_PATH)/build/fvp/$(TF_A_BUILD)/bl1.bin \ -C bp.flashloader0.fname=$(TF_A_PATH)/build/fvp/$(TF_A_BUILD)/fip.bin \ -C bp.virtioblockdevice.image_path=$(BOOT_IMG) ``` Should I add more arguments while booting FVP? Is there any other advice for me to test the TZASC configurations?

7 months, 2 weeks

2
1
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

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 447121: Incorrect expression (UNUSED_VALUE) /drivers/cadence/emmc/cdns_sdmmc.c: 434 in card_reset() ________________________________________________________________________________________________________ *** CID 447121: Incorrect expression (UNUSED_VALUE) /drivers/cadence/emmc/cdns_sdmmc.c: 434 in card_reset() 428 uint32_t reg_value = 0; 429 430 /* Reading SRS10 value before writing */ 431 reg_value = mmio_read_32(cdns_params.reg_base + SDHC_CDNS_SRS10); 432 433 if (power_enable == true) { >>> CID 447121: Incorrect expression (UNUSED_VALUE) >>> Assigning value "4294963455U" to "reg_value" here, but that stored value is overwritten before it can be used. 434 reg_value &= ~((7 << SDMMC_CDN_BVS) | (1 << SDMMC_CDN_BP)); 435 reg_value = ((1 << SDMMC_CDN_BVS) | (1 << SDMMC_CDN_BP)); 436 } else { 437 reg_value &= ~((7 << SDMMC_CDN_BVS) | (1 << SDMMC_CDN_BP)); 438 } 439 mmio_write_32(cdns_params.reg_base + SDHC_CDNS_SRS10, reg_value); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2…

7 months, 2 weeks

1
0
0 0

Trusted Firmware-A LTS v2.10.9 Release Announcement

by ci_notify＠trustedfirmware.org

Hello, Trusted Firmware-A LTS version 2.10.9 is now available. This release contains the following patches: c4c6eae4e feat(cm): add errata 2938996, 2726228 [1] 33a04460d fix(cpus): modify the fix for Cortex-A75 erratum 764081 [2] [1] https://review.trustedfirmware.org/q/I53b037839820c8b3a869f393588302a365d5b… [2] https://review.trustedfirmware.org/q/Ifda1f4cb32bdec9a9af29397ddc03bf22a7a8… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.10.9/change-log.html Thanks, TF-A LTS team

7 months, 2 weeks

1
0
0 0

Trusted Firmware-A LTS v2.8.24 Release Announcement

by ci_notify＠trustedfirmware.org

Hello, Trusted Firmware-A LTS version 2.8.24 is now available. This release contains the following patches: 10cd41d91 feat(cm): add errata 2938996, 2726228 [1] 578d3577f fix(cpus): modify the fix for Cortex-A75 erratum 764081 [2] [1] https://review.trustedfirmware.org/q/I53b037839820c8b3a869f393588302a365d5b… [2] https://review.trustedfirmware.org/q/Ifda1f4cb32bdec9a9af29397ddc03bf22a7a8… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.8.24/change-log.html Thanks, TF-A LTS team

7 months, 2 weeks

1
0
0 0

Trusted Firmware-A LTS v2.10.8 Release Announcement

by ci_notify＠trustedfirmware.org

Hello, Trusted Firmware-A LTS version 2.10.8 is now available. This release contains the following patches: 9c723cd1a docs(prerequisites): update MbedTLS version to 3.6.1 [1] d3726fb42 refactor(mbedtls): remove hack in LIBMBEDTLS_CFLAGS [2] 34a4f2446 fix(cpus): workaround for Cortex-X4 erratum 3076789 [3] [1] https://review.trustedfirmware.org/q/I1a68dfcb52a8361c1689cb6ef12d265a6462f… [2] https://review.trustedfirmware.org/q/I934adefbf2fed16e16b9d98bc8674125b70b0… [3] https://review.trustedfirmware.org/q/Ib100bfab91efdb6330fdcdac127bcc5732d59… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.10.8/change-log.html Thanks, TF-A LTS team

7 months, 3 weeks

1
0
0 0

Trusted Firmware-A LTS v2.8.23 Release Announcement

by ci_notify＠trustedfirmware.org

Hello, Trusted Firmware-A LTS version 2.8.23 is now available. This release contains the following patches: 89c138ae8 docs(prerequisites): update MbedTLS version to 3.6.1 [1] 625207291 fix(cpus): workaround for Cortex-X4 erratum 3076789 [2] [1] https://review.trustedfirmware.org/q/I1a68dfcb52a8361c1689cb6ef12d265a6462f… [2] https://review.trustedfirmware.org/q/Ib100bfab91efdb6330fdcdac127bcc5732d59… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.8.23/change-log.html Thanks, TF-A LTS team

7 months, 3 weeks

1
0
0 0

Canceled event: TF-A Tech Forum @ Thu Oct 17, 2024 5pm - 6pm (GMT+2) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

This event has been canceled. TF-A Tech Forum Thursday Oct 17, 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 ~~//~~ 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

7 months, 4 weeks

1
0
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

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 445539: High impact quality (WRITE_CONST_FIELD) /drivers/arm/dcc/dcc_console.c: 153 in console_dcc_register() ________________________________________________________________________________________________________ *** CID 445539: High impact quality (WRITE_CONST_FIELD) /drivers/arm/dcc/dcc_console.c: 153 in console_dcc_register() 147 .flush = dcc_console_flush, 148 }, 149 }; 150 151 int console_dcc_register(console_t *console) 152 { >>> CID 445539: High impact quality (WRITE_CONST_FIELD) >>> A write to an aggregate overwrites a const-qualified field within the aggregate. 153 memcpy(console, &dcc_console.console, sizeof(console_t)); 154 return console_register(console); 155 } 156 157 void console_dcc_unregister(console_t *console) 158 { 159 dcc_console_flush(console); 160 (void)console_unregister(console); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2…

7 months, 4 weeks

1
0
0 0

Kernel source for RAS error injection on neoverse reference design platform

by Nagal, Amit

Hi, I am referring to https://neoverse-reference-design.docs.arm.com/en/latest/features/ras/ras.h… for RAS error injection on neoverse reference design platform. I am referring to below steps : mount -t debugfs none /sys/kernel/debug # Step needed for Buildroot only echo 0x80020000 > /sys/kernel/debug/apei/einj/error_type echo 1 > /sys/kernel/debug/apei/einj/oem-einj/sel-firmware-first echo 1 > /sys/kernel/debug/apei/einj/oem-einj/sel-component echo 1 > /sys/kernel/debug/apei/einj/oem-einj/sel-error-type echo 1 > /sys/kernel/debug/apei/einj/error_inject I want to refer to kernel source driver which exposes attributes : sel-firmware-first , sel-component , sel-error-type. Also that driver must be doing the actual injections and registering sdei events with EL3 . can I be advised where to look in for kernel sources ? Regards Amit

8 months

4
6
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

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 445362: Uninitialized variables (UNINIT) /drivers/st/ddr/phy/phyinit/src/ddrphy_phyinit_c_initphyconfig.c: 95 in atxslewrate_program() ________________________________________________________________________________________________________ *** CID 445362: Uninitialized variables (UNINIT) /drivers/st/ddr/phy/phyinit/src/ddrphy_phyinit_c_initphyconfig.c: 95 in atxslewrate_program() 89 uint32_t atxpredrvmode; 90 uint32_t c_addr; 91 uint16_t atxslewrate; 92 93 c_addr = anib << 12; 94 >>> CID 445362: Uninitialized variables (UNINIT) >>> Using uninitialized value "ck_anib_inst[0]". 95 if ((anib == ck_anib_inst[0]) || (anib == ck_anib_inst[1])) { 96 /* CK ANIB instance */ 97 #if STM32MP_DDR3_TYPE || STM32MP_DDR4_TYPE 98 atxpredrvmode = 0x0U; 99 #else /* STM32MP_LPDDR4_TYPE */ 100 atxpredrvmode = 0x1U; ** CID 445361: Control flow issues (DEADCODE) /drivers/st/ddr/phy/phyinit/src/ddrphy_phyinit_c_initphyconfig.c: 1021 in aforcetricont_acx4anibdis_program() ________________________________________________________________________________________________________ *** CID 445361: Control flow issues (DEADCODE) /drivers/st/ddr/phy/phyinit/src/ddrphy_phyinit_c_initphyconfig.c: 1021 in aforcetricont_acx4anibdis_program() 1015 #endif /* STM32MP_DDR3_TYPE || STM32MP_DDR4_TYPE */ 1016 1017 /* 1018 * If all the lanes can be disabled, and Anib is not the first or last disable 1019 * entire chiplet 1020 */ >>> CID 445361: Control flow issues (DEADCODE) >>> Execution cannot reach the expression "anib != 0U" inside this statement: "if (aforcetricont == 15U &&...". 1021 if ((aforcetricont == 0xFU) && (anib != 0U) && 1022 (anib != (config->uib.numanib - 1U))) { 1023 acx4anibdis = acx4anibdis | (0x1U << anib); 1024 } 1025 mmio_write_16((uintptr_t)(DDRPHYC_BASE + (4U * (TANIB | c_addr | 1026 CSR_AFORCETRICONT_ADDR))), ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2…

8 months

1
0
0 0

Introduction and Interest in Contributing to the TF-A Project

by omar elmasry

Dear TF-A Contributors, I hope this email finds you well. My name is Omar, and I am an Embedded Software Engineer at Valeo. I am excited to introduce myself to the Trusted Firmware-A community and look forward to contributing to the project. I have already enrolled in the mailing list and reviewed the documentation. I am passionate about technical deep dives and always eager to explore new areas. I am particularly interested in ARM-based projects, and I'm enthusiastic about getting involved with fellow geeks who share the same passion for cutting-edge technology. I would greatly appreciate any guidance on current tasks or areas where contributions are needed so I can start contributing effectively. Thank you for your time, and I look forward to collaborating with all of you! Best regards, Omar Embedded Software Engineer | Valeo (+20) 10 6962 8429

8 months, 1 week

1
0
0 0

Trusted Firmware-A LTS v2.10.7 Release Announcement

by ci_notify＠trustedfirmware.org

Hello, Trusted Firmware-A LTS version 2.10.7 is now available. This release contains the following patches: 23b59a38b fix(cpus): workaround for Cortex-X4 erratum 2897503 [1] [1] https://review.trustedfirmware.org/q/I3178a890b6f1307b310e817af75f8fdfb8668… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.10.7/change-log.html Thanks, TF-A LTS team

8 months, 1 week

1
0
0 0

Trusted Firmware-A LTS v2.8.22 Release Announcement

by ci_notify＠trustedfirmware.org

Hello, Trusted Firmware-A LTS version 2.8.22 is now available. This release contains the following patches: ac24f38b8 fix(cpus): workaround for Cortex-X4 erratum 2897503 [1] [1] https://review.trustedfirmware.org/q/I3178a890b6f1307b310e817af75f8fdfb8668… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.8.22/change-log.html Thanks, TF-A LTS team

8 months, 1 week

1
0
0 0

Re: TF-A Tech Forum

by Olivier Deprez

Hi, Cancelling as no topic planned for today. Regards, Olivier. ________________________________ From: Trusted Firmware Public Meetings Sent: 24 July 2024 17:36 To: Trusted Firmware Public Meetings <linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com>; marek.bykowski(a)gmail.com <marek.bykowski(a)gmail.com>; okash.khawaja(a)gmail.com <okash.khawaja(a)gmail.com>; tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: TF-A Tech Forum When: 03 October 2024 17:00-18:00. Where: This event has been updated 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/<https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…> Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://linaro-org.zoom.us/my/trustedfirmware?pwd=VktXcm5MNUUyVVM4R0k3ZUtvd…<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fmy%2Ftruste…> 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-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> When Every 2 weeks from 8am to 9am on Thursday (Mountain Standard Time - Phoenix) Guests marek.bykowski(a)gmail.com<mailto:marek.bykowski@gmail.com> okash.khawaja(a)gmail.com<mailto:okash.khawaja@gmail.com> tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> View all guest info<https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…> RSVP for tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> for all events in this series Yes<https://calendar.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tM…> No<https://calendar.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tM…> Maybe<https://calendar.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tM…> More options<https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…> 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>

8 months, 1 week

1
0
0 0

Canceled event: TF-A Tech Forum @ Thu Oct 3, 2024 5pm - 6pm (GMT+2) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

This event has been canceled. TF-A Tech Forum Thursday Oct 3, 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 ~~//~~ 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

8 months, 1 week

1
0
0 0

About the SDS usage model

by Deng Bob

Hi all, I am trying to raise a question about SDS. As you know, SDS (Shared data storage) is used to communicate or exhcange info among different processor units like AP, SCP, RSE, etc. So, do we need to add some lock mechanisms to protect the data when one processor entity is accessing it? After I reviewed the open source Trusted Firmware and SCP firmware it looks to me that both Trusted Firmware and SCP directly access the shared memory region without any limitation. Currently, it just uses the 'valid' flag to identify if the data is ready to use, is this good enough? Looking forwared to your response! Thank you!!! Best Regards, Bob

8 months, 2 weeks

2
2
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

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 445089: Control flow issues (DEADCODE) /drivers/st/pmic/stpmic2.c: 251 in stpmic2_regulator_levels_mv() ________________________________________________________________________________________________________ *** CID 445089: Control flow issues (DEADCODE) /drivers/st/pmic/stpmic2.c: 251 in stpmic2_regulator_levels_mv() 245 uint8_t id, const uint16_t **levels, 246 size_t *levels_count) 247 { 248 const struct regul_struct *regul = &regul_table[id]; 249 250 if (regul == NULL) { >>> CID 445089: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "return -3;". 251 return RET_ERROR_BAD_PARAMETERS; 252 } 253 254 if (levels_count != NULL) { 255 *levels_count = regul->volt_table_size; 256 } ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2…

8 months, 2 weeks

1
0
0 0

TF-A EL3 SPMC upgrade to FF-A Spec v1.2

by Belsare, Akshay

Hi Marc, In TF-A, the FF-A version is currently set to v1.2, but I am unable to find the corresponding implementation for EL3 SPMC configuration. I'm particularly interested in the support for FF-A Notification Mechanism. Could you please provide the timeline for when this will be added to the TF-A EL3 SPMC configuration? Thank You! Akshay Belsare

8 months, 2 weeks

2
2
0 0

PSA calls with RSE comms and MHU

by Yann Gautier

Hello, I would like to use PSA calls for an application on STM32MP2 platform. I've seen the psa_call() API that I could use, in drivers/arm/rse/rse_comms.c. The problem is that it is based on MHU mailbox, which I don't have on STM32MP2. So I was planning plan to disentangle RSE comms and MHU, having a new file in the same directory to manage MHU. This code should then be under a flag, I could re-use PLAT_MHU_VERSION. Setting it to 0, would mean no MHU. AFAICT TF-M uses that split with a dedicated file: rse_comms_hal.c: Abstracts MHU message sending and receiving. (see https://tf-m-user-guide.trustedfirmware.org/platform/arm/rse/rse_comms.html). Do you think this approach sounds right? Thanks, Yann

8 months, 3 weeks

4
5
0 0

Trusted Firmware-A LTS v2.8.21 Release Announcement

by ci_notify＠trustedfirmware.org

Hello, Trusted Firmware-A LTS version 2.8.21 is now available. This release contains the following patches: 75124503f fix(cpus): workaround for Cortex-X4 erratum 2816013 [1] dedcbb78e fix(cpus): workaround for Cortex-A720 erratum 2844092 [2] 9db99a3e4 fix(cpus): workaround for Cortex-A720 erratum 2792132 [3] a0a574d70 feat(cpus): workaround for Cortex-A520(2938996) and Cortex-X4(2726228) [4] d1f63aba2 fix(spm-mm): carve out NS buffer TZC400 region [5] 4220b8313 feat(fvp): add cpu power control [6] d9daf130c docs(fvp): update FVP versions used [7] [1] https://review.trustedfirmware.org/q/I546044bde6e5eedd0abf61643d25e2dd2036d… [2] https://review.trustedfirmware.org/q/I3d8eacb26cba42774f1f31c3aae2a0e6fecec… [3] https://review.trustedfirmware.org/q/I8d11fe65a2ab5f79244cc3395d0645f772563… [4] https://review.trustedfirmware.org/q/I8f886a1c21698f546a0996c719cc27dc0a236… [5] https://review.trustedfirmware.org/q/Idc3370803ad204ac29efeded77305e52e17cc… [6] https://review.trustedfirmware.org/q/Iba6c3c8db60dbeb177cead7ebc65df8265860… [7] https://review.trustedfirmware.org/q/Ie478b81b0f09d8664966cc1fac71a775a1a95… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.8.21/change-log.html Thanks, TF-A LTS team

8 months, 3 weeks

1
0
0 0

Trusted Firmware-A LTS v2.10.6 Release Announcement

by ci_notify＠trustedfirmware.org

Hello, Trusted Firmware-A LTS version 2.10.6 is now available. This release contains the following patches: 582b950ed fix(cpus): workaround for Cortex-X4 erratum 2816013 [1] 9d3934323 fix(cpus): workaround for Cortex-A720 erratum 2844092 [2] a93c69bbb fix(cpus): workaround for Cortex-A720 erratum 2792132 [3] 74fc9576d fix(spm-mm): carve out NS buffer TZC400 region [4] 9ca6bf389 feat(fvp): add cpu power control [5] e941b0e0f fix(arm_fpga): halve number of PEs per core [6] 47010ae9d feat(cpus): workaround for Cortex-A520(2938996) and Cortex-X4(2726228) [7] c1b976727 docs(fvp): update FVP versions used [8] [1] https://review.trustedfirmware.org/q/I546044bde6e5eedd0abf61643d25e2dd2036d… [2] https://review.trustedfirmware.org/q/I3d8eacb26cba42774f1f31c3aae2a0e6fecec… [3] https://review.trustedfirmware.org/q/I8d11fe65a2ab5f79244cc3395d0645f772563… [4] https://review.trustedfirmware.org/q/Idc3370803ad204ac29efeded77305e52e17cc… [5] https://review.trustedfirmware.org/q/Iba6c3c8db60dbeb177cead7ebc65df8265860… [6] https://review.trustedfirmware.org/q/Ieb37ccc9f362b10ff0ce038f72efca21512a7… [7] https://review.trustedfirmware.org/q/I8f886a1c21698f546a0996c719cc27dc0a236… [8] https://review.trustedfirmware.org/q/Ie478b81b0f09d8664966cc1fac71a775a1a95… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.10.6/change-log.html Thanks, TF-A LTS team

8 months, 3 weeks

1
0
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

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 445015: Control flow issues (UNREACHABLE) /mbedtls/library/psa_crypto_cipher.c: 250 in mbedtls_cipher_values_from_psa() ________________________________________________________________________________________________________ *** CID 445015: Control flow issues (UNREACHABLE) /mbedtls/library/psa_crypto_cipher.c: 250 in mbedtls_cipher_values_from_psa() 244 cipher_id_tmp = MBEDTLS_CIPHER_ID_CHACHA20; 245 break; 246 #endif 247 default: 248 return PSA_ERROR_NOT_SUPPORTED; 249 } >>> CID 445015: Control flow issues (UNREACHABLE) >>> This code cannot be reached: "if (cipher_id != NULL) { ...". 250 if (cipher_id != NULL) { 251 *cipher_id = cipher_id_tmp; 252 } 253 254 return mbedtls_cipher_validate_values(alg, key_type); 255 } ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2…

8 months, 3 weeks

1
0
0 0

Re: Canceled event: TF-A Tech Forum @ Thu Sep 19, 2024 5pm - 6pm (GMT+2) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

Hi, Cancelling today's Sep 19th instance as no topic proposed. Regards, Olivier. ________________________________ From: Trusted Firmware Public Meetings Sent: 24 July 2024 17:36 To: Trusted Firmware Public Meetings <linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com>; tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Canceled event: TF-A Tech Forum @ Thu Sep 19, 2024 5pm - 6pm (GMT+2) (tf-a(a)lists.trustedfirmware.org) When: 19 September 2024 17:00-18:00. Where: This event has been canceled. 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/<https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…> Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://linaro-org.zoom.us/my/trustedfirmware?pwd=VktXcm5MNUUyVVM4R0k3ZUtvd…<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fmy%2Ftruste…> 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-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> When Thursday Sep 19, 2024 ⋅ 5pm – 6pm (Central European Time - Paris) Guests tf-a(a)lists.trustedfirmware.org<mailto:tf-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>

8 months, 3 weeks

1
0
0 0

Canceled event: TF-A Tech Forum @ Thu Sep 19, 2024 5pm - 6pm (GMT+2) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

This event has been canceled. TF-A Tech Forum Thursday Sep 19, 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 ~~//~~ 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

8 months, 3 weeks

1
0
0 0

How to map a physical address using `mmap_add_dynamic_region_alloc_va`?

by 钱非凡

Hi experts, I tried to allocate a physical memory address in Linux Kernel, and pass the memory address to tf-a using smc call. As I asked in previous mails (https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.…), tf-a can not access the physical memory address directly, so I try to use the `mmap_add_dynamic_region_alloc_va` function in `xlat_table_v2` Library, and map the physical memory in tf-a. After calling the function, It does return a new virtual memory address, but I still failed to access the address, is there any details I have missed? Here is the code: ``` NOTICE("phys_addr: 0x%lx, virt_addr: 0x%lx\n", phys_addr, virt_addr); int rc = mmap_add_dynamic_region_alloc_va(phys_addr, ptr_virt_addr, size, MT_NS | MT_RW_DATA); if (rc) { WARN("Failed to map memory at 0x%lx: %d\n", phys_addr, rc); return; } NOTICE("virt_addr_el3: 0x%lx\n", virt_addr_el3); NOTICE("virt_addr_el3[0] = 0x%x\n", *((uint32_t *)virt_addr_el3)); ``` Here is the output: ``` NOTICE: phys_addr: 0x40f0000, virt_addr: 0xffff0000040f0000 NOTICE: mm.base_va: 0 NOTICE: mm.base_va: 100000000 NOTICE: virt_addr_el3: 0x100000000 [ 38.540464] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: [ 38.546584] rcu: 4-...0: (1 ticks this GP) idle=4224/1/0x4000000000000000 softirq=125/125 fqs=2625 [ 38.555651] (detected by 0, t=5252 jiffies, g=-779, q=16 ncpus=8) [ 38.561843] Task dump for CPU 4: [ 38.565075] task:main state:R running task stack:0 pid:195 ppid:181 flags:0x00000002 [ 38.575015] Call trace: [ 38.577464] __switch_to+0xe4/0x160 [ 38.580975] 0x42 ``` I would be grateful for any advice or suggestions you may have. Sincerely, Feifan

8 months, 3 weeks

2
1
0 0

Canceled event with note: TF-A Tech Forum @ Thu Sep 5, 2024 5pm - 6pm (GMT+2) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

This event has been canceled with a note: "Hi, Cancelling as no topic this week. Thanks & Regards, Olivier. " TF-A Tech Forum Thursday Sep 5, 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 ~~//~~ 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

9 months, 1 week

1
0
0 0

Can't start new thread in website

by 林觀明

Hi I have a question. But, I can't launch a new thread. Can you help me? Thanks

9 months, 1 week

1
0
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 6 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 6 of 6 defect(s) ** CID 443168: Error handling issues (CHECKED_RETURN) /plat/st/stm32mp2/bl2_plat_setup.c: 183 in bl2_el3_plat_arch_setup() ________________________________________________________________________________________________________ *** CID 443168: Error handling issues (CHECKED_RETURN) /plat/st/stm32mp2/bl2_plat_setup.c: 183 in bl2_el3_plat_arch_setup() 177 BL_CODE_END - BL_CODE_BASE, 178 MT_CODE | MT_SECURE); 179 180 configure_mmu(); 181 182 /* Prevent corruption of preloaded Device Tree */ >>> CID 443168: Error handling issues (CHECKED_RETURN) >>> Calling "mmap_add_dynamic_region" without checking return value (as is done elsewhere 25 out of 29 times). 183 mmap_add_dynamic_region(DTB_BASE, DTB_BASE, 184 DTB_LIMIT - DTB_BASE, 185 MT_RO_DATA | MT_SECURE); 186 187 if (dt_open_and_check(STM32MP_DTB_BASE) < 0) { 188 panic(); ** CID 443167: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /plat/rockchip/rk3588/drivers/scmi/rk3588_clk.c: 578 in rk3588_b0pll_get_rate() ________________________________________________________________________________________________________ *** CID 443167: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /plat/rockchip/rk3588/drivers/scmi/rk3588_clk.c: 578 in rk3588_b0pll_get_rate() 572 573 rate64 *= m; 574 rate64 = rate64 / p; 575 576 if (k != 0) { 577 /* fractional mode */ >>> CID 443167: Integer handling issues (OVERFLOW_BEFORE_WIDEN) >>> Potentially overflowing expression "24000000U * k" with type "unsigned int" (32 bits, unsigned) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "uint64_t" (64 bits, unsigned). 578 uint64_t frac_rate64 = 24000000 * k; 579 580 postdiv = p * 65535; 581 frac_rate64 = frac_rate64 / postdiv; 582 rate64 += frac_rate64; 583 } ** CID 443166: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 443166: Memory - corruptions (OVERRUN) /plat/intel/soc/common/socfpga_vab.c: 97 in socfpga_vab_authentication() 91 if (!IS_BYTE_ALIGNED(img_sz, sizeof(uint32_t))) { 92 ERROR("Image size (%d bytes) not aliged to 4 bytes!\n", img_sz); 93 return -EIMGERR; 94 } 95 96 /* Generate HASH384 from the image */ >>> CID 443166: Memory - corruptions (OVERRUN) >>> Overrunning array "hash384" of 12 bytes by passing it to a function which accesses it at byte offset 47. 97 sha384_start((uint8_t *)img_addr, img_sz, hash384, CHUNKSZ_PER_WD_RESET); 98 cert_hash_ptr = (uint8_t *)(img_addr + img_sz + VAB_CERT_MAGIC_OFFSET + 99 VAB_CERT_FIT_SHA384_OFFSET); 100 101 /* 102 * Compare the SHA384 found in certificate against the SHA384 ** CID 443165: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /plat/rockchip/rk3588/drivers/scmi/rk3588_clk.c: 747 in rk3588_b1pll_get_rate() ________________________________________________________________________________________________________ *** CID 443165: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /plat/rockchip/rk3588/drivers/scmi/rk3588_clk.c: 747 in rk3588_b1pll_get_rate() 741 742 rate64 *= m; 743 rate64 = rate64 / p; 744 745 if (k != 0) { 746 /* fractional mode */ >>> CID 443165: Integer handling issues (OVERFLOW_BEFORE_WIDEN) >>> Potentially overflowing expression "24000000U * k" with type "unsigned int" (32 bits, unsigned) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "uint64_t" (64 bits, unsigned). 747 uint64_t frac_rate64 = 24000000 * k; 748 749 postdiv = p * 65535; 750 frac_rate64 = frac_rate64 / postdiv; 751 rate64 += frac_rate64; 752 } ** CID 443164: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /plat/rockchip/rk3588/drivers/scmi/rk3588_clk.c: 408 in rk3588_lpll_get_rate() ________________________________________________________________________________________________________ *** CID 443164: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /plat/rockchip/rk3588/drivers/scmi/rk3588_clk.c: 408 in rk3588_lpll_get_rate() 402 403 rate64 *= m; 404 rate64 = rate64 / p; 405 406 if (k != 0) { 407 /* fractional mode */ >>> CID 443164: Integer handling issues (OVERFLOW_BEFORE_WIDEN) >>> Potentially overflowing expression "24000000U * k" with type "unsigned int" (32 bits, unsigned) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "uint64_t" (64 bits, unsigned). 408 uint64_t frac_rate64 = 24000000 * k; 409 410 postdiv = p * 65535; 411 frac_rate64 = frac_rate64 / postdiv; 412 rate64 += frac_rate64; 413 } ** CID 254051: Memory - illegal accesses (OVERRUN) /plat/intel/soc/common/lib/sha/sha.c: 206 in sha512_base_do_finalize() ________________________________________________________________________________________________________ *** CID 254051: Memory - illegal accesses (OVERRUN) /plat/intel/soc/common/lib/sha/sha.c: 206 in sha512_base_do_finalize() 200 const int bit_offset = SHA512_BLOCK_SIZE - sizeof(uint64_t[2]); 201 uint64_t *bits = (uint64_t *)(sctx->buf + bit_offset); 202 unsigned int partial = sctx->count[0] % SHA512_BLOCK_SIZE; 203 204 sctx->buf[partial++] = 0x80; 205 if (partial > bit_offset) { >>> CID 254051: Memory - illegal accesses (OVERRUN) >>> Overrunning array of 128 bytes at byte offset 128 by dereferencing pointer "sctx->buf + partial". [Note: The source code implementation of the function has been overridden by a builtin model.] 206 memset(sctx->buf + partial, 0x0, SHA512_BLOCK_SIZE - partial); 207 partial = 0; 208 209 sha512_block_fn(sctx, sctx->buf, 1); 210 } 211 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2…

9 months, 2 weeks

1
0
0 0

Canceled event with note: TF-A Tech Forum @ Thu Aug 22, 2024 5pm - 6pm (GMT+2) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

This event has been canceled with a note: "Hi, Cancelling today as no topic. Regards, Olivier." TF-A Tech Forum Thursday Aug 22, 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 ~~//~~ 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

9 months, 3 weeks

1
0
0 0

Re: TF-A Tech Forum

by Olivier Deprez

Hi, cancelling today as no topic. Regards, Olivier. ________________________________ From: Trusted Firmware Public Meetings Sent: 24 July 2024 17:36 To: Trusted Firmware Public Meetings <linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com>; marek.bykowski(a)gmail.com <marek.bykowski(a)gmail.com>; okash.khawaja(a)gmail.com <okash.khawaja(a)gmail.com>; tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: TF-A Tech Forum When: 22 August 2024 17:00-18:00. Where: TF-A Tech Forum 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 This event has been updated 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/<https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…> Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://linaro-org.zoom.us/my/trustedfirmware?pwd=VktXcm5MNUUyVVM4R0k3ZUtvd…<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fmy%2Ftruste…> 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-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> When Every 2 weeks from 8am to 9am on Thursday (Mountain Standard Time - Phoenix) Guests marek.bykowski(a)gmail.com<mailto:marek.bykowski@gmail.com> okash.khawaja(a)gmail.com<mailto:okash.khawaja@gmail.com> tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> View all guest info<https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…> RSVP for tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> for all events in this series <https://calendar.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tM…> Yes <https://calendar.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tM…> No <https://calendar.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tM…> Maybe <https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…> More options 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>

9 months, 3 weeks

1
0
0 0

Query regarding the test coverage thru tf-a-tests

by Thangaraj, Senthil Nathan

Dear TF-A team, I have a query regarding the TF-A test. Specifically, I would like to know if there is a method to find out the code coverage for a specific test or for all the tests in current run? Your direction in this regard will be really appreciated. Thank you, Senthil

9 months, 3 weeks

1
0
1 0

Arm TF-A can not access linux kernel's virtual/physical address?

by 钱非凡

In my opinion, Arm TF-A (EL3) has higher privileges than Linux Kernel (EL1), and Secure World should be able to access all memory address in Normal World. To verify this feature, I added a new SMC call in Arm TF-A and wrote a kernel module to test it (on a Hikey960 Development Board). But the program does not run as expected that Arm TF-A stucked while accessing the memory address passed by Linux Kernel. Here is my kernel module, which uses `alloc_pages` to acquire a physical address, and uses `page_address` converting it to a virtual address. And the module passes the physical address and the virtual address to Arm TF-A using `smc #0`: ```cpp static int __init smc_testing_init(void) { uintptr_t phys_addr, virt_addr; pr_info("Mmodule loaded\n"); phys_addr = (uintptr_t) alloc_pages(GFP_KERNEL, 2); virt_addr = (uintptr_t) page_address((struct page *) phys_addr); memset((void *) virt_addr, 'A', PAGE_SIZE << 2); printk("phys_addr: 0x%llx, virt_addr: 0x%llx\n", (uint64_t) phys_addr, (uint64_t) virt_addr); asm volatile( "ldr x0, =0xC8000003\n" "mov x1, %0\n" "mov x2, %1\n" "smc #0\n" : : "r" (phys_addr), "r" (virt_addr) : "x0", "x1", "x2" ); __free_pages((struct page *) phys_addr, 2); return 0; } static void __exit smc_testing_exit(void) { pr_info("Module unloaded\n"); } ``` And here is the handler's code in Arm TF-A, which prints the addresses of physical address and virtual address, and access the first element of the memory address: ```cpp if (0xC8000003 == smc_fid) { uintptr_t virt_addr = x3; NOTICE("phys_addr: 0x%lx, virt_addr: 0x%lx\n", phys_addr, virt_addr); NOTICE("virt_addr[0] = 0x%x\n", *((uint32_t *)virt_addr)); NOTICE("phys_addr[0] = 0x%x\n", *((uint32_t *)phys_addr)); SMC_RET0(handle); } ``` Here is the output, Arm TF-A handles the request successfully, but failed to access the memory address passed by Linux Kernel: ```bash # insmod ./smc_testing.ko [ 75.259590] smc_testing: loading out-of-tree module taints kernel. [ 75.266682] Mmodule loaded [ 75.269404] phys_addr: 0xfffffc0002dc5e00, virt_addr: 0xffff0000b7178000 NOTICE: phys_addr: 0xfffffc0002dc5e00, virt_addr: 0xffff0000b7178000 [ 96.276605] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: [ 96.282741] rcu: 4-...0: (1 ticks this GP) idle=72ec/1/0x4000000000000000 softirq=204/204 fqs=2592 [ 96.291835] (detected by 0, t=5253 jiffies, g=-643, q=16 ncpus=8) [ 96.298044] Task dump for CPU 4: [ 96.301287] task:insmod state:R running task stack:0 pid:201 ppid:185 flags:0x00000006 [ 96.311254] Call trace: [ 96.313713] __switch_to+0xe4/0x160 [ 96.317241] printk_rb_static+0x30/0x58 ```

9 months, 3 weeks

2
1
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

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 441243: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 441243: Memory - corruptions (OVERRUN) /plat/xilinx/common/pm_service/pm_svc_main.c: 516 in eemi_api_handler() 510 module_id = (api_id & MODULE_ID_MASK) >> 8U; 511 512 PM_PACK_PAYLOAD7(payload, module_id, security_flag, api_id, 513 pm_arg[0], pm_arg[1], pm_arg[2], pm_arg[3], 514 pm_arg[4], pm_arg[5]); 515 >>> CID 441243: Memory - corruptions (OVERRUN) >>> Overrunning callee's array of size 7 by passing argument "7UL" in call to "pm_ipi_send_sync". 516 ret = pm_ipi_send_sync(primary_proc, payload, (uint32_t *)buf, 517 PAYLOAD_ARG_CNT); 518 519 SMC_RET4(handle, (uint64_t)ret | ((uint64_t)buf[0] << 32U), 520 (uint64_t)buf[1] | ((uint64_t)buf[2] << 32U), 521 (uint64_t)buf[3] | ((uint64_t)buf[4] << 32U), ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2…

10 months

1
0
0 0

Canceled event with note: TF-A Tech Forum @ Thu Aug 8, 2024 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by Joanna Farley

This event has been canceled with a note: "No topics scheduled this week so cancelling. Also a lot of people seem to be away on vacations." TF-A Tech Forum Thursday Aug 8, 2024 ⋅ 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/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 ~~//~~ 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

10 months, 1 week

1
0
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

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 440627: Control flow issues (DEADCODE) /plat/allwinner/sun50i_h616/sunxi_h616_dtb.c: 56 in sunxi_soc_fdt_fixup() ________________________________________________________________________________________________________ *** CID 440627: Control flow issues (DEADCODE) /plat/allwinner/sun50i_h616/sunxi_h616_dtb.c: 56 in sunxi_soc_fdt_fixup() 50 if (ret != 0) { 51 return; 52 } 53 54 node = fdt_node_offset_by_phandle(dtb, phandle); 55 if (ret != 0) { >>> CID 440627: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "return;". 56 return; 57 } 58 59 ccsidr = armv8_get_ccsidr(CACHE_L2U); 60 sets = ((ccsidr >> CCSIDR_SETS_SHIFT) & CCSIDR_SETS_MASK) + 1; 61 line_size = 16U << ((ccsidr >> CCSIDR_LSIZE_SHIFT) & CCSIDR_LSIZE_MASK); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2…

10 months, 2 weeks

1
0
0 0

Re: Integrate TF-A and PSA Crypto API with PUFcc

by Jothikumar Mani

HI Andy, Thank you for explaining, psa-arch-test(psa certified api compliance) testsuite currently used with TFM +MbedTLS environment as a release gate, and there is trusted service team whom were running the psa-arch-test package on arm-A class devices. Coming back to the question related to psa-arch-test, the current available package should suffice to check the compliance of crypto necessary tasks/functinoality, fyi we have already validated the latest psa-arch-test repo with the mbedtls 3.6. So I would not be more concern about the psa-arch-test being compliant to latest 1.2.1 spec. because between 1.1.0 and 1.2.1 there were minimal changes which is not showstopper for the psa certified api certification. Regards, JK From: Andy Chen <andychen(a)pufsecurity.com> Date: Thursday, 25 July 2024 at 5:30 AM To: Jothikumar Mani <Jothikumar.Mani(a)arm.com>, Manish Badarkhe <Manish.Badarkhe(a)arm.com>, tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Cc: Diya Soubra <Diya.Soubra(a)arm.com>, Victoria Lee <victorialee(a)pufsecurity.com>, Andrew <andrewirvin(a)pufsecurity.com> Subject: 回覆: Integrate TF-A and PSA Crypto API with PUFcc Hi Jothikumar and Manish, It's great to discuss with you and thanks. Sure, it's more clarity with usage scenarios: 1. As a Security IP provider, our PUFcc functions as a Hardware Root of Trust. However, mbedTLS currently doesn't fully support HRoT. Therefore, we are integrating directly into the PSA Crypto API, which permits customization. 1. While working on PSA L3 or L2R, we frequently face version conflicts. That why, in this project, we aim to confirm these version issues (including the dev. and test bench). 1. This also means that both TF-A and TF-M support PSA Crypto API, so we can also support both through this package. There is our PSA Software Package with PUFcc. We try to find the best way to support cryptographic tasks. Additionally, we plan to use the same development platform as ARM to ensure optimal compatibility for our customers. It means we would try to know the FPV, although I'm not sure if we can add external IPs. If I misunderstood or you have any ideas, please feel free to tell me. [cid:ed0bb76e-fb77-4502-ae5d-f8443d6b4fc4] Have a Nice Day, Andy ________________________________ 寄件者: Jothikumar Mani <Jothikumar.Mani(a)arm.com> 寄件日期: 2024年7月24日下午 11:48 收件者: Andy Chen <andychen(a)pufsecurity.com>; Manish Badarkhe <Manish.Badarkhe(a)arm.com>; tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> 副本: Diya Soubra <Diya.Soubra(a)arm.com>; Victoria Lee <victorialee(a)pufsecurity.com>; Andrew <andrewirvin(a)pufsecurity.com> 主旨: RE: Integrate TF-A and PSA Crypto API with PUFcc Hi Andy, Please find my reply in the previous mail. Regards, JK From: Andy Chen <andychen(a)pufsecurity.com> Sent: Wednesday, July 24, 2024 8:11 PM To: Manish Badarkhe <Manish.Badarkhe(a)arm.com>; Jothikumar Mani <Jothikumar.Mani(a)arm.com>; tf-a(a)lists.trustedfirmware.org Cc: Diya Soubra <Diya.Soubra(a)arm.com>; Victoria Lee <victorialee(a)pufsecurity.com>; Andrew <andrewirvin(a)pufsecurity.com> Subject: 回覆: Integrate TF-A and PSA Crypto API with PUFcc Hi Manish, Thanks for your information. We need to integrate our hardware Crypto IP (PUFcc). And it seems that FVP cannot add custom IP, so we are planning to purchase an FPGA with the A53 - AXU9EGB<https://www.xilinx.com/products/boards-and-kits/1-1ervp7b.html> for our needs. And we need to make sure it is compatible with TF-A lts-v2.10.5. Thanks. Hi Jothikumar, We would try to integrate with PSA Crypto API, and we need a test bench for v1.2.1. Please feel free to let me know if you have any suggestions. [JK] : may I know what the intent is to requesting the crypto v1.2.1 spec compliance suites?, if you are looking for the PSA Certified APIs compliance for your product then the currently available testsuite is more than sufficient. Also, the mbedTLS version mentioned also only supports psa-crypto spec v1.1.0. I am trying to under the end goal of the psa certified api compliance suite usage with your product. Answer to this question will help me to give better suggestion. For TF-A, we plan to integrate with: TF-A lts-v2.10.5 PSA Crypto API - v1.1.0 >>> v1.2.1 PSA Certified APIs Architecture Test Suite - v1.6 Thank you very much. Have a Nice Day, Andy ________________________________ 寄件者: Manish Badarkhe <Manish.Badarkhe(a)arm.com<mailto:Manish.Badarkhe@arm.com>> 寄件日期: 2024年7月24日下午 06:12 收件者: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>>; Andy Chen <andychen(a)pufsecurity.com<mailto:andychen@pufsecurity.com>>; Jothikumar Mani <Jothikumar.Mani(a)arm.com<mailto:Jothikumar.Mani@arm.com>> 副本: Diya Soubra <Diya.Soubra(a)arm.com<mailto:Diya.Soubra@arm.com>>; Victoria Lee <victorialee(a)pufsecurity.com<mailto:victorialee@pufsecurity.com>>; Andrew <andrewirvin(a)pufsecurity.com<mailto:andrewirvin@pufsecurity.com>> 主旨: Re: Integrate TF-A and PSA Crypto API with PUFcc Hi Andy Please see my replies inline. Adding Jothikumar Mani for PSA Certified APIs Architecture Test Suite. Thanks, Manish Badarkhe ________________________________ From: Andy Chen via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Sent: 23 July 2024 09:55 To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Cc: Diya Soubra <Diya.Soubra(a)arm.com<mailto:Diya.Soubra@arm.com>>; Victoria Lee <victorialee(a)pufsecurity.com<mailto:victorialee@pufsecurity.com>>; Andrew <andrewirvin(a)pufsecurity.com<mailto:andrewirvin@pufsecurity.com>> Subject: [TF-A] Integrate TF-A and PSA Crypto API with PUFcc Hi TF-A teams, This is Andy from PUFsecurity, and we have a project with ARM. We try to integrate the PSA Crypto API with PUFcc (Our Crypto Engine) on TF-A. However, there are multiple versions included, and we need your assistance for specification clarification. Please ensure the versions match your recommendations. For TF-A, we plan to integrate with: TF-A lts-v2.10.5 PSA Crypto API - v1.1.0 PSA Certified APIs Architecture Test Suite - v1.6 [MB]: This looks fine. As TF-A lts-v2.10.5 using mbedTLS v3.6.0 which is compliance with PSA Crypto API - v1.1.0 but mbedTLS team can provide more detailed answer on this and also on test suite PSA Certified APIs Architecture Test Suite - v1.6. TF-A It would be beneficial to use the same hardware (FPGA) and tools as the ARM development team. If we can confirm which models are used for TF-A , scripts or details with the ARM hardware That would be grateful. [MB]: We are using FVP AEM model i.e. FVP_Base_RevC-2xAEMvA (Model version: 11.26, Build: 11). Test Run with PSA Crypto you can find here: https://ci.trustedfirmware.org/job/tf-a-builder/4029201/ (today's daily run) PSA Crypto API - The test bench is using the PSA Crypto API v1.1.0, and it is published in 2022. And Now is v1.2.1 in March 2024. I not sure it is a good choose or not. [cid:image001.png@01DADE0E.1BA75330] [MB]: It looks like arch-test is not upgraded to use v1.2.1 PSA Crypto API. Added Jothikumar Mani, he may have idea about this. Test Bench - For the "PSA Certified APIs Architecture Test Suite - v1.6," we would like to identify which test codes (test_c001 to test_c067) are relevant for TF-A. [MB]: Again, TF-A is not using this test suite, so we don't have any insights unless we review all these tests. TF-A mainly uses the following PSA_* APIs for signature verification, hash calculation, and hash comparison. psa_crypto_init mbedtls_md_psa_alg_from_type psa_set_key_algorithm psa_set_key_type psa_set_key_usage_flags psa_import_key psa_destroy_key psa_verify_message psa_hash_compute psa_hash_compare Thank you very much!!! Have a Nice Day, Andy [cid:image002.png@01DADE0E.1BA75330] 熵碼科技股份有限公司 Tel: 886-3-5601010 #2119 Email: andychen(a)pufsecurity.com<mailto:andychen@pufsecurity.com> Website: https://www.pufsecurity.com/ -------- Disclaimer: This e-mail is from PUFsecurity Corporation. This e-mail may contain privileged and confidential information. It is intended for the named recipient(s) only. Disclosure, copying, distribution, or use of the contents of this e-mail by persons other than the intended recipient may violate applicable laws. If you are not an intended recipient, please notify us immediately (by reply e-mail) and delete this e-mail from your system. Our postal address is 8F-1, No. 5, Tai-Yuan 1st St., Jhubei City, Hsinchu County 302082, Taiwan.-------- -------- Disclaimer: This e-mail is from PUFsecurity Corporation. This e-mail may contain privileged and confidential information. It is intended for the named recipient(s) only. Disclosure, copying, distribution, or use of the contents of this e-mail by persons other than the intended recipient may violate applicable laws. If you are not an intended recipient, please notify us immediately (by reply e-mail) and delete this e-mail from your system. Our postal address is 8F-1, No. 5, Tai-Yuan 1st St., Jhubei City, Hsinchu County 302082, Taiwan.-------- -------- Disclaimer: This e-mail is from PUFsecurity Corporation. This e-mail may contain privileged and confidential information. It is intended for the named recipient(s) only. Disclosure, copying, distribution, or use of the contents of this e-mail by persons other than the intended recipient may violate applicable laws. If you are not an intended recipient, please notify us immediately (by reply e-mail) and delete this e-mail from your system. Our postal address is 8F-1, No. 5, Tai-Yuan 1st St., Jhubei City, Hsinchu County 302082, Taiwan.-------- -------- Disclaimer: This e-mail is from PUFsecurity Corporation. This e-mail may contain privileged and confidential information. It is intended for the named recipient(s) only. Disclosure, copying, distribution, or use of the contents of this e-mail by persons other than the intended recipient may violate applicable laws. If you are not an intended recipient, please notify us immediately (by reply e-mail) and delete this e-mail from your system. Our postal address is 8F-1, No. 5, Tai-Yuan 1st St., Jhubei City, Hsinchu County 302082, Taiwan.--------

10 months, 3 weeks

2
2
0 0

Re: Integrate TF-A and PSA Crypto API with PUFcc

by Jothikumar Mani

Hi Andy, Please find my reply in the previous mail. Regards, JK From: Andy Chen <andychen(a)pufsecurity.com> Sent: Wednesday, July 24, 2024 8:11 PM To: Manish Badarkhe <Manish.Badarkhe(a)arm.com>; Jothikumar Mani <Jothikumar.Mani(a)arm.com>; tf-a(a)lists.trustedfirmware.org Cc: Diya Soubra <Diya.Soubra(a)arm.com>; Victoria Lee <victorialee(a)pufsecurity.com>; Andrew <andrewirvin(a)pufsecurity.com> Subject: 回覆: Integrate TF-A and PSA Crypto API with PUFcc Hi Manish, Thanks for your information. We need to integrate our hardware Crypto IP (PUFcc). And it seems that FVP cannot add custom IP, so we are planning to purchase an FPGA with the A53 - AXU9EGB<https://www.xilinx.com/products/boards-and-kits/1-1ervp7b.html> for our needs. And we need to make sure it is compatible with TF-A lts-v2.10.5. Thanks. Hi Jothikumar, We would try to integrate with PSA Crypto API, and we need a test bench for v1.2.1. Please feel free to let me know if you have any suggestions. [JK] : may I know what the intent is to requesting the crypto v1.2.1 spec compliance suites?, if you are looking for the PSA Certified APIs compliance for your product then the currently available testsuite is more than sufficient. Also, the mbedTLS version mentioned also only supports psa-crypto spec v1.1.0. I am trying to under the end goal of the psa certified api compliance suite usage with your product. Answer to this question will help me to give better suggestion. For TF-A, we plan to integrate with: TF-A lts-v2.10.5 PSA Crypto API - v1.1.0 >>> v1.2.1 PSA Certified APIs Architecture Test Suite - v1.6 Thank you very much. Have a Nice Day, Andy ________________________________ 寄件者: Manish Badarkhe <Manish.Badarkhe(a)arm.com<mailto:Manish.Badarkhe@arm.com>> 寄件日期: 2024年7月24日下午 06:12 收件者: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>>; Andy Chen <andychen(a)pufsecurity.com<mailto:andychen@pufsecurity.com>>; Jothikumar Mani <Jothikumar.Mani(a)arm.com<mailto:Jothikumar.Mani@arm.com>> 副本: Diya Soubra <Diya.Soubra(a)arm.com<mailto:Diya.Soubra@arm.com>>; Victoria Lee <victorialee(a)pufsecurity.com<mailto:victorialee@pufsecurity.com>>; Andrew <andrewirvin(a)pufsecurity.com<mailto:andrewirvin@pufsecurity.com>> 主旨: Re: Integrate TF-A and PSA Crypto API with PUFcc Hi Andy Please see my replies inline. Adding Jothikumar Mani for PSA Certified APIs Architecture Test Suite. Thanks, Manish Badarkhe ________________________________ From: Andy Chen via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Sent: 23 July 2024 09:55 To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Cc: Diya Soubra <Diya.Soubra(a)arm.com<mailto:Diya.Soubra@arm.com>>; Victoria Lee <victorialee(a)pufsecurity.com<mailto:victorialee@pufsecurity.com>>; Andrew <andrewirvin(a)pufsecurity.com<mailto:andrewirvin@pufsecurity.com>> Subject: [TF-A] Integrate TF-A and PSA Crypto API with PUFcc Hi TF-A teams, This is Andy from PUFsecurity, and we have a project with ARM. We try to integrate the PSA Crypto API with PUFcc (Our Crypto Engine) on TF-A. However, there are multiple versions included, and we need your assistance for specification clarification. Please ensure the versions match your recommendations. For TF-A, we plan to integrate with: TF-A lts-v2.10.5 PSA Crypto API - v1.1.0 PSA Certified APIs Architecture Test Suite - v1.6 [MB]: This looks fine. As TF-A lts-v2.10.5 using mbedTLS v3.6.0 which is compliance with PSA Crypto API - v1.1.0 but mbedTLS team can provide more detailed answer on this and also on test suite PSA Certified APIs Architecture Test Suite - v1.6. TF-A It would be beneficial to use the same hardware (FPGA) and tools as the ARM development team. If we can confirm which models are used for TF-A , scripts or details with the ARM hardware That would be grateful. [MB]: We are using FVP AEM model i.e. FVP_Base_RevC-2xAEMvA (Model version: 11.26, Build: 11). Test Run with PSA Crypto you can find here: https://ci.trustedfirmware.org/job/tf-a-builder/4029201/ (today's daily run) PSA Crypto API - The test bench is using the PSA Crypto API v1.1.0, and it is published in 2022. And Now is v1.2.1 in March 2024. I not sure it is a good choose or not. [cid:image001.png@01DADE0E.1BA75330] [MB]: It looks like arch-test is not upgraded to use v1.2.1 PSA Crypto API. Added Jothikumar Mani, he may have idea about this. Test Bench - For the "PSA Certified APIs Architecture Test Suite - v1.6," we would like to identify which test codes (test_c001 to test_c067) are relevant for TF-A. [MB]: Again, TF-A is not using this test suite, so we don't have any insights unless we review all these tests. TF-A mainly uses the following PSA_* APIs for signature verification, hash calculation, and hash comparison. psa_crypto_init mbedtls_md_psa_alg_from_type psa_set_key_algorithm psa_set_key_type psa_set_key_usage_flags psa_import_key psa_destroy_key psa_verify_message psa_hash_compute psa_hash_compare Thank you very much!!! Have a Nice Day, Andy [cid:image002.png@01DADE0E.1BA75330] 熵碼科技股份有限公司 Tel: 886-3-5601010 #2119 Email: andychen(a)pufsecurity.com<mailto:andychen@pufsecurity.com> Website: https://www.pufsecurity.com/ -------- Disclaimer: This e-mail is from PUFsecurity Corporation. This e-mail may contain privileged and confidential information. It is intended for the named recipient(s) only. Disclosure, copying, distribution, or use of the contents of this e-mail by persons other than the intended recipient may violate applicable laws. If you are not an intended recipient, please notify us immediately (by reply e-mail) and delete this e-mail from your system. Our postal address is 8F-1, No. 5, Tai-Yuan 1st St., Jhubei City, Hsinchu County 302082, Taiwan.-------- -------- Disclaimer: This e-mail is from PUFsecurity Corporation. This e-mail may contain privileged and confidential information. It is intended for the named recipient(s) only. Disclosure, copying, distribution, or use of the contents of this e-mail by persons other than the intended recipient may violate applicable laws. If you are not an intended recipient, please notify us immediately (by reply e-mail) and delete this e-mail from your system. Our postal address is 8F-1, No. 5, Tai-Yuan 1st St., Jhubei City, Hsinchu County 302082, Taiwan.-------- -------- Disclaimer: This e-mail is from PUFsecurity Corporation. This e-mail may contain privileged and confidential information. It is intended for the named recipient(s) only. Disclosure, copying, distribution, or use of the contents of this e-mail by persons other than the intended recipient may violate applicable laws. If you are not an intended recipient, please notify us immediately (by reply e-mail) and delete this e-mail from your system. Our postal address is 8F-1, No. 5, Tai-Yuan 1st St., Jhubei City, Hsinchu County 302082, Taiwan.--------

10 months, 3 weeks

1
0
0 0

Updated invitation: TF-A Tech Forum @ Every 2 weeks from 8am to 9am on Thursday (MST) (tf-a@lists.trustedfirmware.org)

by Don Harbin

This event has been updated TF-A Tech Forum Every 2 weeks from 8am to 9am 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 marek.bykowski(a)gmail.com okash.khawaja(a)gmail.com tf-a(a)lists.trustedfirmware.org 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

10 months, 3 weeks

1
0
0 0

Updated invitation: TF-A Tech Forum @ Every 2 weeks from 9am to 10am on Thursday from Thu Mar 7 to Wed Jul 24 (MST) (tf-a@lists.trustedfirmware.org)

by Don Harbin

This event has been updated Changed: time TF-A Tech Forum Every 2 weeks from 9am to 10am on Thursday from Thursday Mar 7 to Wednesday Jul 24 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 marek.bykowski(a)gmail.com okash.khawaja(a)gmail.com tf-a(a)lists.trustedfirmware.org 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

10 months, 3 weeks

1
0
0 0

Integrate TF-A and PSA Crypto API with PUFcc

by Andy Chen

Hi TF-A teams, This is Andy from PUFsecurity, and we have a project with ARM. We try to integrate the PSA Crypto API with PUFcc (Our Crypto Engine) on TF-A. However, there are multiple versions included, and we need your assistance for specification clarification. Please ensure the versions match your recommendations. For TF-A, we plan to integrate with: TF-A lts-v2.10.5 PSA Crypto API - v1.1.0 PSA Certified APIs Architecture Test Suite - v1.6 TF-A It would be beneficial to use the same hardware (FPGA) and tools as the ARM development team. If we can confirm which models are used for TF-A , scripts or details with the ARM hardware That would be grateful. PSA Crypto API - The test bench is using the PSA Crypto API v1.1.0, and it is published in 2022. And Now is v1.2.1 in March 2024. I not sure it is a good choose or not. [cid:0e747007-8c2a-49a7-9447-8d5e7f9a3e9c] Test Bench - For the "PSA Certified APIs Architecture Test Suite - v1.6," we would like to identify which test codes (test_c001 to test_c067) are relevant for TF-A. Thank you very much!!! Have a Nice Day, Andy [cid:74269c28-12d4-48a9-b215-3d3eaf95f2c3] 熵碼科技股份有限公司 Tel: 886-3-5601010 #2119 Email: andychen(a)pufsecurity.com<mailto:andychen@pufsecurity.com> Website: https://www.pufsecurity.com/ -------- Disclaimer: This e-mail is from PUFsecurity Corporation. This e-mail may contain privileged and confidential information. It is intended for the named recipient(s) only. Disclosure, copying, distribution, or use of the contents of this e-mail by persons other than the intended recipient may violate applicable laws. If you are not an intended recipient, please notify us immediately (by reply e-mail) and delete this e-mail from your system. Our postal address is 8F-1, No. 5, Tai-Yuan 1st St., Jhubei City, Hsinchu County 302082, Taiwan.-------- -------- Disclaimer: This e-mail is from PUFsecurity Corporation. This e-mail may contain privileged and confidential information. It is intended for the named recipient(s) only. Disclosure, copying, distribution, or use of the contents of this e-mail by persons other than the intended recipient may violate applicable laws. If you are not an intended recipient, please notify us immediately (by reply e-mail) and delete this e-mail from your system. Our postal address is 8F-1, No. 5, Tai-Yuan 1st St., Jhubei City, Hsinchu County 302082, Taiwan.--------

10 months, 3 weeks

2
1
0 0

TF-A Tech Forum - Jul 25th 2024 - Unification of Chain of Trust Descriptors

by Olivier Deprez

Hi, On Jul 25th in the TF-A Tech Forum: Unification of Chain of Trust Descriptors - presented by Xialin Liu Currently, the Chain of Trust is implemented using C data structures built into the firmware or through device tree nodes. Maintaining both formats can lead to maintenance challenges. Therefore, we are standardizing the provision of Chain of Trust descriptors exclusively via the device tree and providing a tool to convert device tree descriptors into C source files. This approach simplifies the process, ensuring consistency and reducing the potential for errors associated with managing multiple formats. Regards, Olivier. TF-A Tech Forum Thursday Jul 25, 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

10 months, 3 weeks

1
0
0 0

Firmware Partition Filesystem query

by Ghennadi Procopciuc

Greetings everyone, I came across the following paragraph while reading the 'Firmware Partition Filesystem' chapter from EBBR v2.2.0 and I would like to clarify my understanding: Where possible, firmware images and data should be stored in a filesystem. Firmware can be stored either in a dedicated firmware partition, or in certain circumstances in the UEFI System Partition (ESP). Using a filesystem makes it simpler to manage multiple firmware files and makes it possible for a single disk image to contain firmware for multiple platforms. Dedicated firmware partitions should be formatted with a FAT filesystem as defined in UEFI § 13.3 File System Format. Dedicated firmware partitions should use the same /FIRMWARE directory hierarchy. OS tools shall ignore dedicated firmware partitions, and shall not attempt to use a dedicated firmware partition as an ESP Questions: 1. Does the above paragraph mean that, if the device allows, all firmware binaries (TF-A, U-Boot, and some others) must be stored in a dedicated firmware partition formatted with a FAT filesystem and GUID Partition Table (GPT) disk layout? 2. If so, would this also mean that, where possible, the BootROM or a (first stage) bootloader running before TF-A should have GPT and FAT support embedded support to load one of the TF-A stages (BL1/BL2)? Regards, Ghennadi

10 months, 3 weeks

5
7
0 0

Proper message for ERRATA_NOT_APPLIES case

by Bollapalli, Maheedhar Sai

Hi, On AMD-Xilinx ZynqMP platform for ERRATA_NOT_APPLIES case; the log appearing on the console is as below: "VERBOSE: BL31: cortex_a53: CPU workaround for erratum 819472was not applied". We checked ZynqMP code and found that the ZynqMP cpu revision was higher than the cpu revision intended in the erratum and hence it was not applicable and not applied. The message seems inappropriate to us as from log message it is not clear why it wasn't applied. Our suggestion is that in the log message instead of "not applied" it should be mentioned as "not applicable" as indicated below to reflect the reason properly. "VERBOSE: BL31: cortex_a53: CPU workaround for erratum 819472 was not applicable". Regards, Maheedhar.

10 months, 4 weeks

2
1
0 0

BL2 does find only 2 images

by Labs, Torsten

Hey all, i tried to setup a fip.bin and add 3 images (bl31, bl32 and bl33). ./fiptool --verbose create --soc-fw bl31.bin --nt-fw bl33.bin --tos-fw bl32.bin fip.bin When i check the generated fip.bin with fiptool info it shows me all my three images in the fip.bin EL3 Runtime Firmware BL31: offset=0xB0, size=0x13644, cmdline="--soc-fw" Secure Payload BL32 (Trusted OS): offset=0x136F4, size=0x18D864, cmdline="--tos-fw" Non-Trusted Firmware BL33: offset=0x1A0F58, size=0x9692E, cmdline="--nt-fw" But during bootup the BL2 finds only the image id =3 and image id=5 which is BL32 and BL33. Why he is not finding the bl32? Thanks for youre short help. Regards Torsten

11 months

2
1
0 0

TF-A Tech Forum - Jul 11th 2024 - Using the SMC Fuzzing Module in TF-A

by Olivier Deprez

Hi, This Thursday Jul 11th Kathleen Capella from Arm's TF-A team will present: **Using the SMC Fuzzing Module in TF-A** This presentation will show how you might get started with fuzz testing using the SMC fuzzing module in TF-A. I will demonstrate the basic fuzzer features, how to add SMC calls/test cases and how to make use of the module's integration with tf-a-tests and the TF-A CI. Regards, Olivier. TF-A Tech Forum Thursday Jul 11, 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

11 months, 1 week

2
1
0 0

TF-A Tech Forum - Jul 18th 2024 - NUMA-Aware PER-CPU Framework

by Olivier Deprez

Hi, On Thursday Jul 18th 2024 Rohit Mathew from Arm's Infra solutions team will present: ** NUMA-Aware PER-CPU Framework: Enhancing Latency and Storage Efficiency** With the increasing prevalence of multi-chip platforms, it is crucial for software written for Trusted Firmware-A to be NUMA-aware. The PER-CPU framework addresses this need by distributing the allocation of per-CPU objects across different NUMA nodes. This approach reduces NUMA latency and balances the allocation load, leading to improved performance and efficiency. Regards, Olivier. NUMA-Aware PER-CPU Framework: Enhancing Latency and Storage Efficiency Thursday Jul 18, 2024 ⋅ 5pm – 5:50pm Central European Time - Paris Location zoom, see dial-in information below https://www.google.com/maps/search/zoom,+see+dial-in+information+below?hl=en NUMA-Aware PER-CPU Framework: Enhancing Latency and Storage EfficiencyWith the increasing prevalence of multi-chip platforms, it is crucial for software written for Trusted Firmware-A to be NUMA-aware. The PER-CPU framework addresses this need by distributing the allocation of per-CPU objects across different NUMA nodes. This approach reduces NUMA latency and balances the allocation load, leading to improved performance and efficiency.Dial In Information:Trusted Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://linaro-org.zoom.us/j/9159704974?pwd=VktXcm5MNUUyVVM4R0k3ZUtvdU84QT09Meeting ID: 915 970 4974Passcode: Mj6NdM---One tap mobile+13462487799,,9159704974# US (Houston)+16694449171,,9159704974# US---Dial by your location• +1 346 248 7799 US (Houston)• +1 669 444 9171 US• +1 669 900 9128 US (San Jose)• +1 719 359 4580 US• +1 253 205 0468 US• +1 253 215 8782 US (Tacoma)• +1 646 931 3860 US• +1 689 278 1000 US• +1 301 715 8592 US (Washington DC)• +1 305 224 1968 US• +1 309 205 3325 US• +1 312 626 6799 US (Chicago)• +1 360 209 5623 US• +1 386 347 5053 US• +1 507 473 4847 US• +1 564 217 2000 US• +1 646 558 8656 US (New York)• 833 548 0276 US Toll-free• 833 548 0282 US Toll-free• 833 928 4608 US Toll-free• 833 928 4609 US Toll-free• 833 928 4610 US Toll-free• 877 853 5247 US Toll-free• 888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://linaro-org.zoom.us/u/aZXJZYXK

11 months, 1 week

1
0
0 0

Native compilation failed on dev board not able to find the gcc

by Anand Moon

Hi All, I am trying to compile the latest ATF on Raspberry Pi 5 but it fails. This is the same for all the other Arm64 architecture I have. Earlier versions of ATF were able to compile on-board with native gcc. Well with CROSS_COMPILE it works fine on x86_64 machine. alarm@raspberrypi:~/Downloads/trusted-firmware-a$ make PLAT=rpi5 DEBUG=1 make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: The configured AArch64 C compiler could not be identified and may not be supported: make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: aarch64-none-elf-gcc make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: The default AArch64 C compiler is: make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: aarch64-none-elf-gcc make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: The following tools are supported: make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: - Arm® Compiler for Embedded `armclang` make_helpers/toolchain.mk:344: - LLVM Clang (`clang`) make_helpers/toolchain.mk:344: - GNU GCC (`gcc`) make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: The build system will treat this C compiler as GNU GCC (`gcc`). make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: The configured AArch64 C preprocessor could not be identified and may not be supported: make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: aarch64-none-elf-gcc make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: The default AArch64 C preprocessor is: make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: aarch64-none-elf-gcc make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: The following tools are supported: make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: - Arm® Compiler for Embedded `armclang` make_helpers/toolchain.mk:344: - LLVM Clang (`clang`) make_helpers/toolchain.mk:344: - GNU GCC (`gcc`) make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: The build system will treat this C preprocessor as GNU GCC (`gcc`). make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: The configured AArch64 assembler could not be identified and may not be supported: make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: aarch64-none-elf-gcc make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: The default AArch64 assembler is: make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: aarch64-none-elf-gcc make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: The following tools are supported: make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: - Arm® Compiler for Embedded `armclang` make_helpers/toolchain.mk:344: - LLVM Clang (`clang`) make_helpers/toolchain.mk:344: - GNU GCC (`gcc`) make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: The build system will treat this assembler as GNU GCC (`gcc`). make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: The configured AArch64 linker could not be identified and may not be supported: make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: aarch64-none-elf-gcc make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: The default AArch64 linker is: make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: aarch64-none-elf-gcc make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: The following tools are supported: make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: - Arm® Compiler for Embedded `armclang` make_helpers/toolchain.mk:344: - Arm® Compiler for Embedded `armlink` make_helpers/toolchain.mk:344: - LLVM Clang (`clang`) make_helpers/toolchain.mk:344: - LLVM LLD (`lld`) make_helpers/toolchain.mk:344: - GNU GCC (`gcc`) make_helpers/toolchain.mk:344: - GNU LD (`ld.bfd`) make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: The build system will treat this linker as GNU GCC (`gcc`). make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: The configured AArch64 object copier could not be identified and may not be supported: make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: aarch64-none-elf-objcopy make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: The default AArch64 object copier is: make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: aarch64-none-elf-objcopy make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: The following tools are supported: make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: - Arm® Compiler for Embedded `fromelf` make_helpers/toolchain.mk:344: - LLVM `llvm-objcopy` make_helpers/toolchain.mk:344: - GNU `objcopy` make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: The build system will treat this object copier as GNU `objcopy`. make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: The configured AArch64 object dumper could not be identified and may not be supported: make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: aarch64-none-elf-objdump make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: The default AArch64 object dumper is: make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: aarch64-none-elf-objdump make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: The following tools are supported: make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: - Arm® Compiler for Embedded `fromelf` make_helpers/toolchain.mk:344: - LLVM `llvm-objdump` make_helpers/toolchain.mk:344: - GNU `objdump` make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: The build system will treat this object dumper as GNU `objdump`. make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: The configured AArch64 archiver could not be identified and may not be supported: make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: aarch64-none-elf-gcc-ar make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: The default AArch64 archiver is: make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: aarch64-none-elf-gcc-ar make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: The following tools are supported: make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: - Arm® Compiler for Embedded `armar` make_helpers/toolchain.mk:344: - LLVM `llvm-ar` make_helpers/toolchain.mk:344: - GNU `ar` make_helpers/toolchain.mk:344: make_helpers/toolchain.mk:344: The build system will treat this archiver as GNU `ar`. make_helpers/toolchain.mk:344: /bin/sh: 1: aarch64-none-elf-gcc: not found /bin/sh: 1: aarch64-none-elf-gcc: not found CC bl31/bl31_context_mgmt.c make: aarch64-none-elf-gcc: No such file or directory make: *** [Makefile:1514: /home/alarm/Downloads/trusted-firmware-a/build/rpi5/debug/bl31/bl31_context_mgmt.o] Error 127 alarm@raspberrypi:~/Downloads/trusted-firmware-a$ alarm@raspberrypi:~/Downloads/trusted-firmware-a$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/12/lto-wrapper Target: aarch64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 12.2.0-14' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-12 --program-prefix=aarch64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libquadmath --disable-libquadmath-support --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --enable-fix-cortex-a53-843419 --disable-werror --enable-checking=release --build=aarch64-linux-gnu --host=aarch64-linux-gnu --target=aarch64-linux-gnu Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.2.0 (Debian 12.2.0-14) Thanks -Anand

11 months, 1 week

3
7
0 0

Re: Questions about the Fault Handling of GPFs

by Olivier Deprez

Hi Feifan Qian, Trapping GPF to EL3 is permitted by the architecture, however I don't believe TF-A provides such option. In general for TF-A's reference software stacks, a GPF is trapped first at EL2 (hence SCR_EL3.GPF=0). E.g. In a system implementing RME, the RMM (@ R-EL2) traps a GPF occurring in an R-EL1/0 Realm (or R-EL2 itself). Similarly, in the secure world, the SPM (@ S-EL2) traps a GPF occurring in a S-EL1/0 secure partition (or S-EL2 itself). Regards, Olivier. ________________________________ From: 钱非凡 <qianfeifan(a)iie.ac.cn> Sent: 01 July 2024 08:52 To: tf-a-owner(a)lists.trustedfirmware.org <tf-a-owner(a)lists.trustedfirmware.org> Subject: Questions about the Fault Handling of GPFs Dear experts, I have been learning the Fault Handling of the Granule Protection Fault in Arm CCA. Upon studying the Arm Document, I discovered that the GPF bit in the SCR_EL3 register controls whether the fault handling of GPFs occurs in EL3 or not. In addition, I noted that `include/arch/aarch64/arch.h` defines a macro `#define SCR_GPF_BIT (UL(1) << 48)`, yet I could not find any reference to this macro in the source code. I want to know that whether ATF has implemented the fault handling of GPFs or if this is a feature to be expected in the future. If its not, how can I implement this. Any guidance or advice you could provide would be greatly appreciated. Sincerely, Feifan Qian

11 months, 2 weeks

1
0
0 0

Trusted Firmware-A LTS v2.8.20 Release Announcement

by ci_notify＠trustedfirmware.org

Hello, Trusted Firmware-A LTS version 2.8.20 is now available. This release contains the following patches: 4da2210db chore: add encrypt_fw to gitignore [1] e0124e1ba feat(build): allow additional CFLAGS for library build [2] d7f618143 refactor(mbedtls): avoid including MBEDTLS_CONFIG_FILE [3] fd566c3cd feat(mbedtls): add support for mbedtls-3.3 [4] bf740eba7 feat(fvp): increase BL1_RW and BL2 size [5] ef7aac710 refactor(fvp): minor cleanup with TRUSTED_BOARD_BOOT [6] c82afd25b feat(stm32mp1): add mbedtls-3.3 support config [7] 488514a66 docs(prerequisites): update software and libraries prerequisites [8] a353e39e8 feat(mbedtls): update to 3.4.1 [9] 07126ffb4 build(mbedtls): add deprecation notice [10] 87f4a6305 refactor(mbedtls): remove mbedtls 2.x support [11] e8ae4fa2b feat(mbedtls): update config for 3.6.0 [12] b437905e2 docs(prerequisites): update mbedtls version used [13] [1] https://review.trustedfirmware.org/q/I2f4ddbe1c11848513fe20f7c8b448a041988c… [2] https://review.trustedfirmware.org/q/Ic99af22b229f8089c82110d6545f762c14a62… [3] https://review.trustedfirmware.org/q/I029992311be2a38b588ebbb350875b03ea29a… [4] https://review.trustedfirmware.org/q/Ib034036c09fbdc573d9427b1eda6f2387bda2… [5] https://review.trustedfirmware.org/q/I8a423711ac50b3d615c1d9650086cdbca5051… [6] https://review.trustedfirmware.org/q/I800524d54ea56dc27b6c6da26c75a07f5f6de… [7] https://review.trustedfirmware.org/q/I4581cb0ea7b2c7022e71aefd7ff05ee3a72f5… [8] https://review.trustedfirmware.org/q/I384aab4dfee9cae9453eebf4091abe82ef9cc… [9] https://review.trustedfirmware.org/q/Ifc31c2fc825a2fc9ca318ea8baadd51b670e7… [10] https://review.trustedfirmware.org/q/I669b423ee9af9f5c5255fce370413fffaf38e… [11] https://review.trustedfirmware.org/q/Id3eb98b55692df98aabe6a7c5a5ec910222c8… [12] https://review.trustedfirmware.org/q/Ib345b0bd4f2994f366629ed162d18814fd05a… [13] https://review.trustedfirmware.org/q/I6bd8fcca795373a05bc6beb2e085d24fdd149… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.8.20/change-log.html Thanks, TF-A LTS team

11 months, 2 weeks

1
0
0 0

Trusted Firmware-A LTS v2.10.5 Release Announcement

by ci_notify＠trustedfirmware.org

Hello, Trusted Firmware-A LTS version 2.10.5 is now available. This release contains the following patches: 1d3bb2fe6 refactor(mbedtls): remove mbedtls 2.x support [1] 05ec367ba feat(mbedtls): update config for 3.6.0 [2] aa84a9dad docs(prerequisites): update mbedtls version used [3] ee945f1d2 fix(mbedtls): sign verification issue with invalid Key/Signature [4] [1] https://review.trustedfirmware.org/q/Id3eb98b55692df98aabe6a7c5a5ec910222c8… [2] https://review.trustedfirmware.org/q/Ib345b0bd4f2994f366629ed162d18814fd05a… [3] https://review.trustedfirmware.org/q/I6bd8fcca795373a05bc6beb2e085d24fdd149… [4] https://review.trustedfirmware.org/q/Ib484d97a04b7a82dd72592c8b5b153d577d01… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.10.5/change-log.html Thanks, TF-A LTS team

11 months, 2 weeks

1
0
0 0

Canceled event with note: TF-A Tech Forum @ Thu Jun 27, 2024 5pm - 6pm (GMT+2) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

This event has been canceled with a note: "Hi, Cancelling as no topic planned. Regards, Olivier. " TF-A Tech Forum Thursday Jun 27, 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

11 months, 3 weeks

1
0
0 0

Canceled event with note: TF-A Tech Forum @ Thu Jun 13, 2024 5pm - 6pm (GMT+2) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

This event has been canceled with a note: "Hi, Cancelling this instance as no topic proposed. Thanks, Olivier. " TF-A Tech Forum Thursday Jun 13, 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

1 year

1
0
0 0

Canceled event with note: TF-A Tech Forum @ Thu May 30, 2024 5pm - 6pm (GMT+2) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

This event has been canceled with a note: "Hi, Cancelling for this week as no topic proposed. Thanks, Olivier. " TF-A Tech Forum Thursday May 30, 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

1 year

1
0
0 0

Trusted Firmware v2.10 Release Announcement

by Olivier Deprez

Hi All, We are pleased to announce the formal release of Trusted Firmware-A version 2.10 bundle of project deliverables. This includes Trusted Firmware-A, Trusted Firmware-A Tests, Hafnium, RMM and TF-A OpenCI Scripts/Jobs 2.10 releases involving the tagging of multiple repositories. These went live on 22nd November 2023. Please find references to tags and change logs at the end of this email. Many thanks to the community for the active engagement in delivering this release! Notable Features of the Version 2.10 Release are as follows: TF-A/EL3 Root World * New Features: * Firmware handoff library support * Improvements to BL31 runtime exception handling * Context management refactoring for RME/4 worlds * Gelas, Nevis & Travis CPUs support * V8.9 features enabled (FEAT_ HAFT, RPRFM, LRCPC3, MTE_PERM) TF-A Boot BL1/BL2 * New Features * Trusted Boot support for ECDSA (Elliptic Curve Digital Signature Algorithm) * Migrated to PSA crypto API’s * Improved the GUID Partition Table (GPT) parser. * Various security Improvements and threat Model updates for ARM CCA * Signer id extraction Implementation Hafnium/SEL2 SPM * New Features: * FF-A v1.2: FFA_YIELD with time-out; EL3 SPMDs LSPs communication; memory sharing updates. * Memory region relative base address field support in SP manifests. * Interrupt re-configuration hypervisor calls. * Memory management: S2 PT NS/S IPA split * SMCCCv1.2+ compliance fixes. * Feature parity test improvements, EL3 SPMC and Hafnium (S-EL2 SPMC) TF-RMM/REL2 * New Feature/Support * Fenimore v1.0 EAC5 aligned implementation. * TFTF Enhancements for RME testing * Initial CBMC support * NS SME support in RMM * BTI support for RMM Errata * Errata implemented (1xCortex-X2/ Matterhorn-ELP, 1xCortex-A710/Matterhorn, 1xNeoverse N2/Perseus, 2xNeoverse V2/Demeter, Makalu ELP/Cortex X3, Klein/Cortex-A510) * Fix some minor defects with version in a few errata that applies for some follow up revisions of the CPUs. (Neoverse V1, Cortex-X2, Cortex-A710) TF-A Tests * Core * Added errata management firmware interface tests. * Added firmware handoff tests. * Introduced RAS KFH support test. * SPM/FF-A * Support SMCCCv1.2 extended GP registers set. * Test SMCCC compliance at the non-secure physical instance. * Test secure eSPI interrupt handling. * Test FF-A v1.2 FFA_PARTITION_INFO_GET_REGS interface. * RMM * Added FPU/SVE/SME tests * Added multiple REC single CPU tests. * Added PAuth support in Realms tests. * Added PMU tests. Platform Support * New platforms added: * Aspeed AST2700, NXP IMX93, Intel Agilex5, Nuvoton NPCM845x, QTI MDM9607, MSM8909, MSM8939, ST STM32MP2 Release tags across repositories: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tag/?h=v2.10 https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tag/?h=v2.10 https://git.trustedfirmware.org/ci/tf-a-ci-scripts.git/tag/?h=v2.10 https://git.trustedfirmware.org/ci/tf-a-job-configs.git/tag/?h=v2.10 https://git.trustedfirmware.org/hafnium/hafnium.git/tag/?h=v2.10 https://git.trustedfirmware.org/ci/hafnium-ci-scripts.git/tag/?h=v2.10 https://git.trustedfirmware.org/ci/hafnium-job-configs.git/tag/?h=v2.10 https://git.trustedfirmware.org/TF-RMM/tf-rmm.git/tag/?h=tf-rmm-v0.4.0 Change logs: https://trustedfirmware-a.readthedocs.io/en/v2.10/change-log.html#id1 https://trustedfirmware-a-tests.readthedocs.io/en/v2.10/change-log.html#ver… https://hafnium.readthedocs.io/en/latest/change-log.html#v2-10 https://tf-rmm.readthedocs.io/en/tf-rmm-v0.4.0/about/change-log.html#v0-4-0 Regards, Olivier.

1 year

1
1
0 0

regarding AS and AR values with clang compiler

by Nagal, Amit

Hi , We are trying to build the TF-A code using clang compiler . Instructions are followed as per the conf page https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/initial-… 1. export CROSS_COMPILE=<path-to-aarch64-gcc>/bin/aarch64-none-elf- 2. make CC=<path-to-armclang>/bin/armclang PLAT=<platform> all in our side , make CC=/tools/installs/arm/safety/armcc/6.6.2/bin/armclang PLAT=zynqmp distclean 3. with steps 1) and 2) , we observe the value of AS and AR getting set as below: AS = /tools/installs/arm/safety/armcc/6.6.2/bin/armclang -c -x assembler-with-cpp -target aarch64-arm-none-eabi -march=armv8-a AR = <path-to-aarch64-gcc>/bin/aarch64-linux-gnu-ar 4. However in /tools/installs/arm/safety/armcc/6.6.2/bin , clang tool specific AS points to armasm and AR points to armar utility. 5. From above output in point 4 , we can see that AS and AR does not refer to clang toolchain utilities armasm and armar. From point 3) , AS still points to armclang utility only instead of armasm , while AR still points to aarch64-linux-gnu-ar instead of armar . 6. Can we be guided if the above outputs are correct to use wrt TF-A code build using clang compiler ? And whether any modifications can be done to point AS and AR to clang toolchain specific utilities as mentioned in step 4. Regards Amit

1 year

2
1
0 0

Maintainer for Marvell platforms

by Manish Pandey2

Hi, We do not have active maintainer for Marvell platform. As per docs/about/maintainers.rst the current maintainer is "Konstantin Porotchkin <kostap(a)marvell.com>". Is anybody willing to take ownership of the platform, preferably people who have contributed to this platform in past. Thanks Manish

1 year

4
3
0 0

Make TF-A (bl31) (El3 firmware) preemtible

by Kamlesh Gurudasani

Clock and power management in ATF, preemption issue. I have seen that multiple Vendors are using arm scmi protocol to do clock management in bl31[0][1]. The problem with such implementations is any long running SCMI operations (like PLL locking for example) will hold the core in EL3 for extended period of time, adding to latency of NS EL1 interrupt handling as ATF is not preemptible. This problem can be solved by making ATF preemptible, similar to how OP-TEE does it by by implementing a remote procedural call after it receives a interrupt. [2]How Linux does SMC call with YIELD flag enabled. [3]How OP-TEE handles the timer interrupt [4]How Linux receives an interrupt which came in EL3->SEL1 As quoted in exception Handling document in ATF docs[5] "Receive exceptions, but handle part of the exception in EL3, and delegate processing of the error to dedicated software stack running at lower secure ELs (as above); additionally, the Normal world may also be required to participate in the handling, or be notified of such events (for example, as an event). In this scheme, exception handling potentially and maximally spans all ELs in both Secure and Normal worlds." From this we can understand that we can delegate the exception to EL1 if we are already in EL3. (way to preempt) We are aware that ARM v8.4-A onwards arch are having a SEL2 level with which we can run a vendor specific firmware parallel to TEE at SEL1 in a secure partition. But how we do handle clock and power management for version which doesn't support SEL2? We don't want to put it in TEE as it will constraint our devices to that specific TEE. I am starting to work on a proposal to make ATF preemptible similar to how OP-TEE is doing it. a)Will the similar approach from OP-TEE if implemented and working be accepted by ATF upstream? The SMC call with YIELD option will only be preemtible so will not affect the normal flow. b)As quoted in Trusted Firmware-A Document[6] Page 94, "Yielding calls are reserved exclusively for Trusted OS providers" "Yielding 0- 1 Reserved for existing Armv7-A calls Yielding 2-63 Trusted OS Standard Calls" Can this range be consumed within ATF/bl31 firmware or is it necessary to forward all yielding calls to Trusted OS? [0]https://github.com/ARM-software/arm-trusted-firmware/blob/master/plat/st/… [1]https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/21840 [2]https://elixir.bootlin.com/linux/v6.9-rc3/source/drivers/tee/optee/smc_ab… [3]https://github.com/OP-TEE/optee_os/blob/fc57019cb35c8c1bad66fc6d814ace5de… [4]https://elixir.bootlin.com/linux/v6.9-rc3/source/drivers/tee/optee/smc_ab… [5]https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/com… [6]https://trustedfirmware-a.readthedocs.io/_/downloads/en/latest/pdf/ Regards, Kamlesh

1 year

6
10
0 0

Changelog for v2.11 Release

by Juan Pablo Conde

Hello everyone, Please take a look at the changelog for your respective platforms ahead of the TF-A v2.11 release. The changelog is autogenerated from the commit messages of the patches that have been merged since the v2.10 release. Here's your chance to give us guidance on any small manual adjustments you would like to see. Patch: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/28891 Rendered Version: https://ci-builds.trustedfirmware.org/static-files/M6zhCYgGrsu6KLmMu2AdTlI2… Thanks, Juan Pablo

1 year

1
0
0 0

documentation - secure interrupt handling in EL3 for arm gic v2

by Nagal, Amit

Hi , There is a contradiction present in TF-A documentation whether secure interrupts can be handled in EL3 for arm gic v2 case . 1. Referring https://trustedfirmware-a.readthedocs.io/en/latest/design/interrupt-framewo… It says secure interrupts can't be handled in EL3 . Refer statement : "In Arm GICv2, all secure interrupts are assumed to be handled in Secure-EL1. They can be delivered to Secure-EL1 via EL3 but they cannot be handled in EL3." 2. Referring https://trustedfirmware-a.readthedocs.io/en/latest/components/platform-inte… It says secure interrupts can be handled in EL3 , When GICV2_G0_FOR_EL3 is 1 . Refer below statements : For interrupt type INTR_TYPE_EL3: When GICV2_G0_FOR_EL3 is 0, it returns false, indicating no support for EL3 interrupts. When GICV2_G0_FOR_EL3 is 1, it returns true, indicating support for EL3 interrupts. can this be clarified ? Regards Amit

1 year

2
1
0 0

Trusted Firmware-A LTS v2.8.19 Release Announcement

by ci_notify＠trustedfirmware.org

Hello, Trusted Firmware-A LTS version 2.8.19 is now available. This release contains the following patches. 1e785ab6a feat(spmd): initialize SCR_EL3.EEL2 bit at RESET [1] 9d40eff24 fix(spmd): avoid restoring ctx during first entry into spmc [2] 02633263a fix(cpus): workaround for Cortex-A715 erratum 2728106 [3] 9b5d75b17 fix(cpus): workaround for Cortex-X4 erratum 2740089 [4] d0a74e38c fix(cpus): workaround for Cortex-X4 erratum 2763018 [5] 6c9135fb0 docs: decrease the minimum supported OpenSSL [6] [1] https://review.trustedfirmware.org/q/Ia246235aa8d8004dcaf845f21c8aeeabbbbbe… [2] https://review.trustedfirmware.org/q/I368088ece60826fd7a6aa423ba584a89d32fc… [3] https://review.trustedfirmware.org/q/Ic825f9942e7eb13893fdbb44a2090b897758c… [4] https://review.trustedfirmware.org/q/I1d0fa4dd383437044a4467591f65a4a8514ca… [5] https://review.trustedfirmware.org/q/Ia188e08c2eb2952923ec72e2a56efdeea836f… [6] https://review.trustedfirmware.org/q/I5c60907337f10b05d5c43b0384247c5d4135d… Thanks, TF-A LTS team

1 year

1
0
0 0

Canceled event with note: TF-A Tech Forum @ Thu May 16, 2024 5pm - 6pm (GMT+2) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

This event has been canceled with a note: "Hi, Cancelling as no topic proposed this week. Thanks & Regards, Olivier. " TF-A Tech Forum Thursday May 16, 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

1 year

1
0
0 0

Firmware-A v2.10 release code freeze notification

by Olivier Deprez

Hi All, The next release of the Firmware-A bundle of projects tagged v2.10 has an expected code freeze date of Nov, 7th 2023. Refer to the Release Cadence section from TF-A documentation (https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/docs/about…). Closing out the release takes around 6-10 working days after the code freeze. Preparations tasks for v2.10 release should start in coming month. 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 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 & Regards, Olivier.

1 year

1
3
0 0

FAULT_INJECTION_SUPPORT - FIEN bit

by Nagal, Amit

Hi, Referring https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/getti… it says : ``FAULT_INJECTION_SUPPORT``: ARMv8.4 extensions introduced support for fault injection from lower Els. Referring https://github.com/ARM-software/arm-trusted-firmware/blob/master/lib/el3_ru… FAULT_INJECTION_SUPPORT enables FIEN bit. #if FAULT_INJECTION_SUPPORT /* Enable fault injection from lower ELs */ scr_el3 |= SCR_FIEN_BIT; #endif Question : 1. Do we have any relevant documentation from arm which specifies FIEN bit can be enabled from armv8.4 ? 2. In cortex a-53 technical reference manual, SCR_EL3 does not have FIEN bit , bit 21 is marked reserved . In cortex a-78 technical reference manual , manual does not have details for SCR_EL3 . I want to know whether on Armv8.2-a based cores like cortex a-78 , is the FIEN bit field marked reserved in SCR_EL3 register or is available functionality wise as in armv8.4 ? Please help with above query. Regards Amit

1 year, 1 month

2
1
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

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. 14 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 2 of 2 defect(s) ** CID 425813: Memory - corruptions (OVERRUN) /drivers/arm/css/dsu/dsu.c: 133 in cluster_on_dsu_pmu_context_restore() ________________________________________________________________________________________________________ *** CID 425813: Memory - corruptions (OVERRUN) /drivers/arm/css/dsu/dsu.c: 133 in cluster_on_dsu_pmu_context_restore() 127 void cluster_on_dsu_pmu_context_restore(void) 128 { 129 unsigned int cluster_pos; 130 131 cluster_pos = (unsigned int) plat_cluster_id_by_mpidr(read_mpidr_el1()); 132 >>> CID 425813: Memory - corruptions (OVERRUN) >>> "&cluster_pmu_context[cluster_pos]" evaluates to an address that is at byte offset 138720 of an array of 544 bytes. 133 restore_dsu_pmu_state(&cluster_pmu_context[cluster_pos]); ** CID 425812: Memory - corruptions (OVERRUN) /drivers/arm/css/dsu/dsu.c: 81 in cluster_off_dsu_pmu_context_save() ________________________________________________________________________________________________________ *** CID 425812: Memory - corruptions (OVERRUN) /drivers/arm/css/dsu/dsu.c: 81 in cluster_off_dsu_pmu_context_save() 75 void cluster_off_dsu_pmu_context_save(void) 76 { 77 unsigned int cluster_pos; 78 79 cluster_pos = (unsigned int) plat_cluster_id_by_mpidr(read_mpidr_el1()); 80 >>> CID 425812: Memory - corruptions (OVERRUN) >>> "&cluster_pmu_context[cluster_pos]" evaluates to an address that is at byte offset 138720 of an array of 544 bytes. 81 save_dsu_pmu_state(&cluster_pmu_context[cluster_pos]); 82 } 83 84 /***************************************************************************** 85 * This function, restore_dsu_pmu_state, restores the state of the 86 * Performance Monitoring Unit (PMU) from a previously saved state. ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2…

1 year, 1 month

1
0
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

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. 8 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 1 of 1 defect(s) ** CID 425810: High impact quality (WRITE_CONST_FIELD) /plat/nxp/s32/s32g274ardb2/plat_console.c: 17 in console_s32g2_register() ________________________________________________________________________________________________________ *** CID 425810: High impact quality (WRITE_CONST_FIELD) /plat/nxp/s32/s32g274ardb2/plat_console.c: 17 in console_s32g2_register() 11 12 void console_s32g2_register(void) 13 { 14 static console_t s32g2_console; 15 int ret; 16 >>> CID 425810: High impact quality (WRITE_CONST_FIELD) >>> A write to an aggregate overwrites a const-qualified field within the aggregate. 17 (void)memset(&s32g2_console, 0, sizeof(s32g2_console)); 18 19 ret = console_linflex_register(UART_BASE, UART_CLOCK_HZ, 20 UART_BAUDRATE, &s32g2_console); 21 if (ret == 0) { 22 panic(); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2…

1 year, 1 month

1
0
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 7 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 14 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 7 of 7 defect(s) ** CID 425803: Control flow issues (DEADCODE) /mbedtls/library/psa_crypto_aead.c: 314 in mbedtls_psa_aead_decrypt() ________________________________________________________________________________________________________ *** CID 425803: Control flow issues (DEADCODE) /mbedtls/library/psa_crypto_aead.c: 314 in mbedtls_psa_aead_decrypt() 308 } 309 310 exit: 311 mbedtls_psa_aead_abort(&operation); 312 313 if (status == PSA_SUCCESS) { >>> CID 425803: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "*plaintext_length = ciphert...". 314 *plaintext_length = ciphertext_length - operation.tag_length; 315 } 316 return status; 317 } 318 319 /* Set the key and algorithm for a multipart authenticated encryption ** CID 425802: Control flow issues (DEADCODE) /mbedtls/library/x509_crt.c: 2750 in x509_inet_pton_ipv6() ________________________________________________________________________________________________________ *** CID 425802: Control flow issues (DEADCODE) /mbedtls/library/x509_crt.c: 2750 in x509_inet_pton_ipv6() 2744 MBEDTLS_PUT_UINT16_BE(group, addr, nonzero_groups); 2745 nonzero_groups++; 2746 if (*p == '\0') { 2747 break; 2748 } else if (*p == '.') { 2749 /* Don't accept IPv4 too early or late */ >>> CID 425802: Control flow issues (DEADCODE) >>> Execution cannot reach the expression "zero_group_start == -1" inside this statement: "if ((nonzero_groups == 0 &&...". 2750 if ((nonzero_groups == 0 && zero_group_start == -1) || 2751 nonzero_groups >= 7) { 2752 break; 2753 } 2754 2755 /* Walk back to prior ':', then parse as IPv4-mapped */ ** CID 425801: Control flow issues (UNREACHABLE) /mbedtls/library/psa_crypto_aead.c: 306 in mbedtls_psa_aead_decrypt() ________________________________________________________________________________________________________ *** CID 425801: Control flow issues (UNREACHABLE) /mbedtls/library/psa_crypto_aead.c: 306 in mbedtls_psa_aead_decrypt() 300 (void) additional_data; 301 (void) additional_data_length; 302 (void) plaintext; 303 return PSA_ERROR_NOT_SUPPORTED; 304 } 305 >>> CID 425801: Control flow issues (UNREACHABLE) >>> This code cannot be reached: "if (status == 0) { *plain...". 306 if (status == PSA_SUCCESS) { 307 *plaintext_length = ciphertext_length - operation.tag_length; 308 } 309 310 exit: 311 mbedtls_psa_aead_abort(&operation); ** CID 425800: Control flow issues (UNREACHABLE) /mbedtls/library/psa_crypto_aead.c: 612 in mbedtls_psa_aead_finish() ________________________________________________________________________________________________________ *** CID 425800: Control flow issues (UNREACHABLE) /mbedtls/library/psa_crypto_aead.c: 612 in mbedtls_psa_aead_finish() 606 (void) tag_size; 607 (void) tag_length; 608 609 return PSA_ERROR_NOT_SUPPORTED; 610 } 611 >>> CID 425800: Control flow issues (UNREACHABLE) >>> This code cannot be reached: "if (status == 0) { *ciphe...". 612 if (status == PSA_SUCCESS) { 613 /* This will be zero for all supported algorithms currently, but left 614 * here for future support. */ 615 *ciphertext_length = finish_output_size; 616 *tag_length = operation->tag_length; 617 } ** CID 425799: Control flow issues (UNREACHABLE) /mbedtls/library/psa_crypto_aead.c: 110 in psa_aead_setup() ________________________________________________________________________________________________________ *** CID 425799: Control flow issues (UNREACHABLE) /mbedtls/library/psa_crypto_aead.c: 110 in psa_aead_setup() 104 default: 105 (void) status; 106 (void) key_buffer; 107 return PSA_ERROR_NOT_SUPPORTED; 108 } 109 >>> CID 425799: Control flow issues (UNREACHABLE) >>> This code cannot be reached: "operation->key_type = psa_g...". 110 operation->key_type = psa_get_key_type(attributes); 111 112 operation->tag_length = PSA_ALG_AEAD_GET_TAG_LENGTH(alg); 113 114 return PSA_SUCCESS; 115 } ** CID 425798: Control flow issues (UNREACHABLE) /mbedtls/library/psa_crypto_aead.c: 541 in mbedtls_psa_aead_update() ________________________________________________________________________________________________________ *** CID 425798: Control flow issues (UNREACHABLE) /mbedtls/library/psa_crypto_aead.c: 541 in mbedtls_psa_aead_update() 535 (void) output; 536 (void) output_size; 537 538 return PSA_ERROR_NOT_SUPPORTED; 539 } 540 >>> CID 425798: Control flow issues (UNREACHABLE) >>> This code cannot be reached: "if (status == 0) { *outpu...". 541 if (status == PSA_SUCCESS) { 542 *output_length = update_output_length; 543 } 544 545 return status; 546 } ** CID 425797: Control flow issues (UNREACHABLE) /mbedtls/library/psa_crypto_aead.c: 196 in mbedtls_psa_aead_encrypt() ________________________________________________________________________________________________________ *** CID 425797: Control flow issues (UNREACHABLE) /mbedtls/library/psa_crypto_aead.c: 196 in mbedtls_psa_aead_encrypt() 190 (void) additional_data; 191 (void) additional_data_length; 192 (void) plaintext; 193 return PSA_ERROR_NOT_SUPPORTED; 194 } 195 >>> CID 425797: Control flow issues (UNREACHABLE) >>> This code cannot be reached: "if (status == 0) { *ciphe...". 196 if (status == PSA_SUCCESS) { 197 *ciphertext_length = plaintext_length + operation.tag_length; 198 } 199 200 exit: 201 mbedtls_psa_aead_abort(&operation); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2…

1 year, 1 month

1
0
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

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 425708: Null pointer dereferences (NULL_RETURNS) ________________________________________________________________________________________________________ *** CID 425708: Null pointer dereferences (NULL_RETURNS) /plat/xilinx/zynqmp/pm_service/zynqmp_pm_api_sys.c: 279 in pm_self_suspend() 273 const struct pm_proc *proc = pm_get_proc(cpuid); 274 275 /* 276 * Do client specific suspend operations 277 * (e.g. set powerdown request bit) 278 */ >>> CID 425708: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a pointer that might be "NULL" "proc" when calling "pm_client_suspend". 279 pm_client_suspend(proc, state); 280 /* Send request to the PMU */ 281 PM_PACK_PAYLOAD6(payload, PM_SELF_SUSPEND, proc->node_id, latency, 282 state, address, (address >> 32)); 283 return pm_ipi_send_sync(proc, payload, NULL, 0); 284 } ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2…

1 year, 1 month

1
0
0 0

TF-A Tech Forum : TF-RMM CPPCheck integration and TF-A-Tests testing

by Soby Mathew

Hi Everyone, This Thursday , Shruti from TF-RMM team will discuss the following topics in TF-A Tech Forum : 1. Integration of CPPCheck in TF-RMM * CPPCheck is an open-source static analyzer with addon MISRA checker. In this talk, we will discuss the CPPCheck integration in TF-RMM build system and demonstrate the same. 2. TF-A-Tests enhancements and testing for TF-RMM * Discuss new enhancements in TF-A-Tests for Realm Payload tests including Creating, Loading & Running Realm Payload, testing multiple Rec’s and PSCI support for Realms. We will also cover some Test framework conventions and aspects of Stage2 Memory Management, Realm Memory Exception Model testing. Best Regards Soby Mathew -----Original Appointment----- From: Trusted Firmware Public Meetings <linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com> Sent: Thursday, February 22, 2024 10:13 PM To: Trusted Firmware Public Meetings; tf-a(a)lists.trustedfirmware.org; marek.bykowski(a)gmail.com; okash.khawaja(a)gmail.com Subject: TF-A Tech Forum When: 02 May 2024 16:00-17:00 Europe/London. Where: TF-A Tech Forum 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 This event has been updated with a note: "Updating invite link" Changed: description Description CHANGED 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/<https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…> Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://linaro-org.zoom.us/my/trustedfirmware?pwd=VktXcm5MNUUyVVM4R0k3ZUtvd…<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fmy%2Ftruste…> 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-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> When Every 2 weeks from 9am to 10am on Thursday (Mountain Standard Time - Phoenix) Guests tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> marek.bykowski(a)gmail.com<mailto:marek.bykowski@gmail.com> okash.khawaja(a)gmail.com<mailto:okash.khawaja@gmail.com> View all guest info<https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…> RSVP for tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> for all events in this series Yes<https://calendar.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tM…> No<https://calendar.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tM…> Maybe<https://calendar.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tM…> More options<https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…> 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>

1 year, 1 month

1
0
0 0

Trusted Firmware-A LTS v2.10.4 Release Announcement

by ci_notify＠trustedfirmware.org

The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.

1 year, 1 month

1
0
0 0

Trusted Firmware-A LTS v2.8.18 Release Announcement

by ci_notify＠trustedfirmware.org

Hello, Trusted Firmware-A LTS version 2.8.18 is now available. This release contains the following patches. a1cb5f656 feat(mbedtls): upgrade to version v2.28.8 [1] [1] https://review.trustedfirmware.org/q/Ic1e6debbfc0f5667a8872482ccfb104c1a92e… Thanks, TF-A LTS team

1 year, 1 month

1
0
0 0

Need a mechanism to easily define platform-independent SMC FIDs

by Julius Werner

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?

1 year, 1 month

3
3
0 0

Re: rk3399 issue: no DMA in Linux with mainline TF-A and U-Boot SPL

by Christoph Fritz

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

1 year, 1 month

1
0
0 0

About unmaintained files

by Yann Gautier

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

1 year, 1 month

3
2
0 0

Build failure under yocto

by Ryan Eatmon

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

1 year, 1 month

1
0
0 0

gicv2.h vs gicv3.h conflict

by Jacob Kroon

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

1 year, 1 month

2
2
0 0

Reminder: TrustedFirmware Discord Channel

by don.harbin＠linaro.org

The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.

1 year, 1 month

1
0
0 0

TF-A Tech Forum - Apr 18th at 4.00pm BST

by Olivier Deprez

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

1 year, 1 month

1
0
0 0

el3 secure memory access from lower exception levels.

by Nagal, Amit

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

1 year, 1 month

4
9
0 0

Trusted Firmware-A LTS v2.8.17 Release Announcement

by Varun Wadekar

1 year, 2 months

1
0
0 0

Patch for fixing SGIR_NSATT bitshift

by Jacob Kroon

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

1 year, 2 months

2
2
0 0

L3 cache flush

by Nagal, Amit

Hi, Referring https://github.com/ARM-software/arm-trusted-firmware/blob/master/lib/cpus/a… Software cache maintenance is done till L3 . Referring https://github.com/ARM-software/arm-trusted-firmware/blob/master/lib/cpus/a… for cortex a78 , it is mentioned that HW will do the cache maintenance . is HW cache maintenance done till L3 for cortex a78 case too ? Regards Amit

1 year, 2 months

2
2
0 0

Trusted Firmware-A LTS v2.10.3 Release Announcement

by Yann GAUTIER - foss

Hello, Trusted Firmware-A LTS version 2.10.3 is now available. This release contains the following patches. 5f8f745c7 fix(cpus): workaround for Cortex-X3 erratum 2372204 [1] 301698e15 fix(cpus): workaround for Cortex-A715 erratum 2429384 [2] 9fe65073d refactor(errata-abi): optimize errata ABI using errata framework [3] a24c8006e refactor(errata-abi): workaround platforms non-arm interconnect [4] a234f540b fix(cpus): add erratum 2701951 to Cortex-X3's list [5] 58646309a chore: rearrange the fvp_cpu_errata.mk file [6] b7ed781ee fix(gic600): workaround for Part 1 of GIC600 erratum 2384374 [7] 04c60d5ef fix(cpus): workaround for Cortex-A715 erratum 2420947 [8] 940ebbe2d fix(cpus): workaround for Cortex-A715 erratum 2331818 [9] d466c5d4d fix(cpus): workaround for Cortex-X4 erratum 2701112 [10] 3e3ff298a fix(cpus): workaround for Cortex-A715 erratum 2344187 [11] 11cb0962f docs(threat_model): mark power analysis threats out-of-scope [12] 44f36c48f docs(sdei): provide security guidelines when using SDEI [13] b59307ef8 fix(cpus): workaround for Cortex-A715 erratum 2413290 [14] e86990d09 fix(cpus): fix a defect in Cortex-A715 erratum 2561034 [15] 03636f2c3 fix(cpus): workaround for Cortex-A720 erratum 2940794 [16] 635c83eb4 chore: update status of Cortex-X3 erratum 2615812 [17] baf14745f fix(cpus): workaround for Cortex-A720 erratum 2926083 [18] 81931a13a fix(cpus): workaround for Cortex-A715 erratum 2413290 [19] ef393a3f9 fix(cpu): correct variant name for default Poseidon CPU [20] a6256d7a2 feat(cpu): add support for Poseidon V CPU [21] bafc27c8d chore: rename Poseidon to Neoverse V3 [22] d6b1d4807 fix(readme): dummy commit for sandbox release [23] [1] https://review.trustedfirmware.org/q/Iad28f8625c84186fbd8049406d139d4f15c6e… [2] https://review.trustedfirmware.org/q/I3cdb1b71567542174759f6946e9c81f77d0d9… [3] https://review.trustedfirmware.org/q/I1a60d3e4f116b6254fb45426f43ff1b21771a… [4] https://review.trustedfirmware.org/q/Ie86b7212d731a79e2a0c07649e69234e733cd… [5] https://review.trustedfirmware.org/q/I6ffaf4360a4a2d0a23c253a2326c178e010c8… [6] https://review.trustedfirmware.org/q/I3959bdf5852c5714f2238f61493a931b3c857… [7] https://review.trustedfirmware.org/q/I4bb6dcf86c94125cbc574e0dc5119abe43e84… [8] https://review.trustedfirmware.org/q/I01a71b878cd958e742ff8357f8cdfbfc5625d… [9] https://review.trustedfirmware.org/q/If3b1ed78b145ab6515cdd41135314350ed556… [10] https://review.trustedfirmware.org/q/I8ede1ee75b0ea1658369a0646d8af91d44a87… [11] https://review.trustedfirmware.org/q/I78ea39a91254765c964bff89f771af33b23f2… [12] https://review.trustedfirmware.org/q/I5b245f33609fe8948e473ce4484898db5ff8d… [13] https://review.trustedfirmware.org/q/Ic27bdc88186f6805adee2f452503856e213a4… [14] https://review.trustedfirmware.org/q/Iaeb258c8b0a92e93d70b7dad6ba59d1056aeb… [15] https://review.trustedfirmware.org/q/I4f115bbb27c57f16cada2a7eb314af8380f93… [16] https://review.trustedfirmware.org/q/I1488802e0ec7c16349c9633bb45de4d0e1faa… [17] https://review.trustedfirmware.org/q/Ied7150bab505a743401cf4afa9a0a5f81d5fd… [18] https://review.trustedfirmware.org/q/I30182c3893416af65b55fca9a913cb4512430… [19] https://review.trustedfirmware.org/q/I87b2175b89d6fb168c77e6ab233c90ca05679… [20] https://review.trustedfirmware.org/q/I48183290ffc2889d6ae000d3aa423c0ee5e4d… [21] https://review.trustedfirmware.org/q/Icdcc5f57c62855b2ec54c58a401d3bf09f292… [22] https://review.trustedfirmware.org/q/I9e40ba8f80b7390703d543787e6cd2ab6301e… [23] https://review.trustedfirmware.org/q/Ib36e14779e2cdf42cfd9d5690ca8d0288689c… TF-A-tests LTS version 2.10.3 contains the following patches. 2162802 refactor(errata_abi): update the cpu structs for errata ABI [24] 9135090 refactor(errata_abi): add the Cortex-X4 cpu struct [25] [24] https://review.trustedfirmware.org/q/I4650a88003db2ded9277b35c7fc521026fe4a… [25] https://review.trustedfirmware.org/q/I8421dcc98eea85d038070f90e819e91bb2652… TF-A-ci-scripts LTS version 2.10.3 contains the following patches. 7a33284 fix(fvp): remove fvp-tc.crash-linux.tc-fip.tc-tc2-debug [26] 4ffc461 ci(errata_abi): update testconfig for errata ABI [27] a295862 ci: create groups for Arm platforms and partner boards [28] e78b129 lts: new downloads area for LTS v2.10 [29] 3dc2907 tf-l3-boot-tests-css: Remove TC1/TC2 configs [30] ae4d470 expect-lava/linux.inc: Fail-fast on kernel panic [31] 32fac0c fvp-tftf.cactus_mm: Increase timeout to 900s [32] f818c0e fvp-tftf.cactus_mm: Increase timeout to 720s [33] 80294ea fvp-tftf.cactus_mm: Further increase timeout for this test to 600s [34] 3a5cbe9 expect-lava: Propagate failure clauses to all TFTF test snippets [35] a2ee841 run_config/fvp-tftf.cactus_mm: Set lava_timeout="450" [36] 052f1bb fix: check and initialise spm submodules [37] [26] https://review.trustedfirmware.org/q/Ifd3fda7e18d2135287371f2e991e29e1d7e70… [27] https://review.trustedfirmware.org/q/I5635916abe03676316488b0321f0d8757bf07… [28] https://review.trustedfirmware.org/q/I8cfa16de1dd09981b5a5ffdc9cf79b19e789b… [29] https://review.trustedfirmware.org/q/I0280c4f6d286b4bf0fb13490e7234004bdd32… [30] https://review.trustedfirmware.org/q/Ia213695824ef8923edd2ca4e924e44b10ad4e… [31] https://review.trustedfirmware.org/q/Ib89948e0a0c9b1a9fa1eed8bf02b6b88f70a3… [32] https://review.trustedfirmware.org/q/I10d9e1b62456ecd2908b08287a23ebccdb261… [33] https://review.trustedfirmware.org/q/I1f796b06ddac1ab66e3e5090dbf1da8ec718e… [34] https://review.trustedfirmware.org/q/I8e792a07928c0f63954e8c166300614cef292… [35] https://review.trustedfirmware.org/q/I1a19e7e21d7db3527d24624a16d6ed442ec2f… [36] https://review.trustedfirmware.org/q/Id582f8712fb50fd58e00d49c65dcecb753141… [37] https://review.trustedfirmware.org/q/If07fb5c721b699bf80bd7fe5f54fad5ad16ed… Thanks, TF-A LTS team

1 year, 2 months

1
0
0 0

Canceled event with note: TF-A Tech Forum @ Thu Apr 4, 2024 5pm - 6pm (GMT+2) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

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

1 year, 2 months

1
0
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

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…

1 year, 2 months

1
0
0 0

Deprecating ENABLE_FEAT_MTE build option

by Govindraj Raja

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

1 year, 2 months

1
0
0 0

RAS exceptions TRAP at EL3

by Nagal, Amit

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

1 year, 2 months

2
3
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

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…

1 year, 2 months

1
0
0 0

Canceled event with note: TF-A Tech Forum @ Thu Mar 21, 2024 5pm - 6pm (GMT+1) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

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

1 year, 2 months

1
0
0 0

Question about RME-DA in TF-A/TF-RMM/FVP

by Chenxu Wang

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

1 year, 2 months

2
1
0 0

Compatibility support for SPM_MM and SPMD

by baopeng (A)

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?

1 year, 3 months

2
2
0 0

Updated invitation with note: TF-A Tech Forum @ Every 2 weeks from 9am to 10am on Thursday (MST) (tf-a@lists.trustedfirmware.org)

by Don Harbin

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

1 year, 3 months

2
2
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

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…

1 year, 3 months

1
0
0 0

ENABLE_LTO feature usage.

by Kummari, Prasad

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.

1 year, 3 months

4
10
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

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…

1 year, 3 months

1
0
0 0

mbedtls and PQC algorithms support

by shripad.nunjundarao＠broadcom.com

Hi, Is there a plan for mbedtls to add support for PQC algorithms (Dilithium/Khyber)? regards, /Shripad

1 year, 3 months

2
1
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 27 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 20 of 27 defect(s) ** CID 415001: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 1922 in upwr_pwm_boot_start() ________________________________________________________________________________________________________ *** CID 415001: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 1922 in upwr_pwm_boot_start() 1916 } 1917 1918 if (api_state != UPWR_API_READY) { 1919 return -3; 1920 } 1921 >>> CID 415001: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(sg_busy & (2U /* 1U << 1U */)) == 1U" is always false regardless of the values of its operands. This occurs as the logical operand of "if". 1922 if (UPWR_SG_BUSY(UPWR_SG_PWRMGMT)) { 1923 return -1; 1924 } 1925 1926 UPWR_USR_CALLB(UPWR_SG_PWRMGMT, (upwr_callb)bootcallb); 1927 ** CID 415000: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 2195 in upwr_pwm_power_on() ________________________________________________________________________________________________________ *** CID 415000: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 2195 in upwr_pwm_power_on() 2189 size_t stsize = 0U; 2190 2191 if (api_state != UPWR_API_READY) { 2192 return -3; 2193 } 2194 >>> CID 415000: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(sg_busy & (2U /* 1U << 1U */)) == 1U" is always false regardless of the values of its operands. This occurs as the logical operand of "if". 2195 if (UPWR_SG_BUSY(UPWR_SG_PWRMGMT)) { 2196 return -1; 2197 } 2198 2199 UPWR_USR_CALLB(UPWR_SG_PWRMGMT, callb); 2200 ** CID 414999: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 2290 in upwr_pwm_power_off() ________________________________________________________________________________________________________ *** CID 414999: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 2290 in upwr_pwm_power_off() 2284 size_t stsize = 0; 2285 2286 if (api_state != UPWR_API_READY) { 2287 return -3; 2288 } 2289 >>> CID 414999: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(sg_busy & (2U /* 1U << 1U */)) == 1U" is always false regardless of the values of its operands. This occurs as the logical operand of "if". 2290 if (UPWR_SG_BUSY(UPWR_SG_PWRMGMT)) { 2291 return -1; 2292 } 2293 2294 UPWR_USR_CALLB(UPWR_SG_PWRMGMT, callb); 2295 ** CID 414998: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /plat/imx/imx8ulp/scmi/scmi_pd.c: 243 in plat_scmi_pd_psw() ________________________________________________________________________________________________________ *** CID 414998: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /plat/imx/imx8ulp/scmi/scmi_pd.c: 243 in plat_scmi_pd_psw() 237 return 0; 238 } 239 240 on = (state == POWER_STATE_ON) ? true : false; 241 242 if ((imx8ulp_psw[psw_parent].flags & ALWAYS_ON) == 0U) { >>> CID 414998: Integer handling issues (OVERFLOW_BEFORE_WIDEN) >>> Potentially overflowing expression "1 << imx8ulp_psw[psw_parent].reg" with type "int" (32 bits, signed) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "uint64_t" (64 bits, unsigned). 243 swt = 1 << imx8ulp_psw[psw_parent].reg; 244 if (imx8ulp_psw[psw_parent].count == 0U) { 245 if (on == false) { 246 WARN("off PSW[%d] that already in off state\n", psw_parent); 247 ret = -EACCES; 248 } else { ** CID 414997: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 1869 in upwr_pwm_dom_power_on() ________________________________________________________________________________________________________ *** CID 414997: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 1869 in upwr_pwm_dom_power_on() 1863 } 1864 1865 if (api_state != UPWR_API_READY) { 1866 return -3; 1867 } 1868 >>> CID 414997: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(sg_busy & (2U /* 1U << 1U */)) == 1U" is always false regardless of the values of its operands. This occurs as the logical operand of "if". 1869 if (UPWR_SG_BUSY(UPWR_SG_PWRMGMT)) { 1870 return -1; 1871 } 1872 1873 UPWR_USR_CALLB(UPWR_SG_PWRMGMT, (upwr_callb)pwroncallb); 1874 ** CID 414996: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 2117 in upwr_pwm_freq_setup() ________________________________________________________________________________________________________ *** CID 414996: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 2117 in upwr_pwm_freq_setup() 2111 upwr_pwm_freq_msg txmsg = {0}; 2112 2113 if (api_state != UPWR_API_READY) { 2114 return -3; 2115 } 2116 >>> CID 414996: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(sg_busy & (2U /* 1U << 1U */)) == 1U" is always false regardless of the values of its operands. This occurs as the logical operand of "if". 2117 if (UPWR_SG_BUSY(UPWR_SG_PWRMGMT)) { 2118 return -1; 2119 } 2120 2121 UPWR_USR_CALLB(UPWR_SG_PWRMGMT, callb); 2122 ** CID 414995: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 2372 in upwr_pwm_mem_retain() ________________________________________________________________________________________________________ *** CID 414995: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 2372 in upwr_pwm_mem_retain() 2366 unsigned long ptrval = 0UL; /* needed for X86, ARM64 */ 2367 2368 if (api_state != UPWR_API_READY) { 2369 return -3; 2370 } 2371 >>> CID 414995: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(sg_busy & (2U /* 1U << 1U */)) == 1U" is always false regardless of the values of its operands. This occurs as the logical operand of "if". 2372 if (UPWR_SG_BUSY(UPWR_SG_PWRMGMT)) { 2373 return -1; 2374 } 2375 2376 UPWR_USR_CALLB(UPWR_SG_PWRMGMT, callb); 2377 ** CID 414994: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 2547 in upwr_pwm_pmode_config() ________________________________________________________________________________________________________ *** CID 414994: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 2547 in upwr_pwm_pmode_config() 2541 unsigned long ptrval = 0UL; /* needed for X86, ARM64 */ 2542 2543 if (api_state != UPWR_API_READY) { 2544 return -3; 2545 } 2546 >>> CID 414994: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(sg_busy & (2U /* 1U << 1U */)) == 1U" is always false regardless of the values of its operands. This occurs as the logical operand of "if". 2547 if (UPWR_SG_BUSY(UPWR_SG_PWRMGMT)) { 2548 return -1; 2549 } 2550 2551 UPWR_USR_CALLB(UPWR_SG_PWRMGMT, callb); 2552 ** CID 414993: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 1812 in upwr_dlm_process_monitor() ________________________________________________________________________________________________________ *** CID 414993: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 1812 in upwr_dlm_process_monitor() 1806 upwr_pmon_msg txmsg = {0}; 1807 1808 if (api_state != UPWR_API_READY) { 1809 return -3; 1810 } 1811 >>> CID 414993: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(sg_busy & (4U /* 1U << 2U */)) == 1U" is always false regardless of the values of its operands. This occurs as the logical operand of "if". 1812 if (UPWR_SG_BUSY(UPWR_SG_DELAYM)) { 1813 return -1; 1814 } 1815 1816 UPWR_USR_CALLB(UPWR_SG_DELAYM, callb); 1817 ** CID 414992: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 1973 in upwr_pwm_param() ________________________________________________________________________________________________________ *** CID 414992: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 1973 in upwr_pwm_param() 1967 upwr_pwm_param_msg txmsg = {0}; 1968 1969 if (api_state != UPWR_API_READY) { 1970 return -3; 1971 } 1972 >>> CID 414992: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(sg_busy & (2U /* 1U << 1U */)) == 1U" is always false regardless of the values of its operands. This occurs as the logical operand of "if". 1973 if (UPWR_SG_BUSY(UPWR_SG_PWRMGMT)) { 1974 return -1; 1975 } 1976 1977 UPWR_USR_CALLB(UPWR_SG_PWRMGMT, callb); 1978 ** CID 414991: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 1511 in upwr_vtm_vmeter_measure() ________________________________________________________________________________________________________ *** CID 414991: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 1511 in upwr_vtm_vmeter_measure() 1505 upwr_volt_vmeter_meas_msg txmsg = {0}; 1506 1507 if (api_state != UPWR_API_READY) { 1508 return -3; 1509 } 1510 >>> CID 414991: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(sg_busy & (8U /* 1U << 3U */)) == 1U" is always false regardless of the values of its operands. This occurs as the logical operand of "if". 1511 if (UPWR_SG_BUSY(UPWR_SG_VOLTM)) { 1512 return -1; 1513 } 1514 1515 UPWR_USR_CALLB(UPWR_SG_VOLTM, callb); 1516 ** CID 414990: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 2775 in upwr_dgn_mode() ________________________________________________________________________________________________________ *** CID 414990: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 2775 in upwr_dgn_mode() 2769 * -3 if called in an invalid API state 2770 */ 2771 int upwr_dgn_mode(upwr_dgn_mode_t mode, const upwr_callb callb) 2772 { 2773 upwr_dgn_mode_msg txmsg = {0}; 2774 >>> CID 414990: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(sg_busy & (64U /* 1U << 6U */)) == 1U" is always false regardless of the values of its operands. This occurs as the logical operand of "if". 2775 if (UPWR_SG_BUSY(UPWR_SG_DIAG)) { 2776 return -1; 2777 } 2778 2779 UPWR_USR_CALLB(UPWR_SG_DIAG, callb); 2780 ** CID 414989: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 1692 in upwr_dlm_get_delay_margin() ________________________________________________________________________________________________________ *** CID 414989: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 1692 in upwr_dlm_get_delay_margin() 1686 upwr_dmeter_get_delay_margin_msg txmsg = {0}; 1687 1688 if (api_state != UPWR_API_READY) { 1689 return -3; 1690 } 1691 >>> CID 414989: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(sg_busy & (4U /* 1U << 2U */)) == 1U" is always false regardless of the values of its operands. This occurs as the logical operand of "if". 1692 if (UPWR_SG_BUSY(UPWR_SG_DELAYM)) { 1693 return -1; 1694 } 1695 1696 UPWR_USR_CALLB(UPWR_SG_DELAYM, callb); 1697 ** CID 414988: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 1632 in upwr_tpm_get_temperature() ________________________________________________________________________________________________________ *** CID 414988: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 1632 in upwr_tpm_get_temperature() 1626 upwr_temp_get_cur_temp_msg txmsg = {0}; 1627 1628 if (api_state != UPWR_API_READY) { 1629 return -3; 1630 } 1631 >>> CID 414988: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(sg_busy & (32U /* 1U << 5U */)) == 1U" is always false regardless of the values of its operands. This occurs as the logical operand of "if". 1632 if (UPWR_SG_BUSY(UPWR_SG_TEMPM)) { 1633 return -1; 1634 } 1635 1636 UPWR_USR_CALLB(UPWR_SG_TEMPM, callb); 1637 ** CID 415014: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 1317 in upwr_vtm_chng_pmic_voltage() ________________________________________________________________________________________________________ *** CID 415014: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 1317 in upwr_vtm_chng_pmic_voltage() 1311 upwr_volt_pmic_set_volt_msg txmsg = {0}; 1312 1313 if (api_state != UPWR_API_READY) { 1314 return -3; 1315 } 1316 >>> CID 415014: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(sg_busy & (8U /* 1U << 3U */)) == 1U" is always false regardless of the values of its operands. This occurs as the logical operand of "if". 1317 if (UPWR_SG_BUSY(UPWR_SG_VOLTM)) { 1318 return -1; 1319 } 1320 1321 UPWR_USR_CALLB(UPWR_SG_VOLTM, callb); 1322 ** CID 415013: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 2727 in upwr_pwm_chng_mem_bias() ________________________________________________________________________________________________________ *** CID 415013: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 2727 in upwr_pwm_chng_mem_bias() 2721 upwr_pwm_mem_bias_msg txmsg = {0}; 2722 2723 if (api_state != UPWR_API_READY) { 2724 return -3; 2725 } 2726 >>> CID 415013: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(sg_busy & (2U /* 1U << 1U */)) == 1U" is always false regardless of the values of its operands. This occurs as the logical operand of "if". 2727 if (UPWR_SG_BUSY(UPWR_SG_PWRMGMT)) { 2728 return -1; 2729 } 2730 2731 UPWR_USR_CALLB(UPWR_SG_PWRMGMT, callb); 2732 ** CID 415012: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 2674 in upwr_pwm_chng_dom_bias() ________________________________________________________________________________________________________ *** CID 415012: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 2674 in upwr_pwm_chng_dom_bias() 2668 upwr_pwm_dom_bias_msg txmsg = {0}; 2669 2670 if (api_state != UPWR_API_READY) { 2671 return -3; 2672 } 2673 >>> CID 415012: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(sg_busy & (2U /* 1U << 1U */)) == 1U" is always false regardless of the values of its operands. This occurs as the logical operand of "if". 2674 if (UPWR_SG_BUSY(UPWR_SG_PWRMGMT)) { 2675 return -1; 2676 } 2677 2678 UPWR_USR_CALLB(UPWR_SG_PWRMGMT, callb); 2679 ** CID 415011: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 1559 in upwr_vtm_pmic_config() ________________________________________________________________________________________________________ *** CID 415011: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 1559 in upwr_vtm_pmic_config() 1553 unsigned long ptrval = 0UL; /* needed for X86, ARM64 */ 1554 1555 if (api_state != UPWR_API_READY) { 1556 return -3; 1557 } 1558 >>> CID 415011: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(sg_busy & (8U /* 1U << 3U */)) == 1U" is always false regardless of the values of its operands. This occurs as the logical operand of "if". 1559 if (UPWR_SG_BUSY(UPWR_SG_VOLTM)) { 1560 return -1; 1561 } 1562 1563 UPWR_USR_CALLB(UPWR_SG_VOLTM, callb); 1564 ** CID 415010: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 2616 in upwr_pwm_reg_config() ________________________________________________________________________________________________________ *** CID 415010: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 2616 in upwr_pwm_reg_config() 2610 unsigned long ptrval = 0UL; /* needed for X86, ARM64 */ 2611 2612 if (api_state != UPWR_API_READY) { 2613 return -3; 2614 } 2615 >>> CID 415010: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(sg_busy & (2U /* 1U << 1U */)) == 1U" is always false regardless of the values of its operands. This occurs as the logical operand of "if". 2616 if (UPWR_SG_BUSY(UPWR_SG_PWRMGMT)) { 2617 return -1; 2618 } 2619 2620 UPWR_USR_CALLB(UPWR_SG_PWRMGMT, callb); 2621 ** CID 415009: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 1443 in upwr_vtm_power_measure() ________________________________________________________________________________________________________ *** CID 415009: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 1443 in upwr_vtm_power_measure() 1437 upwr_volt_pmeter_meas_msg txmsg = {0}; 1438 1439 if (api_state != UPWR_API_READY) { 1440 return -3; 1441 } 1442 >>> CID 415009: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(sg_busy & (8U /* 1U << 3U */)) == 1U" is always false regardless of the values of its operands. This occurs as the logical operand of "if". 1443 if (UPWR_SG_BUSY(UPWR_SG_VOLTM)) { 1444 return -1; 1445 } 1446 1447 UPWR_USR_CALLB(UPWR_SG_VOLTM, callb); 1448 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2…

1 year, 3 months

1
0
0 0

All if...else if constructs shall be terminated with an else statement.

by Nithin G

Hello, In the file lib/xlat_tables/xlat_tables_common.c and other associated files, there are instances where if...else if constructs lack an else statement, resulting in violations during the Coverity MISRA-C analysis for the ZynqMP platform. Addressing this issue added empty else statement to resolve the issue but it is related to core translational table logic function. Is it possible to address this issue? Please provide your suggestions. Regards, Nithin G

1 year, 3 months

4
12
0 0

TF-A Node.js migration to v20

by Chris Kay

Hi folks, If you don’t use any of the JavaScript-based tooling from the TF-A repository then you can safely ignore this. I’ve just updated TF-A’s Node.js dependencies, including the minimum version of Node.js required to use the JavaScript-based hooks and tooling from the repository (previously v16, now v20). If you use these and you find that they have started throwing errors, make sure that you are rebased on the latest version of the integration branch, and then run: npm ci If you need to commit changes while the tools are erroring, you can commit with the `-n` flag to skip the commit hooks: git commit -n <usual commit flags…> Please let me know if you run into any issues. Cheers, Chris

1 year, 3 months

1
0
0 0

Compatibility support for SPM_MM and SPMD

by baopeng (A)

Hi Olivier Deprez, One more question, the SPM_MM code will not be removed from the main repository, right? ________________________________ 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.html...<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@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org Sent: 21 February 2024 07:10 To: tf-a(a)lists.trustedfirmware.org tf-a@lists.trustedfirmware.orgmailto: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?

1 year, 3 months

2
1
0 0

Updated invitation: TF-A Tech Forum @ Every 2 weeks from 9am to 10am on Thursday (MST) (tf-a@lists.trustedfirmware.org)

by Don Harbin

This event has been updated 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

1 year, 3 months

1
0
0 0

Updated invitation: TF-A Tech Forum @ Every 2 weeks from 8am to 9am on Thursday (MST) (tf-a@lists.trustedfirmware.org)

by Don Harbin

This event has been updated TF-A Tech Forum Every 2 weeks from 8am to 9am 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/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 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

1 year, 3 months

1
0
0 0

FW: Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a@lists.trustedfirmware.org)

by Bipin Ravi

Hi all, Please use this link for the Tech Forum https://armltd.zoom.us/j/97580924908?pwd=VkVXL2pxemJJYVhieUovRmF4QTU3UT09&f… Bipin -----Original Appointment----- From: Trusted Firmware Public Meetings <linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com> Sent: Thursday, July 16, 2020 11:22 AM To: Trusted Firmware Public Meetings; Bipin Ravi; John Powell; tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a(a)lists.trustedfirmware.org) When: Thursday, February 22, 2024 4:00 PM-5:00 PM Europe/London. Where: Forwarding as it seems you guys still have the old one in your calendars. You have to accept this one and delete the old one. Don't blame me blame Linaro as its their invite and they said they sent it to everybody on the TF-A ML.... Will send you the link to the zoom recording once it comes through to me as it takes a few days to get the webpages up dated. Joanna From: linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com<mailto:linaro.org_havjv2figrh5egaiurb229pd8c@group.calendar.google.com> When: 16:00 - 17:00 18 June 2020 Subject: [TF-A] Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>) You have been invited to the following event. TF-A Tech Forum When Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time Calendar tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Who * Bill Fletcher- creator * tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> more details ><https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> 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/<https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…> Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…> Meeting ID: 915 970 4974 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-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> Going (tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>)? All events in this series: Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> more options ><https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> Invitation from Google Calendar<https://www.google.com/calendar/> You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more<https://support.google.com/calendar/answer/37135#forwarding>. ________________________________ From: Trusted Firmware Public Meetings Sent: Sunday, June 14, 2020 5:21:25 PM (UTC) Coordinated Universal Time To: Trusted Firmware Public Meetings; tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Subject: [TF-A] Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>) When: Occurs on Thursday every other week from 4:00 PM to 5:00 PM effective 6/18/2020. Europe/London Where: You have been invited to the following event. TF-A Tech Forum When Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time Calendar tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Who * Bill Fletcher- creator * tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> more details ><https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> 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/<https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…> Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…> Meeting ID: 915 970 4974 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-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> Going (tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>)? All events in this series: Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> more options ><https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> Invitation from Google Calendar<https://www.google.com/calendar/> You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more<https://support.google.com/calendar/answer/37135#forwarding>.

1 year, 3 months

1
0
0 0

TF-A Tech Forum - Feb 22nd 4.00pm BST

by Olivier Deprez

Hi, In the TF-A Tech Forum today Feb, 22nd 4.00pm BST, Harrison Mutai and Manish Pandey will present the Firmware hand-off framework: The presentation will address the firmware handoff framework’s objectives, key concepts, progress on FVP platform support, and plans for wider adoption across other firmware components and Arm platforms. Regards, Olivier. TF-A Tech Forum Thursday Feb 22, 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/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 tf-a(a)lists.trustedfirmware.org marek.bykowski(a)gmail.com okash.khawaja(a)gmail.com

1 year, 3 months

1
0
0 0

Re: Request for help

by baopeng (A)

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(a)huawei.com<mailto:baopeng1@huawei.com> Sent: 20 February 2024 02:19 To: tf-a-owner(a)lists.trustedfirmware.org tf-a-owner(a)lists.trustedfirmware.org<mailto: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?

1 year, 3 months

2
1
0 0

Purpose of ENABLE_PIE in TF-A without ASLR

by Igor Zhbanov

Hello, I'm trying to understand the purpose of ENABLE_PIE build flag. IIUC, it makes the BL* executables position-independent. But I could not find any ASLR or some other addresses randomization support. Therefore, could you please clarify, what is the point of building position-independent parts, if (most of the time?) they will be loaded at the fixed addresses? Thank you.

1 year, 3 months

2
1
0 0

Re: Request for help

by Olivier Deprez

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(a)huawei.com> Sent: 20 February 2024 02:19 To: tf-a-owner(a)lists.trustedfirmware.org <tf-a-owner(a)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?

1 year, 3 months

1
0
0 0

Trusted Firmware-A LTS v2.10.2 Release Announcement

by Varun Wadekar

Hello, We are happy to announce the first release for the LTS v2.10 program. The code is available on the lts-v2.10 branch (https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/log/?h=lts-v2.10) and the latest tag is lts-v2.10.2. This release consists of two minor releases due to last minute defect fixes in lts-v2.10.1. The changelog for both the minor releases is pasted below for quick reference and the complete documentation is now available at https://trustedfirmware-a.readthedocs.io/en/lts-v2.10.2/change-log.html. ========================================================= Trusted Firmware-A LTS version 2.10.1 contains the following patches. 402b9a9c0 fix(cpus): workaround for Cortex-X3 erratum 2779509 [1] 25cf2844b fix(cpus): workaround for Neoverse V1 erratum 2348377 [2] 6becda5d1 fix(cpus): workaround for Cortex-A78C erratum 2743232 [3] d36d16751 fix(cpus): workaround for Neoverse V2 erratum 2662553 [4] 9cec5496d feat(security): add support for SLS mitigation [5] f9405375a fix(errata): check for SCU before accessing DSU [6] b7591e16f fix(rk3328): apply ERRATA_A53_1530924 erratum [7] f98185e1e fix(cpus): workaround for Neoverse V2 erratum 2618597 [8] b98d0b2ed docs: fix errata in RMM-EL3 Communication Interface documentation [9] bdedd844c fix(sgi): apply workarounds for N2 CPU erratum [10] e27b8ecc7 fix(cpus): workaround for Cortex-A710 erratum 2778471 [11] b312fa066 fix(cpus): workaround for Cortex-X2 erratum 2778471 [12] 4a9ed7a29 fix(cpus): workaround for Cortex-A520 erratum 2630792 [13] 0685a91fd fix(errata): add Cortex-A520 definitions [14] 8d45e30a7 fix(cpus): workaround for Cortex-A520 erratum 2858100 [15] 4f5ce871f feat(versal): enable errata management feature [16] 88a8cd0e5 fix(cpus): workaround for Cortex X3 erratum 2743088 [17] 744f07ae7 fix(cpus): workaround for Cortex-X3 erratum 2302506 [18] 7c227dc44 fix(cpus): workaround for Cortex-X3 erratum 2266875 [19] 0e5e99476 fix(cpus): workaround for Cortex-A78C erratum 2683027 [20] 35d133415 docs(security): security advisory for CVE-2023-49100 [21] 84fcd0429 fix(cpus): workaround for Cortex X3 erratum 2641945 [22] 5c972dfdf feat(spmd): initialize SCR_EL3.EEL2 bit at RESET [23] 2624951d2 fix(cpus): workaround for Cortex-A715 erratum 2561034 [24] [1] https://review.trustedfirmware.org/q/Id92dbae6f1f313b133ffaa018fbf9c078da55… [2] https://review.trustedfirmware.org/q/Ica402494f78811c85e56a262e1f60b0991516… [3] https://review.trustedfirmware.org/q/Ic62579c2dd69b7a8cbbeaa936f45b2cc94364… [4] https://review.trustedfirmware.org/q/I3bc43e7299c17db8a6771a547515ffb2a172f… [5] https://review.trustedfirmware.org/q/I59f5963c22431571f5aebe7e0c5642b32362f… [6] https://review.trustedfirmware.org/q/I38cee6085d6e49ba23de95b3de08bc98798ab… [7] https://review.trustedfirmware.org/q/Ib4130fd9d4cd16b12322f44e91196607fcb6b… [8] https://review.trustedfirmware.org/q/I23a81275d1e40cae39e6897093d6cdd3e11c0… [9] https://review.trustedfirmware.org/q/I6d6b7ff084cc731470e873cfdf37beeec0d36… [10] https://review.trustedfirmware.org/q/Ib0240f56813a913309e5a6a1902e2990979e9… [11] https://review.trustedfirmware.org/q/Id3bb4a2673e41ff237682e46784d37752daf2… [12] https://review.trustedfirmware.org/q/Ia95f0e276482283bf50e06c58c2bc5faab3f6… [13] https://review.trustedfirmware.org/q/Idb6f32f680ee1378a57c2d2f809ea847fffe5… [14] https://review.trustedfirmware.org/q/I45153a1aa2d6dace38650268a32106f5201f4… [15] https://review.trustedfirmware.org/q/I5a07163f919352583b03328abd5659bf7b268… [16] https://review.trustedfirmware.org/q/I54cda23d699abc0782f44172c28933f5cbb01… [17] https://review.trustedfirmware.org/q/I2c8577e3ca0781af8b1c3912e577d3bd77f92… [18] https://review.trustedfirmware.org/q/I048b830867915b88afa36582c6da05734a56d… [19] https://review.trustedfirmware.org/q/I9c610777e222f57f520d223bb03fc5ad05af1… [20] https://review.trustedfirmware.org/q/I2bf9e675f48b62b4cd203100f7df40f4846aa… [21] https://review.trustedfirmware.org/q/I13fa93a65e5017dae6c837e88cd80bda72d4c… [22] https://review.trustedfirmware.org/q/Ia6d6ac8a66936c63b8aa8d7698b937f42ba8f… [23] https://review.trustedfirmware.org/q/If8b2bdbb19bc65391a33dd34cc9824a0203ae… [24] https://review.trustedfirmware.org/q/I377f250a2994b6ced3ac7d93f947af6ceb690… Trusted Firmware-A LTS version 2.10.2 contains the following patches. 822bfa39c fix(build): move comment for VERSION_PATCH [1] 7bccacdde fix(build): properly manage versions in .versionrc.js [2] e8e5c7759 fix(build): update versions [3] [1] https://review.trustedfirmware.org/q/I4008ccbccd512edf33f67c645b38937ad1af9… [2] https://review.trustedfirmware.org/q/I612338fd2896f3fe614f23d14f56d58d43318… [3] https://review.trustedfirmware.org/q/Ia80bd4b28fbb7402f4ae139512fcd176bad05… Thanks, TF-A LTS team

1 year, 4 months

1
0
0 0

Trusted Firmware-A LTS v2.8.16 Release Announcement

by Varun Wadekar

Hello, Trusted Firmware-A LTS version 2.8.16 is now available. This release contains the following patches. e80174ea9 fix(cpus): workaround for Cortex X3 erratum 2641945 [1] a3cd44292 fix(cpus): workaround for Cortex-A715 erratum 2561034 [2] [1] https://review.trustedfirmware.org/q/Ia6d6ac8a66936c63b8aa8d7698b937f42ba8f… [2] https://review.trustedfirmware.org/q/I377f250a2994b6ced3ac7d93f947af6ceb690… Thanks, TF-A LTS team

1 year, 4 months

1
0
0 0

Canceled event with note: TF-A Tech Forum @ Thu Feb 8, 2024 5pm - 6pm (GMT+1) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

This event has been canceled with a note: "Hi, Cancelling as no topic planned. Regards, Olivier." TF-A Tech Forum Thursday Feb 8, 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/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

1 year, 4 months

1
0
0 0

MMIO with pre/post indexing instructions

by ff

Hi, I am using hypervisors to allow execution of EL3 code directly and had to deal with MMIO caused by instructions that have post-indexing parameters. Xen community had to deal with this in 2022: https://www.mail-archive.com/xen-devel@lists.xenproject.org/msg113335.html This does not cause any trouble and have implemented ways to deal with this expeditiously. Yet, I wonder if it is desirable to from a synchronisation perspective? Cheers FF Compiling TFA 2.10 for PLAT=a80x0_mcbin The following line https://elixir.bootlin.com/arm-trusted-firmware/v2.10.0/source/drivers/marv… Is compiled as: win_reg = mmio_read_32(AMB_WIN_CR_OFFSET(win_id)); 4026d9c: f9470260 ldr x0, [x19, #3584] 4026da0: 9100e002 add x2, x0, #0x38 4026da4: b9400001 ldr w1, [x0] win_reg &= ~WIN_ENABLE_BIT; 4026da8: 121f7821 and w1, w1, #0xfffffffe *(volatile uint32_t*)addr = value; // post-indexing 4026dac: b8008401 str w1, [x0], #8 #gcc --version gcc (Ubuntu 10.3.0-1ubuntu1) 10.3.0 Copyright (C) 2020 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. #objdump --version GNU objdump (GNU Binutils for Ubuntu) 2.36.1 Copyright (C) 2021 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) any later version. This program has absolutely no warranty. #I can’t get access to latests compiler and binutils versions to overcome # « ../.. array subscript 0 is outside array bounds of ‘volatile void[0] » # « ../.. has a LOAD segment with RWX permissions » # so I don’t know if this behaviour is changed when using this latests toolchain

1 year, 4 months

2
5
0 0

Handling of normal world interrupts with BL31 PSCI handler

by caleb.ethridge＠analog.com

Hello, If normal world interrupts are received while invoking TF-A's PSCI reset handler, we have observed that the reset can be aborted. In TF-A's PSCI reset handler, a call out to OP-TEE is made before performing the platform-specific reset: https://github.com/ARM-software/arm-trusted-firmware/blob/master/lib/psci/p… https://github.com/ARM-software/arm-trusted-firmware/blob/master/services/s… When OP-TEE is entered, it is possible to receive foreign (normal world) interrupts, which invokes the procedure described here: https://optee.readthedocs.io/en/3.16.0/architecture/core.html#deliver-non-s… When the SMC call is aborted as described above, this results in the reboot failing. Linux does not retry the PSCI reset (https://github.com/torvalds/linux/blob/master/drivers/firmware/psci/psci.c#…). This makes sense because it is not expecting the SMC call to fail (it expected to make an uninterruptable SMC call into the secure monitor, not a call into OP-TEE). If OP-TEE itself is setup to handle PSCI reset calls, it also handles them in (uninterruptable) SMC context: https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/sm/psci.c#L140 https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/sm/sm_a32.S#L96 Based on this, we see two possible solutions: a) Masking the non-secure interrupts in BL31 while we are doing a reset b) Removing the call to OPTEE in the reset handler so that we never leave the SMC context Which option do you suggest? Or are we missing an important detail here? Thanks, Caleb

1 year, 4 months

6
11
0 0

All if...else if constructs shall be terminated with an else statement.

by Nithin G

Hello, In the file /lib/el3_runtime/aarch64/context_mgmt.c. getting misra_c_2012_rule_15_7_violation: No non-empty terminating "else" statement. during the Coverity MISRA-C analysis. void cm_prepare_el3_exit(uint32_t security_state) { u_register_t sctlr_elx, scr_el3, mdcr_el2; if (security_state == NON_SECURE) { scr_el3 = read_ctx_reg(get_el3state_ctx(ctx), CTX_SCR_EL3); misra_c_2012_rule_15_7_violation: No non-empty terminating "else" statement. if ((scr_el3 & SCR_HCE_BIT) != 0U) { ... ... ... write_sctlr_el2(sctlr_elx); } else if (el_implemented(2) != EL_IMPL_NONE) { el2_unused = true; ... ... ... write_cnthp_ctl_el2(CNTHP_CTL_RESET_VAL & ~(CNTHP_CTL_ENABLE_BIT)); } manage_extensions_nonsecure(el2_unused, ctx); } cm_el1_sysregs_context_restore(security_state); cm_set_next_eret_context(security_state); } Resolution: added empty else statement to resolve the issue. diff --git a/lib/el3_runtime/aarch64/context_mgmt.c b/lib/el3_runtime/aarch64/context_mgmt.c index 8e6bfc5..8996746 100644 --- a/lib/el3_runtime/aarch64/context_mgmt.c +++ b/lib/el3_runtime/aarch64/context_mgmt.c @@ -789,6 +789,8 @@ void cm_prepare_el3_exit(uint32_t security_state) */ write_cnthp_ctl_el2(CNTHP_CTL_RESET_VAL & ~(CNTHP_CTL_ENABLE_BIT)); + } else { + /* To fix the MISRA 15.7 warning - Added an empty else statement */ } manage_extensions_nonsecure(el2_unused, ctx); } -- Is it possible to add an empty else statement in this code? Please suggest. Regards, Nithin G

1 year, 4 months

2
1
0 0

Fw: Trusted Firmware-A LTS v2.8.15 Release Announcement

by Yann GAUTIER - foss

Hello, Trusted Firmware-A LTS version 2.8.15 is now available. This release contains the following patches. 7185d051b fix(docs): add few missed links for Security Advisories [1] 10d738975 docs(security): security advisory for CVE-2023-49100 [2] fc08e1bc4 fix(cpus): workaround for Cortex X3 erratum 2743088 [3] 70bd2640b fix(cpus): workaround for Cortex-X3 erratum 2302506 [4] eadc24b6b fix(cpus): workaround for Cortex-X3 erratum 2266875 [5] 560f14075 fix(cpus): workaround for Cortex-A78C erratum 2683027 [6] bdb731568 docs(changelog): changelog for lts-v2.8.15 release [7] [1] https://review.trustedfirmware.org/q/I9cab72b70a518273cbb1a291142f452198427… [2] https://review.trustedfirmware.org/q/I13fa93a65e5017dae6c837e88cd80bda72d4c… [3] https://review.trustedfirmware.org/q/I2c8577e3ca0781af8b1c3912e577d3bd77f92… [4] https://review.trustedfirmware.org/q/I048b830867915b88afa36582c6da05734a56d… [5] https://review.trustedfirmware.org/q/I9c610777e222f57f520d223bb03fc5ad05af1… [6] https://review.trustedfirmware.org/q/I2bf9e675f48b62b4cd203100f7df40f4846aa… [7] https://review.trustedfirmware.org/q/Ibb920e90a6f44a858b9f4709dbeb22e22ab86… Thanks, TF-A LTS team

1 year, 4 months

1
0
0 0

New ticketing system

by Sandrine Bailleux

Hi all, As you might have heard, developer.trustedfirmware.org is getting deprecated. TF-A project used to make (little) use of its issues tracker at [1]. In replacement, we suggest switching to the issues tracker associated with TF-A Github mirror at [2]. Similarly, for TF-A Tests and TF-A CI scripts repositories, we've now got Github mirrors for these projects as well and associated issues trackers at [3] and [4], which we'd like to start using. If you've opened tickets on developer.trustedfirmware.org in the past, could you please migrate them to Github? We might review the tickets list at some point and migrate remaining ones but your help would be much appreciated! TF-A and TF-A tests documentation are in the process of being updated (see [5] and [6]) to refer to the new ticketing system. Best regards, Sandrine [1] https://developer.trustedfirmware.org/project/board/1/ [2] https://github.com/TrustedFirmware-A/trusted-firmware-a/issues [3] https://github.com/TrustedFirmware-A/tf-a-tests/issues [4] https://github.com/TrustedFirmware-A/tf-a-ci-scripts/issues [5] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/26168 [6] https://review.trustedfirmware.org/c/TF-A/tf-a-tests/+/26169

1 year, 4 months

1
0
0 0

Deprecating CTX_INCLUDE_MTE_REGS build option.

by Govindraj Raja

Hi All, Please note build option CTX_INCLUDE_MTE_REGS is now replaced with ENABLE_FEAT_MTE[1] To avoid breaking any builds for timebeing CTX_INCLUDE_MTE_REGS usage will indirectly enable ENABLE_FEAT_MTE but will produce a build warning. Kindly request anyone using CTX_INCLUDE_MTE_REGS to replace with ENABLE_FEAT_MTE As option CTX_INCLUDE_MTE_REGS backward support will be removed after next release and going forward usage of CTX_INCLUDE_MTE_REGS will not be handled within build. -- Thanks, Govindraj R [1]: https://review.trustedfirmware.org/q/topic:%22gr/refac_mte%22

1 year, 4 months

1
0
0 0

Canceled event with note: TF-A Tech Forum @ Thu Jan 25, 2024 5pm - 6pm (GMT+1) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

This event has been canceled with a note: "Hi, No topic proposed, cancelling. Thanks, Olivier. " TF-A Tech Forum Thursday Jan 25, 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/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

1 year, 4 months

1
0
0 0

Should strscpy() be preferred over strlcpy()?

by Sandrine Bailleux

Hi, Right now, TF-A coding guidelines advocate the use of strlcpy() over strcpy()/strncpy() (see the banned libc functions [1]) for the following reasons: - strlcpy() always null-terminates the destination string, even if it gets truncated. This is safer and less error-prone than leaving it unterminated like strncpy() does in this case. - With strlcpy(), it is possible to detect whether the string was truncated. This is useful in some use cases. - strlcpy() writes a single null-terminating byte into the destination string, whereas strncpy() wastes time writing multiple null-terminating bytes until it fills the destination string. Thus, strlcpy() is more efficient in the case where the source string is shorter than the destination one. There exists another string copy variant: strscpy(). Just like strlcpy(), it is not part of the C standard but most libc implementations provide it. strscpy() has the following advantages over strlcpy(): - strscpy() only reads the specified number of bytes from the source string, whereas strlcpy() reads all of its bytes until it finds a null-terminating byte (this is because it needs to return this information). This opens up a potential security risk if the source string is untrusted and controlled by an attacker, as we might end up reading a lot of memory if proper safeguards are not put in place on the source string prior to calling strlcpy(). Also it causes a performance penalty for reading "useless" bytes from the source string. - Checking for truncation is easier and less error-prone with strscpy() : strscpy() returns an error code (-E2BIG) in case of truncation, whereas strlcpy() requires comparing the return value with the destination string size. For these reasons, it seems to me we should prefer strscpy() over strlcpy() in TF-A code base. Any thoughts? Note that the Linux kernel coding style already goes in that direction. The coding style verification script (checkpatch.pl), which TF-A reuses, will print the following warning message if strlcpy() is used: WARNING: Prefer strscpy over strlcpy - see: https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=V6A6G1oUZcprmk… This got flagged by the OpenCI into some TF-A code review already [2]. If we decide that strlcpy() is fine for TF-A codebase in the end, we'll at least need to find a way to silence this checkpatch.pl warning. AFAICS there is already a switch to this effect so it should just be a matter of adding '--ignore STRLCPY' inside .checkpatch.conf file. Best regards, Sandrine [1] https://trustedfirmware-a.readthedocs.io/en/latest/process/coding-guideline…) [2] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/25551

1 year, 4 months

1
0
0 0

Declaration uses a different parameter type than the function Definition.

by Nithin G

Hello, In the file /plat/xilinx/zynqmp/aarch64/zynqmp_common.c, there is a function named plat_get_syscnt_freq2 with its definition. Simultaneously, the declaration of this function is included in include/plat/common/platform.h with the name plat_get_syscnt_freq2 and a different parameter type, leading to a violation when running the Coverity MISRA-C analysis for the Zynqmp platform. Declaration uses a different parameter type than the function Definition. Addressing this issue by introducing a typedef for plat_get_syscnt_freq2 in platform.h and specifying its type as uint32_t resolves the violation. However, it introduces a challenge for other platforms, as this modification necessitates similar changes across various platforms, causing violations in those areas due to the adjusted typedef. Is it possible to fix with the typedef? Please suggest. Regards, Nithin

1 year, 4 months

3
5
0 0

A project should not contain unused tag declarations.

by Nithin G

Hello, In the file /bl31/interrupt_mgmt.c and /include/drivers/arm/gicv2.h and other files getting misra_c_2012_rule_2_4_violation: Type has tag "intr_type_desc" but that tag is never used. during the Coverity MISRA-C analysis. typedef struct intr_type_desc { interrupt_type_handler_t handler; u_register_t scr_el3[2]; uint32_t flags; } intr_type_desc_t; Resolution: Removed the intr_type_desc variable as it declared it's typedef intr_type_desc_t. typedef struct { interrupt_type_handler_t handler; u_register_t scr_el3[2]; uint32_t flags; } intr_type_desc_t; Is It possible to remove the intr_type_desc variable since it is typedef. Please suggest? Regards, Nithin

1 year, 4 months

3
2
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

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. 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 1 of 1 defect(s) ** CID 414009: (RETURN_LOCAL) /services/std_svc/spm/el3_spmc/spmc_main.c: 1530 in spmc_ffa_console_log() /services/std_svc/spm/el3_spmc/spmc_main.c: 1530 in spmc_ffa_console_log() ________________________________________________________________________________________________________ *** CID 414009: (RETURN_LOCAL) /services/std_svc/spm/el3_spmc/spmc_main.c: 1530 in spmc_ffa_console_log() 1524 } 1525 1526 if ((chars_count == 0) || (chars_count > chars_max)) { 1527 return spmc_ffa_error_return(handle, FFA_ERROR_INVALID_PARAMETER); 1528 } 1529 >>> CID 414009: (RETURN_LOCAL) >>> Using "chars", which points to an out-of-scope variable "registers". 1530 for (size_t i = 0; (i < chars_count) && (chars[i] != '\0'); i++) { 1531 putchar(chars[i]); 1532 } 1533 1534 SMC_RET1(handle, FFA_SUCCESS_SMC32); 1535 } /services/std_svc/spm/el3_spmc/spmc_main.c: 1530 in spmc_ffa_console_log() 1524 } 1525 1526 if ((chars_count == 0) || (chars_count > chars_max)) { 1527 return spmc_ffa_error_return(handle, FFA_ERROR_INVALID_PARAMETER); 1528 } 1529 >>> CID 414009: (RETURN_LOCAL) >>> Using "chars", which points to an out-of-scope variable "registers". 1530 for (size_t i = 0; (i < chars_count) && (chars[i] != '\0'); i++) { 1531 putchar(chars[i]); 1532 } 1533 1534 SMC_RET1(handle, FFA_SUCCESS_SMC32); 1535 } ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 year, 4 months

1
0
0 0

PSCI patches fail TF-A-tests on 2 platform configs

by Yann Gautier

Hi, Patrick has sent 2 correction patches for PSCI stack in OSI mode there: https://review.trustedfirmware.org/q/topic:%22fix_psci_osi%22 But when running CI+2, there are 2 platforms for which 2 PSCI OSI tests are failing: fvp-ext-pstate-ea-el3|fvp-default|fvp-tftf-fip.tftf-cortexa57x4a53x4-debug fvp-ext-pstate-ea-el3|fvp-default|fvp-tftf-fip.tftf-aemv8a-debug I'm not familiar with those test configs, but when checking lava logs, I see those traces for failing tests: 2024-01-11T14:21:59 > Executing 'CPU suspend to powerdown at level 1 in OSI mode' 2024-01-11T14:21:59 INFO: Booting 2024-01-11T14:21:59 INFO: Registered IRQ handler 0x8801b274 for IRQ #7 2024-01-11T14:21:59 INFO: Booting 2024-01-11T14:21:59 INFO: Registered IRQ handler 0x8801b274 for IRQ #7 2024-01-11T14:21:59 INFO: Booting 2024-01-11T14:21:59 INFO: Registered IRQ handler 0x8801b274 for IRQ #7 2024-01-11T14:21:59 INFO: Booting 2024-01-11T14:21:59 INFO: Registered IRQ handler 0x8801b274 for IRQ #7 2024-01-11T14:21:59 INFO: Booting 2024-01-11T14:21:59 INFO: Registered IRQ handler 0x8801b274 for IRQ #7 2024-01-11T14:21:59 INFO: Booting 2024-01-11T14:21:59 INFO: Registered IRQ handler 0x8801b274 for IRQ #7 2024-01-11T14:21:59 INFO: Booting 2024-01-11T14:21:59 INFO: Registered IRQ handler 0x8801b274 for IRQ #7 2024-01-11T14:21:59 INFO: Going into suspend state 2024-01-11T14:22:00 INFO: Going into suspend state 2024-01-11T14:22:00 INFO: Going into suspend state 2024-01-11T14:22:00 INFO: Going into suspend state 2024-01-11T14:22:00 INFO: Going into suspend state 2024-01-11T14:22:00 INFO: Going into suspend state 2024-01-11T14:22:00 INFO: Going into suspend state 2024-01-11T14:22:00 INFO: Resumed from suspend state 2024-01-11T14:22:03 INFO: Going into suspend state 2024-01-11T14:22:03 INFO: Resumed from suspend state 2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7 2024-01-11T14:22:03 INFO: Powering off 2024-01-11T14:22:03 INFO: Resumed from suspend state 2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7 2024-01-11T14:22:03 INFO: Powering off 2024-01-11T14:22:03 INFO: Resumed from suspend state 2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7 2024-01-11T14:22:03 INFO: Powering off 2024-01-11T14:22:03 INFO: Resumed from suspend state 2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7 2024-01-11T14:22:03 INFO: Powering off 2024-01-11T14:22:03 INFO: Resumed from suspend state 2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7 2024-01-11T14:22:03 INFO: Powering off 2024-01-11T14:22:03 INFO: Resumed from suspend state 2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7 2024-01-11T14:22:03 INFO: Powering off 2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7 2024-01-11T14:22:03 INFO: Powering off 2024-01-11T14:22:03 INFO: Resumed from suspend state 2024-01-11T14:22:03 TEST COMPLETE Failed 2024-01-11T14:22:03 Wrong value: expected 0, got -3 2024-01-11T14:22:03 > Executing 'CPU suspend to powerdown at level 2 in OSI mode' 2024-01-11T14:22:03 INFO: Booting 2024-01-11T14:22:03 INFO: Registered IRQ handler 0x8801b274 for IRQ #7 2024-01-11T14:22:03 INFO: Booting 2024-01-11T14:22:03 INFO: Registered IRQ handler 0x8801b274 for IRQ #7 2024-01-11T14:22:03 INFO: Booting 2024-01-11T14:22:03 INFO: Registered IRQ handler 0x8801b274 for IRQ #7 2024-01-11T14:22:03 INFO: Booting 2024-01-11T14:22:03 INFO: Registered IRQ handler 0x8801b274 for IRQ #7 2024-01-11T14:22:03 INFO: Booting 2024-01-11T14:22:03 INFO: Registered IRQ handler 0x8801b274 for IRQ #7 2024-01-11T14:22:03 INFO: Booting 2024-01-11T14:22:03 INFO: Registered IRQ handler 0x8801b274 for IRQ #7 2024-01-11T14:22:03 INFO: Booting 2024-01-11T14:22:03 INFO: Registered IRQ handler 0x8801b274 for IRQ #7 2024-01-11T14:22:03 INFO: Going into suspend state 2024-01-11T14:22:03 INFO: Going into suspend state 2024-01-11T14:22:03 INFO: Going into suspend state 2024-01-11T14:22:03 INFO: Going into suspend state 2024-01-11T14:22:03 INFO: Going into suspend state 2024-01-11T14:22:03 INFO: Going into suspend state 2024-01-11T14:22:03 INFO: Going into suspend state 2024-01-11T14:22:03 INFO: Resumed from suspend state 2024-01-11T14:22:03 INFO: Going into suspend state 2024-01-11T14:22:03 INFO: Saving system context 2024-01-11T14:22:03 INFO: Resumed from suspend state 2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7 2024-01-11T14:22:03 INFO: Powering off 2024-01-11T14:22:03 INFO: Resumed from suspend state 2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7 2024-01-11T14:22:03 INFO: Powering off 2024-01-11T14:22:03 INFO: Resumed from suspend state 2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7 2024-01-11T14:22:03 INFO: Powering off 2024-01-11T14:22:03 INFO: Resumed from suspend state 2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7 2024-01-11T14:22:03 INFO: Powering off 2024-01-11T14:22:03 INFO: Resumed from suspend state 2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7 2024-01-11T14:22:03 INFO: Powering off 2024-01-11T14:22:03 INFO: Resumed from suspend state 2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7 2024-01-11T14:22:03 INFO: Powering off 2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7 2024-01-11T14:22:03 INFO: Powering off 2024-01-11T14:22:03 INFO: Restoring system context 2024-01-11T14:22:03 INFO: Resumed from suspend state 2024-01-11T14:22:03 TEST COMPLETE Failed 2024-01-11T14:22:03 Wrong value: expected 0, got -3 The "Resumed from suspend state" message interleaved with "Going into suspend state" seem strange, but I cannot say what could be wrong there. Maybe there is something wrong with the TF-A patches? Or the platforms tests or configs need to be updated? If you have any clue that would be very helpful! Thanks, Yann

1 year, 4 months

2
1
0 0

Cache Maintenance For SiP buffers

by Ahmad Fatoum

Hi, I was looking at imx_hab_handler, which forwards calls into the BootROM on i.MX SoCs in response to secure monitor calls. The BootROM call (and thus the SiP call) accepts two pointers as arguments, where it writes data. The plat/imx/imx8m/imx8m*/imx8m*_bl31_setup.c files map the RAM as MT_MEMORY | MT_RW, which would mean that not only is it writable from TF-A side, but it's also mapped cacheable. I see no explicit cache maintenance in the i.MX SiP code for these two pointer arguments and haven't been successful to find where in TF-A core code if at all, complete D-Cache is flushed on SMC exit. Therefore I ask: - Don't shared non-secure memory buffers between EL3 and lower EL require explicit cache maintenance? - Did I miss the place where this cache maintenance is done? - How did it work so far? barebox does explicit flushing before HAB SiP, invalidation after. U-Boot doesn't do cache maintenance. Both apparently work... Thanks, Ahmad --- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |

1 year, 4 months

3
11
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

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 413966: Uninitialized variables (UNINIT) /plat/qemu/qemu_sbsa/sbsa_sip_svc.c: 113 in read_cpuinfo_from_dt() ________________________________________________________________________________________________________ *** CID 413966: Uninitialized variables (UNINIT) /plat/qemu/qemu_sbsa/sbsa_sip_svc.c: 113 in read_cpuinfo_from_dt() 107 108 if (fdt_getprop(dtb, node, "numa-node-id", NULL)) { 109 fdt_read_uint32(dtb, node, "numa-node-id", &nodeid); 110 } 111 112 dynamic_platform_info.cpu[cpu].nodeid = nodeid; >>> CID 413966: Uninitialized variables (UNINIT) >>> Using uninitialized value "mpidr". 113 dynamic_platform_info.cpu[cpu].mpidr = mpidr; 114 115 INFO("CPU %d: node-id: %d, mpidr: %ld\n", cpu, nodeid, mpidr); 116 117 cpu++; 118 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 year, 5 months

1
0
0 0

Canceled event with note: TF-A Tech Forum @ Thu Jan 11, 2024 5pm - 6pm (CET) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

This event has been canceled with a note: "Hi, Cancelling as no topic proposed. Thanks & Regards, Olivier. " TF-A Tech Forum Thursday Jan 11, 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/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

1 year, 5 months

1
0
0 0

Violations MISRA_15.1 and 15.5 when running the Coverity MISRA-C analysis.

by Nithin G

1. misra_c_2012_rule_15_1_violation: Using "goto" statement. In the file common/bl_common.c and other related files, getting misra_c_2012_rule_15_1_violation: Using "goto" statement. during the Coverity MISRA-C analysis. if (...) { goto exit; } exit: some operation Resolution: goto statement is replaced with exit_func() and new variable is introduced to store the return value of exit_func(). exit_func() some operation int ret; if (...) { ret = return value of exit func() } return ret; Is it possible to fix MISRA 15.1 like this in open source? Please suggest. 2. misra_c_2012_rule_15_5_violation: This return statement is not the final statement in the compound statement that forms the body of the function. In the file common/bl_common.c, lib/xlat_tables/aarch64/xlat_tables.c and other related files, getting misra_c_2012_rule_15_5_violation: This return statement is not the final statement in the compound statement that forms the body of the function. during the Coverity MISRA-C analysis. if (...) { return <something> } if (...) { return <something> } return; Resolution: Taken new variable and assign the return result to new variable and calling only one return statement in end of the function. int result; if (...) { result = <something> } else { if (...) { result = <something> } } return result; Is it possible to fix MISRA 15.5 like this in open source? Please suggest. Thanks & Regards, Nithin G

1 year, 5 months

2
3
0 0

Trusted Firmware-A LTS v2.8.14 Release Announcement

by Varun Wadekar

Hello, Trusted Firmware-A LTS version 2.8.14 is now available. This release introduces errata workarounds for Cortex-A520, Cortex-A710, and Neoverse X2 CPUs. The complete list of changes can be found here<https://trustedfirmware-a.readthedocs.io/en/lts-v2.8.14/change-log.html>. Thanks.

1 year, 5 months

1
0
0 0

Minor updates to the tf.org project maintenance

by Sandrine Bailleux

Hello TF-A and TF-M communities, I've done 2 minor updates to the generic tf.org project maintenance process, which TF-A and TF-M both use. Please see the pull request here: https://github.com/TrustedFirmware/tf_docs/pull/1 Please provide your feedback on the pull request, if any. Happy end-of-year celebrations to all! Best regards, Sandrine

1 year, 5 months

1
0
0 0