- TF-A - lists.trustedfirmware.org

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

2 years, 3 months

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

2 years, 3 months

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

2 years, 3 months

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

2 years, 3 months

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

2 years, 3 months

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

2 years, 3 months

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

2 years, 3 months

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

2 years, 4 months

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

2 years, 4 months

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.

2 years, 4 months

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

2 years, 4 months

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

2 years, 4 months

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

2 years, 5 months

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

2 years, 5 months

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

2 years, 5 months

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

2 years, 5 months

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

2 years, 5 months

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.

2 years, 5 months

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

2 years, 5 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. 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…

2 years, 5 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. 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…

2 years, 5 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. 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…

2 years, 5 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 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…

2 years, 5 months

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>

2 years, 5 months

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.

2 years, 5 months

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

2 years, 5 months

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?

2 years, 5 months

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

2 years, 5 months

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

2 years, 6 months

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

2 years, 6 months

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

2 years, 6 months

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.

2 years, 6 months

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

2 years, 6 months

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

2 years, 6 months

4
9
0 0

Trusted Firmware-A LTS v2.8.17 Release Announcement

by Varun Wadekar

2 years, 6 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

2 years, 6 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

2 years, 6 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

2 years, 6 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

2 years, 6 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…

2 years, 6 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

2 years, 6 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

2 years, 6 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…

2 years, 7 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

2 years, 7 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

2 years, 7 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?

2 years, 7 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

2 years, 7 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…

2 years, 7 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.

2 years, 7 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…

2 years, 7 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

2 years, 7 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…

2 years, 7 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

2 years, 7 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

2 years, 7 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?

2 years, 7 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

2 years, 8 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

2 years, 8 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>.

2 years, 8 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

2 years, 8 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?

2 years, 8 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.

2 years, 8 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?

2 years, 8 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

2 years, 8 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

2 years, 8 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

2 years, 8 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

2 years, 8 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

2 years, 8 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

2 years, 8 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

2 years, 8 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

2 years, 8 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

2 years, 8 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

2 years, 8 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

2 years, 9 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

2 years, 9 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

2 years, 9 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…

2 years, 9 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

2 years, 9 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 |

2 years, 9 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…

2 years, 9 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

2 years, 9 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

2 years, 9 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.

2 years, 9 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

2 years, 10 months

1
0
0 0

Stack usage details with armclang TF-A build

by mail2diggi＠gmail.com

Dear all, we want analyze stack usage details when we build TF-A for armclang compiler but we are not able generate stack usage details. sorry for long thread and question please go through and suggest way forward to perform stack analysis with TF-A armclang build. as per https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/initial-… (section 2.3) when CC is set to armclang, GCC linker is used default (since the TF-A build system doesn’t currently support Arm Scatter files) So when we try to generate stack usage details we will not be able to use GCC -fstack-usage and -fdump-ipa-calgraph since CC is set to armclang and these flags will be un-recognized. Since we are building this for armclang we attempted to use following armlinker flags along with -g compiler flag (refer link:https://developer.arm.com/documentation/100748/0607/writing-optimized-…). --info=stack, --calgrapth, --calgraph_output=text But we end up with unrecognized options error for --info=stack, --calgrapth, --calgraph_output=text This error occurs because GCC linker is used default as per above link section 2.3 (since the TF-A build system doesn’t currently support Arm Scatter files) So we end up with not having stack usage details generated. Q1: Any suggestion to generate stack usage when CC=armclang and GCC linker is used by default. Q2: if we attempt to change LD with armlink we will end up with "Fatal error: L6031U: Could not open scatter description file." https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/initial-… section 2.3 suggest that "that the default linker may be manually overridden using the LD variable" can you please let us know how to override LD with armlinker without getting scatter issue. Using: armclang 6.6.2 version. Thank you Shivakumar Diggi

2 years, 10 months

1
0
0 0

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

by Olivier Deprez

This event has been canceled with a note: "Hi, Cancelling the TF-A Tech Forum as no topic planned. Thanks & Regards, Olivier. " TF-A Tech Forum Thursday Dec 14, 2023 ⋅ 5pm – 6pm Central European Time - Paris We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   Guests marek.bykowski(a)gmail.com okash.khawaja(a)gmail.com tf-a(a)lists.trustedfirmware.org ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years, 10 months

1
0
0 0

Function parameter should not be modified.

by Nithin G

Hello, In the file common/bl_common.c and other related files, there are instances where function parameters are being modified. This leads to violations when running the Coverity MISRA-C analysis for the ZynqMP platform. To address this issue a new variable is declared and used to store the value from the argument in the code. Is it possible to fix by taking a new variable? Please provide your suggestions. Regards, Nithin G

2 years, 10 months

2
1
0 0

The condition clause of the for loop does not use the loop counter variable.

by Nithin G

Hello, In the file lib/xlat_tables/xlat_tables_common.c and other related files, the condition clause of the for loop does not use the loop counter variable "mm". This leads to violations when running the Coverity MISRA-C analysis for the ZynqMP platform. Addressing this issue added mm as part of loop counter and this belongs to core translational table logic and other violations also related to this. Is it possible to address this issue? Please provide your suggestions. Regards, Nithin G

2 years, 10 months

2
1
0 0

Trusted Firmware-A LTS v2.8.13 Release Announcement

by Varun Wadekar

Hello, Trusted Firmware-A LTS version 2.8.13 is now available. This release introduces workarounds for new CPU errata for Cortex-A78C, Cortex-X3, and Neoverse V1/V2. It also adds support for the SLS mitigation. The complete list of changes can be found here<https://trustedfirmware-a.readthedocs.io/en/lts-v2.8.13/change-log.html>. Thanks.

2 years, 10 months

1
0
0 0

Function bl31_lib_init() has external linkage but is only used in one translation unit.

by Nithin G

Hello, In the file bl31/bl31_main.c, there is a function named bl31_lib_init with its definition. Simultaneously, the declaration of this function is included in include/bl31/bl31.h since the function bl31_lib_init used only in one translational unit. leading to a violation when running the Coverity MISRA-C analysis for the ZynqMP. Addressing this issue need to remove the declaration of the function from the bl31.h file and making its definition static. To maintain visibility, included a static declaration in the bl31_main.c file. However, it will may impact in future modifications due to the removal of the declaration in bl31.h. Please provide your suggestions. Regards, Nithin

2 years, 10 months

2
2
0 0

Experimental rust-spmc project release

by Imre Kis

Dear All, We would like to announce that we have published an experimental project called rust-spmc which is a S-EL1 FF-A Secure Partition Manager Core implementation in Rust. We started this as a free time project and now we had the opportunity to publish it on trustedfirmware.org. In its current state it has a partial implementation of the FF-A protocol, and it is able to run the secure partitions of Trusted Services with all tests passing on Arm FVP. It also provides the required compartmentalization between the S-EL0 secure partitions. Please note that the project is experimental (i.e. PoC, not suitable for production) and it is currently not scheduled by Arm for further development. The Rust language is an ideal language for implementing firmware components given its lack of undefined behavior and its memory safety guarantees. Our goal was to demonstrate the capabilities of language in a security critical firmware environment and to gather feedback from partners which could open up the possibility of further development of the project. The repository is available here: https://git.trustedfirmware.org/rust-spmc/rust-spmc.git/ We also prepared a readme with instructions for testing the project: https://git.trustedfirmware.org/rust-spmc/rust-spmc.git/about/ Please reach out to us if you are interested in the project or if you have any questions. Regards, Bálint Dobszay & Imre Kis

2 years, 10 months

1
0
0 0

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

by Olivier Deprez

This event has been canceled with a note: "Hi, Cancelling the TF-A Tech Forum as no topic. Thanks & Regards, Olivier. " TF-A Tech Forum Thursday Nov 30, 2023 ⋅ 5pm – 6pm Central European Time - Paris We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   Guests marek.bykowski(a)gmail.com okash.khawaja(a)gmail.com tf-a(a)lists.trustedfirmware.org ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years, 10 months

1
0
0 0

rk3328: WARNING: BL31: cortex_a53: CPU workaround for 1530924 was missing!

by Diederik de Haas

When booting my Pine64 Rock64 (rk3328), I see the following warning: WARNING: BL31: cortex_a53: CPU workaround for 1530924 was missing! That warning is present in u-boot 2023.01 and also in 2023.07. Asking on their IRC channel and they indicated it should be fixed in TF-A. In the source code I saw various commits which all seem a variation of 74665119f04de0cd7c735fa741aff607a4a9fde8 titled "Enable workaround for Cortex-A53 erratum 1530924" But such a commit seems to be missing for the rk3328 platform. I guess a patch like this is needed to fix that? ```patch diff --git a/plat/rockchip/rk3328/platform.mk b/plat/rockchip/rk3328/ platform.mk index 5b4766d51..bd86a1cc8 100644 --- a/plat/rockchip/rk3328/platform.mk +++ b/plat/rockchip/rk3328/platform.mk @@ -65,6 +65,7 @@ include lib/libfdt/libfdt.mk # Enable workarounds for selected Cortex-A53 errata ERRATA_A53_855873 := 1 +ERRATA_A53_1530924 := 1 $(eval $(call add_define,PLAT_EXTRA_LD_SCRIPT)) $(eval $(call add_define,PLAT_SKIP_OPTEE_S_EL1_INT_REGISTER)) ``` The Contributor’s Guide indicates that it requires a Microsoft Github account, so I opted to post a patch to this list. Cheers, Diederik PS: https://developer.trustedfirmware.org/ seems to be full of spam; you may want to look into that.

2 years, 10 months

2
4
0 0

Trusted Firmware-A LTS v2.8.12 Release Announcement

by Varun Wadekar

Hello, Trusted Firmware-A LTS version 2.8.12 is now available. This release removes the Cryptocell driver support and contains fixes for the Tegra platform, the SMCCC library, and SDEI. The complete list of changes can be found here<https://ci-builds.trustedfirmware.org/static-files/DcqMVUzlEWpu-LYx_0-RuHeu…>. Thanks.

2 years, 11 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. 120 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 4 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 120 defect(s) ** CID 408744: (OVERRUN) /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 320 in mv_ddr4_dq_vref_calibration() /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 254 in mv_ddr4_dq_vref_calibration() ________________________________________________________________________________________________________ *** CID 408744: (OVERRUN) /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 320 in mv_ddr4_dq_vref_calibration() 314 (BYTE_HOMOGENEOUS_LOW | BYTE_SPLIT_OUT_MIX)) == 315 (BYTE_HOMOGENEOUS_LOW | BYTE_SPLIT_OUT_MIX)) { 316 if ((dq_vref_start_win[if_id][subphy_num][vref_idx] + 317 dq_vref_end_win[if_id][subphy_num][vref_idx]) / 2 <= 31) { 318 dq_vref_start_win[if_id][subphy_num][vref_idx] += 64; 319 dq_vref_end_win[if_id][subphy_num][vref_idx] += 64; >>> CID 408744: (OVERRUN) >>> Overrunning array "valid_vref_ptr[if_id]" of 9 26-byte elements at element index 12 (byte offset 337) using index "subphy_num" (which evaluates to 12). 320 DEBUG_CALIBRATION 321 (DEBUG_LEVEL_TRACE, 322 ("%s vref_idx %d if %d subphy %d added 64 adlls to window\n", 323 __func__, valid_vref_ptr[if_id][subphy_num][vref_idx], 324 if_id, subphy_num)); 325 } /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 340 in mv_ddr4_dq_vref_calibration() 334 VALIDATE_BUS_ACTIVE(tm->bus_act_mask, subphy_num); 335 DEBUG_CALIBRATION(DEBUG_LEVEL_INFO, 336 ("calculating center of mass for subphy %d, valid window size %d\n", 337 subphy_num, valid_win_size[if_id][subphy_num])); 338 if (valid_vref_cnt[if_id][subphy_num] > 0) { 339 /* calculate center of mass sampling point (t, v) for each subphy */ >>> CID 408744: (OVERRUN) >>> Overrunning array of 234 bytes at byte offset 312 by dereferencing pointer "valid_vref_ptr[if_id][subphy_num]". 340 status = mv_ddr4_center_of_mass_calc(dev_num, if_id, subphy_num, TX_DIR, 341 dq_vref_start_win[if_id][subphy_num], 342 dq_vref_end_win[if_id][subphy_num], 343 valid_vref_ptr[if_id][subphy_num], 344 valid_vref_cnt[if_id][subphy_num], 345 &center_vref[if_id][subphy_num], /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 254 in mv_ddr4_dq_vref_calibration() 248 if (vref_state_per_subphy[if_id][subphy_num] == MV_DDR4_VREF_SUBPHY_CAL_UNDER) 249 DEBUG_CALIBRATION(DEBUG_LEVEL_ERROR, 250 ("warning: %s: subphy %d vref tap %d voltage noise\n", 251 __func__, subphy_num, vref_tap_idx)); 252 /* window is valid; keep current vref_tap_idx value and increment counter */ 253 vref_idx = valid_vref_cnt[if_id][subphy_num]; >>> CID 408744: (OVERRUN) >>> Overrunning array "valid_vref_ptr[if_id]" of 9 26-byte elements at element index 12 (byte offset 337) using index "subphy_num" (which evaluates to 12). 254 valid_vref_ptr[if_id][subphy_num][vref_idx] = vref_tap_idx; 255 valid_vref_cnt[if_id][subphy_num]++; 256 257 /* set 0 for possible negative values */ 258 vref_byte_status[if_id][subphy_num][vref_idx] |= 259 patterns_byte_status[if_id][subphy_num]; ** CID 408743: Memory - illegal accesses (OVERRUN) /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 693 in mv_ddr4_centralization() ________________________________________________________________________________________________________ *** CID 408743: Memory - illegal accesses (OVERRUN) /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 693 in mv_ddr4_centralization() 687 * that we have already dealt with this bytes by adding 64 adlls 688 * to the low bytes 689 */ 690 if (patterns_byte_status[if_id][subphy_num] & 691 (BYTE_HOMOGENEOUS_LOW | BYTE_SPLIT_OUT_MIX)) 692 patterns_byte_status[if_id][subphy_num] = BYTE_SPLIT_OUT_MIX; >>> CID 408743: Memory - illegal accesses (OVERRUN) >>> Overrunning array "rx_vw_pos[if_id]" of 9 bytes at byte offset 12 using index "subphy_num" (which evaluates to 12). 693 if (rx_vw_pos[if_id][subphy_num] == 0) /* rx_vw_pos is initialized during tap tune */ 694 pbs_max = 31 - 0xa; 695 else 696 pbs_max = 31; 697 698 /* continue if locked */ ** CID 408742: Memory - illegal accesses (OVERRUN) /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 258 in mv_ddr4_dq_vref_calibration() ________________________________________________________________________________________________________ *** CID 408742: Memory - illegal accesses (OVERRUN) /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 258 in mv_ddr4_dq_vref_calibration() 252 /* window is valid; keep current vref_tap_idx value and increment counter */ 253 vref_idx = valid_vref_cnt[if_id][subphy_num]; 254 valid_vref_ptr[if_id][subphy_num][vref_idx] = vref_tap_idx; 255 valid_vref_cnt[if_id][subphy_num]++; 256 257 /* set 0 for possible negative values */ >>> CID 408742: Memory - illegal accesses (OVERRUN) >>> Overrunning array "patterns_byte_status[if_id]" of 9 bytes at byte offset 12 using index "subphy_num" (which evaluates to 12). 258 vref_byte_status[if_id][subphy_num][vref_idx] |= 259 patterns_byte_status[if_id][subphy_num]; 260 dq_vref_start_win[if_id][subphy_num][vref_idx] = 261 c_opt_per_bus[if_id][subphy_num] + 1 - 262 valid_win_size[if_id][subphy_num] / 2; 263 dq_vref_start_win[if_id][subphy_num][vref_idx] = ** CID 408741: Memory - illegal accesses (OVERRUN) /drivers/marvell/mv_ddr/drivers/snps/snps_fw.c: 428 in snps_mail_box_print_major_msg() ________________________________________________________________________________________________________ *** CID 408741: Memory - illegal accesses (OVERRUN) /drivers/marvell/mv_ddr/drivers/snps/snps_fw.c: 428 in snps_mail_box_print_major_msg() 422 * and print the required message string, according to it's message id. */ 423 static void snps_mail_box_print_major_msg(int msg_id) 424 { 425 int major_msg_count = sizeof(mb_major_messages) / sizeof(mb_major_messages[0]); 426 427 for (int i = 0; i <= major_msg_count; i++) >>> CID 408741: Memory - illegal accesses (OVERRUN) >>> Overrunning array "mb_major_messages" of 17 16-byte elements at element index 17 (byte offset 287) using index "i" (which evaluates to 17). 428 if (mb_major_messages[i].message_id == msg_id) { 429 pr_debug("%s\n", mb_major_messages[i].string); 430 return; 431 } 432 433 /* in case msg_id wasn't found in major messages database */ ** CID 408740: (OVERRUN) /drivers/marvell/mv_ddr/mv_ddr_topology.c: 190 in mv_ddr_topology_map_update() /drivers/marvell/mv_ddr/mv_ddr_topology.c: 210 in mv_ddr_topology_map_update() ________________________________________________________________________________________________________ *** CID 408740: (OVERRUN) /drivers/marvell/mv_ddr/mv_ddr_topology.c: 190 in mv_ddr_topology_map_update() 184 /* update bus bit mask in topology map */ 185 tm->bus_act_mask = mv_ddr_bus_bit_mask_get(); 186 187 /* update cs bit mask in topology map */ 188 val = mv_ddr_spd_cs_bit_mask_get(&tm->spd_data); 189 for (i = 0; i < octets_per_if_num; i++) >>> CID 408740: (OVERRUN) >>> Overrunning array "iface_params->as_bus_params" of 9 16-byte elements at element index 12 (byte offset 207) using index "i" (which evaluates to 12). 190 iface_params->as_bus_params[i].cs_bitmask = val; 191 192 /* check dram module type */ 193 val = mv_ddr_spd_module_type_get(&tm->spd_data); 194 switch (val) { 195 case MV_DDR_SPD_MODULE_TYPE_UDIMM: /drivers/marvell/mv_ddr/mv_ddr_topology.c: 210 in mv_ddr_topology_map_update() 204 return -1; 205 } 206 207 /* update mirror bit mask in topology map */ 208 val = mv_ddr_spd_mem_mirror_get(&tm->spd_data); 209 for (i = 0; i < octets_per_if_num; i++) >>> CID 408740: (OVERRUN) >>> Overrunning array "iface_params->as_bus_params" of 9 16-byte elements at element index 12 (byte offset 207) using index "i" (which evaluates to 12). 210 iface_params->as_bus_params[i].mirror_enable_bitmask = val << 1; 211 212 tclk = 1000000 / mv_ddr_freq_get(iface_params->memory_freq); 213 /* update cas write latency (cwl) */ 214 val = mv_ddr_cwl_calc(tclk); 215 if (val == 0) { ** CID 408739: (OVERRUN) /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1614 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1617 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1602 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1463 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1580 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1488 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1611 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1414 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1475 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1608 in ddr3_tip_ip_training_wrapper() ________________________________________________________________________________________________________ *** CID 408739: (OVERRUN) /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1614 in ddr3_tip_ip_training_wrapper() 1608 if (((l2h_adll_value[sybphy_id][bit_id] + 1609 h2l_adll_value[sybphy_id][bit_id]) / 2) > 1610 max_center_subphy_adll[sybphy_id]) 1611 max_center_subphy_adll[sybphy_id] = 1612 (l2h_adll_value[sybphy_id][bit_id] + 1613 h2l_adll_value[sybphy_id][bit_id]) / 2; >>> CID 408739: (OVERRUN) >>> Overrunning array "h2l_adll_value" of 9 8-byte elements at element index 12 (byte offset 103) using index "sybphy_id" (which evaluates to 12). 1614 if (((l2h_adll_value[sybphy_id][bit_id] + 1615 h2l_adll_value[sybphy_id][bit_id]) / 2) < 1616 min_center_subphy_adll[sybphy_id]) 1617 min_center_subphy_adll[sybphy_id] = 1618 (l2h_adll_value[sybphy_id][bit_id] + 1619 h2l_adll_value[sybphy_id][bit_id]) / 2; /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1617 in ddr3_tip_ip_training_wrapper() 1611 max_center_subphy_adll[sybphy_id] = 1612 (l2h_adll_value[sybphy_id][bit_id] + 1613 h2l_adll_value[sybphy_id][bit_id]) / 2; 1614 if (((l2h_adll_value[sybphy_id][bit_id] + 1615 h2l_adll_value[sybphy_id][bit_id]) / 2) < 1616 min_center_subphy_adll[sybphy_id]) >>> CID 408739: (OVERRUN) >>> Overrunning array "h2l_adll_value" of 9 8-byte elements at element index 12 (byte offset 103) using index "sybphy_id" (which evaluates to 12). 1617 min_center_subphy_adll[sybphy_id] = 1618 (l2h_adll_value[sybphy_id][bit_id] + 1619 h2l_adll_value[sybphy_id][bit_id]) / 2; 1620 } 1621 1622 /* calculate the center of the current subphy */ /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1602 in ddr3_tip_ip_training_wrapper() 1596 center_subphy_adll_window[sybphy_id] = 0; 1597 max_center_subphy_adll[sybphy_id] = 0; 1598 min_center_subphy_adll[sybphy_id] = 64; 1599 /* find the max and min center adll value in the current subphy */ 1600 for (bit_id = 0; bit_id < bit_end; bit_id++) { 1601 /* debug print all the bit edges after alignment */ >>> CID 408739: (OVERRUN) >>> Overrunning array "h2l_adll_value" of 9 8-byte elements at element index 12 (byte offset 103) using index "sybphy_id" (which evaluates to 12). 1602 DEBUG_TRAINING_IP_ENGINE 1603 (DEBUG_LEVEL_TRACE, 1604 ("if_id %d sybphy_id %d bit %d l2h %d h2l %d\n", 1605 if_id, sybphy_id, bit_id, l2h_adll_value[sybphy_id][bit_id], 1606 h2l_adll_value[sybphy_id][bit_id])); 1607 /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1463 in ddr3_tip_ip_training_wrapper() 1457 /* low ui */ 1458 if (e1 <= 31 && e2 <= 31) { 1459 bit_state[sybphy_id * BUS_WIDTH_IN_BITS + bit_id] = 1460 BIT_LOW_UI; 1461 byte_status[if_id][sybphy_id] |= BYTE_HOMOGENEOUS_LOW; 1462 l2h_adll_value[sybphy_id][bit_id] = e1; >>> CID 408739: (OVERRUN) >>> Overrunning array "h2l_adll_value" of 9 8-byte elements at element index 12 (byte offset 103) using index "sybphy_id" (which evaluates to 12). 1463 h2l_adll_value[sybphy_id][bit_id] = e2; 1464 DEBUG_TRAINING_IP_ENGINE 1465 (DEBUG_LEVEL_TRACE, 1466 ("if_id %d sybphy_id %d bit %d BIT_LOW_UI\n", 1467 if_id, sybphy_id, bit_id)); 1468 } /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1580 in ddr3_tip_ip_training_wrapper() 1574 TRAINING_LOAD_OPERATION_UNLOAD, CS_SINGLE, 1575 &h2l_if_train_res, 0, cons_tap, 1); 1576 1577 if (MV_OK != status) 1578 return status; 1579 >>> CID 408739: (OVERRUN) >>> Overrunning array "h2l_adll_value" of 9 8-byte elements at element index 12 (byte offset 103) using index "sybphy_id" (which evaluates to 12). 1580 h2l_adll_value[sybphy_id][bit_id] = 1581 h2l_if_train_res[sybphy_id * 1582 BUS_WIDTH_IN_BITS + bit_id] & PUP_RESULT_EDGE_1_MASK; 1583 } 1584 } 1585 } /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1488 in ddr3_tip_ip_training_wrapper() 1482 if (e1 <= 31 && e2 >= 32) { 1483 bit_state[sybphy_id * BUS_WIDTH_IN_BITS + bit_id] = 1484 BIT_SPLIT_IN; 1485 byte_status[if_id][sybphy_id] |= 1486 BYTE_HOMOGENEOUS_SPLIT_IN; 1487 l2h_adll_value[sybphy_id][bit_id] = e1; >>> CID 408739: (OVERRUN) >>> Overrunning array "h2l_adll_value" of 9 8-byte elements at element index 12 (byte offset 103) using index "sybphy_id" (which evaluates to 12). 1488 h2l_adll_value[sybphy_id][bit_id] = e2; 1489 DEBUG_TRAINING_IP_ENGINE 1490 (DEBUG_LEVEL_TRACE, 1491 ("if_id %d sybphy_id %d bit %d BIT_SPLIT_IN\n", 1492 if_id, sybphy_id, bit_id)); 1493 } /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1611 in ddr3_tip_ip_training_wrapper() 1605 if_id, sybphy_id, bit_id, l2h_adll_value[sybphy_id][bit_id], 1606 h2l_adll_value[sybphy_id][bit_id])); 1607 1608 if (((l2h_adll_value[sybphy_id][bit_id] + 1609 h2l_adll_value[sybphy_id][bit_id]) / 2) > 1610 max_center_subphy_adll[sybphy_id]) >>> CID 408739: (OVERRUN) >>> Overrunning array "h2l_adll_value" of 9 8-byte elements at element index 12 (byte offset 103) using index "sybphy_id" (which evaluates to 12). 1611 max_center_subphy_adll[sybphy_id] = 1612 (l2h_adll_value[sybphy_id][bit_id] + 1613 h2l_adll_value[sybphy_id][bit_id]) / 2; 1614 if (((l2h_adll_value[sybphy_id][bit_id] + 1615 h2l_adll_value[sybphy_id][bit_id]) / 2) < 1616 min_center_subphy_adll[sybphy_id]) /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1414 in ddr3_tip_ip_training_wrapper() 1408 bit_end = 0; 1409 1410 /* zero the data base */ 1411 bit_bit_mask[sybphy_id] = 0; 1412 byte_status[if_id][sybphy_id] = BYTE_NOT_DEFINED; 1413 for (bit_id = 0; bit_id < bit_end; bit_id++) { >>> CID 408739: (OVERRUN) >>> Overrunning array "h2l_adll_value" of 9 8-byte elements at element index 12 (byte offset 103) using index "sybphy_id" (which evaluates to 12). 1414 h2l_adll_value[sybphy_id][bit_id] = 64; 1415 l2h_adll_value[sybphy_id][bit_id] = 0; 1416 for (search_dir_id = HWS_LOW2HIGH; search_dir_id <= HWS_HIGH2LOW; 1417 search_dir_id++) { 1418 status = ddr3_tip_read_training_result 1419 (dev_num, if_id, /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1475 in ddr3_tip_ip_training_wrapper() 1469 /* high ui */ 1470 if (e1 >= 32 && e2 >= 32) { 1471 bit_state[sybphy_id * BUS_WIDTH_IN_BITS + bit_id] = 1472 BIT_HIGH_UI; 1473 byte_status[if_id][sybphy_id] |= BYTE_HOMOGENEOUS_HIGH; 1474 l2h_adll_value[sybphy_id][bit_id] = e1; >>> CID 408739: (OVERRUN) >>> Overrunning array "h2l_adll_value" of 9 8-byte elements at element index 12 (byte offset 103) using index "sybphy_id" (which evaluates to 12). 1475 h2l_adll_value[sybphy_id][bit_id] = e2; 1476 DEBUG_TRAINING_IP_ENGINE 1477 (DEBUG_LEVEL_TRACE, 1478 ("if_id %d sybphy_id %d bit %d BIT_HIGH_UI\n", 1479 if_id, sybphy_id, bit_id)); 1480 } /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1608 in ddr3_tip_ip_training_wrapper() 1602 DEBUG_TRAINING_IP_ENGINE 1603 (DEBUG_LEVEL_TRACE, 1604 ("if_id %d sybphy_id %d bit %d l2h %d h2l %d\n", 1605 if_id, sybphy_id, bit_id, l2h_adll_value[sybphy_id][bit_id], 1606 h2l_adll_value[sybphy_id][bit_id])); 1607 >>> CID 408739: (OVERRUN) >>> Overrunning array "h2l_adll_value" of 9 8-byte elements at element index 12 (byte offset 103) using index "sybphy_id" (which evaluates to 12). 1608 if (((l2h_adll_value[sybphy_id][bit_id] + 1609 h2l_adll_value[sybphy_id][bit_id]) / 2) > 1610 max_center_subphy_adll[sybphy_id]) 1611 max_center_subphy_adll[sybphy_id] = 1612 (l2h_adll_value[sybphy_id][bit_id] + 1613 h2l_adll_value[sybphy_id][bit_id]) / 2; ** CID 408738: (OVERRUN) /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1617 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1462 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1614 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1611 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1602 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1474 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1608 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1544 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1487 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1415 in ddr3_tip_ip_training_wrapper() ________________________________________________________________________________________________________ *** CID 408738: (OVERRUN) /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1617 in ddr3_tip_ip_training_wrapper() 1611 max_center_subphy_adll[sybphy_id] = 1612 (l2h_adll_value[sybphy_id][bit_id] + 1613 h2l_adll_value[sybphy_id][bit_id]) / 2; 1614 if (((l2h_adll_value[sybphy_id][bit_id] + 1615 h2l_adll_value[sybphy_id][bit_id]) / 2) < 1616 min_center_subphy_adll[sybphy_id]) >>> CID 408738: (OVERRUN) >>> Overrunning array "l2h_adll_value" of 9 8-byte elements at element index 12 (byte offset 103) using index "sybphy_id" (which evaluates to 12). 1617 min_center_subphy_adll[sybphy_id] = 1618 (l2h_adll_value[sybphy_id][bit_id] + 1619 h2l_adll_value[sybphy_id][bit_id]) / 2; 1620 } 1621 1622 /* calculate the center of the current subphy */ /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1462 in ddr3_tip_ip_training_wrapper() 1456 } else { 1457 /* low ui */ 1458 if (e1 <= 31 && e2 <= 31) { 1459 bit_state[sybphy_id * BUS_WIDTH_IN_BITS + bit_id] = 1460 BIT_LOW_UI; 1461 byte_status[if_id][sybphy_id] |= BYTE_HOMOGENEOUS_LOW; >>> CID 408738: (OVERRUN) >>> Overrunning array "l2h_adll_value" of 9 8-byte elements at element index 12 (byte offset 103) using index "sybphy_id" (which evaluates to 12). 1462 l2h_adll_value[sybphy_id][bit_id] = e1; 1463 h2l_adll_value[sybphy_id][bit_id] = e2; 1464 DEBUG_TRAINING_IP_ENGINE 1465 (DEBUG_LEVEL_TRACE, 1466 ("if_id %d sybphy_id %d bit %d BIT_LOW_UI\n", 1467 if_id, sybphy_id, bit_id)); /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1614 in ddr3_tip_ip_training_wrapper() 1608 if (((l2h_adll_value[sybphy_id][bit_id] + 1609 h2l_adll_value[sybphy_id][bit_id]) / 2) > 1610 max_center_subphy_adll[sybphy_id]) 1611 max_center_subphy_adll[sybphy_id] = 1612 (l2h_adll_value[sybphy_id][bit_id] + 1613 h2l_adll_value[sybphy_id][bit_id]) / 2; >>> CID 408738: (OVERRUN) >>> Overrunning array "l2h_adll_value" of 9 8-byte elements at element index 12 (byte offset 103) using index "sybphy_id" (which evaluates to 12). 1614 if (((l2h_adll_value[sybphy_id][bit_id] + 1615 h2l_adll_value[sybphy_id][bit_id]) / 2) < 1616 min_center_subphy_adll[sybphy_id]) 1617 min_center_subphy_adll[sybphy_id] = 1618 (l2h_adll_value[sybphy_id][bit_id] + 1619 h2l_adll_value[sybphy_id][bit_id]) / 2; /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1611 in ddr3_tip_ip_training_wrapper() 1605 if_id, sybphy_id, bit_id, l2h_adll_value[sybphy_id][bit_id], 1606 h2l_adll_value[sybphy_id][bit_id])); 1607 1608 if (((l2h_adll_value[sybphy_id][bit_id] + 1609 h2l_adll_value[sybphy_id][bit_id]) / 2) > 1610 max_center_subphy_adll[sybphy_id]) >>> CID 408738: (OVERRUN) >>> Overrunning array "l2h_adll_value" of 9 8-byte elements at element index 12 (byte offset 103) using index "sybphy_id" (which evaluates to 12). 1611 max_center_subphy_adll[sybphy_id] = 1612 (l2h_adll_value[sybphy_id][bit_id] + 1613 h2l_adll_value[sybphy_id][bit_id]) / 2; 1614 if (((l2h_adll_value[sybphy_id][bit_id] + 1615 h2l_adll_value[sybphy_id][bit_id]) / 2) < 1616 min_center_subphy_adll[sybphy_id]) /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1602 in ddr3_tip_ip_training_wrapper() 1596 center_subphy_adll_window[sybphy_id] = 0; 1597 max_center_subphy_adll[sybphy_id] = 0; 1598 min_center_subphy_adll[sybphy_id] = 64; 1599 /* find the max and min center adll value in the current subphy */ 1600 for (bit_id = 0; bit_id < bit_end; bit_id++) { 1601 /* debug print all the bit edges after alignment */ >>> CID 408738: (OVERRUN) >>> Overrunning array "l2h_adll_value" of 9 8-byte elements at element index 12 (byte offset 103) using index "sybphy_id" (which evaluates to 12). 1602 DEBUG_TRAINING_IP_ENGINE 1603 (DEBUG_LEVEL_TRACE, 1604 ("if_id %d sybphy_id %d bit %d l2h %d h2l %d\n", 1605 if_id, sybphy_id, bit_id, l2h_adll_value[sybphy_id][bit_id], 1606 h2l_adll_value[sybphy_id][bit_id])); 1607 /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1474 in ddr3_tip_ip_training_wrapper() 1468 } 1469 /* high ui */ 1470 if (e1 >= 32 && e2 >= 32) { 1471 bit_state[sybphy_id * BUS_WIDTH_IN_BITS + bit_id] = 1472 BIT_HIGH_UI; 1473 byte_status[if_id][sybphy_id] |= BYTE_HOMOGENEOUS_HIGH; >>> CID 408738: (OVERRUN) >>> Overrunning array "l2h_adll_value" of 9 8-byte elements at element index 12 (byte offset 103) using index "sybphy_id" (which evaluates to 12). 1474 l2h_adll_value[sybphy_id][bit_id] = e1; 1475 h2l_adll_value[sybphy_id][bit_id] = e2; 1476 DEBUG_TRAINING_IP_ENGINE 1477 (DEBUG_LEVEL_TRACE, 1478 ("if_id %d sybphy_id %d bit %d BIT_HIGH_UI\n", 1479 if_id, sybphy_id, bit_id)); /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1608 in ddr3_tip_ip_training_wrapper() 1602 DEBUG_TRAINING_IP_ENGINE 1603 (DEBUG_LEVEL_TRACE, 1604 ("if_id %d sybphy_id %d bit %d l2h %d h2l %d\n", 1605 if_id, sybphy_id, bit_id, l2h_adll_value[sybphy_id][bit_id], 1606 h2l_adll_value[sybphy_id][bit_id])); 1607 >>> CID 408738: (OVERRUN) >>> Overrunning array "l2h_adll_value" of 9 8-byte elements at element index 12 (byte offset 103) using index "sybphy_id" (which evaluates to 12). 1608 if (((l2h_adll_value[sybphy_id][bit_id] + 1609 h2l_adll_value[sybphy_id][bit_id]) / 2) > 1610 max_center_subphy_adll[sybphy_id]) 1611 max_center_subphy_adll[sybphy_id] = 1612 (l2h_adll_value[sybphy_id][bit_id] + 1613 h2l_adll_value[sybphy_id][bit_id]) / 2; /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1544 in ddr3_tip_ip_training_wrapper() 1538 TRAINING_LOAD_OPERATION_UNLOAD, CS_SINGLE, 1539 &l2h_if_train_res, 0, 0, 1); 1540 1541 if (MV_OK != status) 1542 return status; 1543 >>> CID 408738: (OVERRUN) >>> Overrunning array "l2h_adll_value" of 9 8-byte elements at element index 12 (byte offset 103) using index "sybphy_id" (which evaluates to 12). 1544 l2h_adll_value[sybphy_id][bit_id] = 1545 l2h_if_train_res[sybphy_id * 1546 BUS_WIDTH_IN_BITS + bit_id] & PUP_RESULT_EDGE_1_MASK; 1547 } 1548 } 1549 } /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1487 in ddr3_tip_ip_training_wrapper() 1481 /* split in */ 1482 if (e1 <= 31 && e2 >= 32) { 1483 bit_state[sybphy_id * BUS_WIDTH_IN_BITS + bit_id] = 1484 BIT_SPLIT_IN; 1485 byte_status[if_id][sybphy_id] |= 1486 BYTE_HOMOGENEOUS_SPLIT_IN; >>> CID 408738: (OVERRUN) >>> Overrunning array "l2h_adll_value" of 9 8-byte elements at element index 12 (byte offset 103) using index "sybphy_id" (which evaluates to 12). 1487 l2h_adll_value[sybphy_id][bit_id] = e1; 1488 h2l_adll_value[sybphy_id][bit_id] = e2; 1489 DEBUG_TRAINING_IP_ENGINE 1490 (DEBUG_LEVEL_TRACE, 1491 ("if_id %d sybphy_id %d bit %d BIT_SPLIT_IN\n", 1492 if_id, sybphy_id, bit_id)); /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1415 in ddr3_tip_ip_training_wrapper() 1409 1410 /* zero the data base */ 1411 bit_bit_mask[sybphy_id] = 0; 1412 byte_status[if_id][sybphy_id] = BYTE_NOT_DEFINED; 1413 for (bit_id = 0; bit_id < bit_end; bit_id++) { 1414 h2l_adll_value[sybphy_id][bit_id] = 64; >>> CID 408738: (OVERRUN) >>> Overrunning array "l2h_adll_value" of 9 8-byte elements at element index 12 (byte offset 103) using index "sybphy_id" (which evaluates to 12). 1415 l2h_adll_value[sybphy_id][bit_id] = 0; 1416 for (search_dir_id = HWS_LOW2HIGH; search_dir_id <= HWS_HIGH2LOW; 1417 search_dir_id++) { 1418 status = ddr3_tip_read_training_result 1419 (dev_num, if_id, 1420 ACCESS_TYPE_UNICAST, sybphy_id, bit_id, ** CID 408737: Memory - illegal accesses (OVERRUN) /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 396 in mv_ddr4_dq_vref_calibration() ________________________________________________________________________________________________________ *** CID 408737: Memory - illegal accesses (OVERRUN) /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 396 in mv_ddr4_dq_vref_calibration() 390 for (subphy_num = 0; subphy_num < subphy_max; subphy_num++) { 391 VALIDATE_BUS_ACTIVE(tm->bus_act_mask, subphy_num); 392 for (dq_idx = 0; dq_idx < 8; dq_idx++) { 393 pad_num = dq_map_table[dq_idx + 394 subphy_num * BUS_WIDTH_IN_BITS + 395 if_id * BUS_WIDTH_IN_BITS * subphy_max]; >>> CID 408737: Memory - illegal accesses (OVERRUN) >>> Overrunning array "pbs_res_per_bus[if_id]" of 9 8-byte elements at element index 12 (byte offset 103) using index "subphy_num" (which evaluates to 12). 396 status = ddr3_tip_bus_write(dev_num, ACCESS_TYPE_UNICAST, if_id, ACCESS_TYPE_UNICAST, 397 subphy_num, DDR_PHY_DATA, 398 0x10 + pad_num + effective_cs * 0x10, 399 pbs_res_per_bus[if_id][subphy_num][dq_idx]); 400 if (status != MV_OK) 401 return status; ** CID 408736: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 408736: Memory - corruptions (OVERRUN) /drivers/marvell/mv_ddr/apn806/mv_ddr_plat.c: 586 in mv_ddr_clk_dividers_set() 580 if_id)); 581 return -1; 582 } 583 584 if (mv_ddr_first_time_setting) { 585 /* get ddr init freq */ >>> CID 408736: Memory - corruptions (OVERRUN) >>> Overrunning callee's array of size 13 by passing argument "mv_ddr_init_freq_get()" (which evaluates to 14) in call to "mv_ddr_freq_get". 586 init_ddr_freq_val = mv_ddr_freq_get(mv_ddr_init_freq_get()); 587 588 /* get mc & ddr clk dividers values */ 589 reg = reg_read(DEV_GEN_CTRL1_REG_ADDR); 590 ddr_div = (reg >> MISC_CLKDIV_RATIO_1_OFFS) & MISC_CLKDIV_RATIO_1_MASK; 591 ** CID 408735: Data race undermines locking (LOCK_EVASION) /plat/mediatek/drivers/cpu_pm/cpcv3_2/mt_cpu_pm.c: 410 in cpupm_pwr_state_valid() ________________________________________________________________________________________________________ *** CID 408735: Data race undermines locking (LOCK_EVASION) /plat/mediatek/drivers/cpu_pm/cpcv3_2/mt_cpu_pm.c: 410 in cpupm_pwr_state_valid() 404 if (cpupm_init() != MTK_CPUPM_E_OK) { 405 return MTK_CPUPM_E_FAIL; 406 } 407 408 if (read_cntpct_el0() >= (uint64_t)CPUPM_BOOTUP_TIME_THR) { 409 plat_cpu_pm_lock(); >>> CID 408735: Data race undermines locking (LOCK_EVASION) >>> Thread1 sets "cpu_pm_status" to a new value. Now the two threads have an inconsistent view of "cpu_pm_status" and updates to fields correlated with "cpu_pm_status" may be lost. 410 cpu_pm_status |= CPU_PM_PLAT_READY; 411 plat_cpu_pm_unlock(); 412 } 413 414 if (!IS_PLAT_SYSTEM_SUSPEND(afflv) && (cpu_pm_status & CPU_PM_PLAT_READY) == 0) { 415 return MTK_CPUPM_E_FAIL; ** CID 408734: Memory - corruptions (OVERRUN) /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 1285 in mv_ddr4_tap_tuning() ________________________________________________________________________________________________________ *** CID 408734: Memory - corruptions (OVERRUN) /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 1285 in mv_ddr4_tap_tuning() 1279 pattern, EDGE_FPF, CS_SINGLE, PARAM_NOT_CARE, training_result); 1280 1281 for (iface = 0; iface < MAX_INTERFACE_NUM; iface++) { 1282 VALIDATE_IF_ACTIVE(tm->if_act_mask, iface); 1283 for (subphy = 0; subphy < subphy_max; subphy++) { 1284 VALIDATE_BUS_ACTIVE(tm->bus_act_mask, subphy); >>> CID 408734: Memory - corruptions (OVERRUN) >>> Overrunning array "rx_vw_pos[iface]" of 9 bytes at byte offset 12 using index "subphy" (which evaluates to 12). 1285 rx_vw_pos[iface][subphy] = ALIGN_CENTER; 1286 new_pbs_per_byte[subphy] = new_pbs; /* rx init */ 1287 if ((mode == TX_DIR) && (loop == 0)) { 1288 /* read nominal wl */ 1289 ddr3_tip_bus_read(dev, iface, ACCESS_TYPE_UNICAST, subphy, 1290 DDR_PHY_DATA, WL_PHY_REG(effective_cs), ** CID 408733: (OVERRUN) /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1598 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1623 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1626 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1617 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1614 in ddr3_tip_ip_training_wrapper() ________________________________________________________________________________________________________ *** CID 408733: (OVERRUN) /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1598 in ddr3_tip_ip_training_wrapper() 1592 VALIDATE_BUS_ACTIVE(tm->bus_act_mask, sybphy_id); 1593 1594 if ((byte_status[if_id][sybphy_id] != BYTE_NOT_DEFINED) && (direction == OPER_WRITE)) { 1595 /* clear the arrays and parameters */ 1596 center_subphy_adll_window[sybphy_id] = 0; 1597 max_center_subphy_adll[sybphy_id] = 0; >>> CID 408733: (OVERRUN) >>> Overrunning array "min_center_subphy_adll" of 9 bytes at byte offset 12 using index "sybphy_id" (which evaluates to 12). 1598 min_center_subphy_adll[sybphy_id] = 64; 1599 /* find the max and min center adll value in the current subphy */ 1600 for (bit_id = 0; bit_id < bit_end; bit_id++) { 1601 /* debug print all the bit edges after alignment */ 1602 DEBUG_TRAINING_IP_ENGINE 1603 (DEBUG_LEVEL_TRACE, /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1623 in ddr3_tip_ip_training_wrapper() 1617 min_center_subphy_adll[sybphy_id] = 1618 (l2h_adll_value[sybphy_id][bit_id] + 1619 h2l_adll_value[sybphy_id][bit_id]) / 2; 1620 } 1621 1622 /* calculate the center of the current subphy */ >>> CID 408733: (OVERRUN) >>> Overrunning array "min_center_subphy_adll" of 9 bytes at byte offset 12 using index "sybphy_id" (which evaluates to 12). 1623 center_subphy_adll_window[sybphy_id] = 1624 max_center_subphy_adll[sybphy_id] - 1625 min_center_subphy_adll[sybphy_id]; 1626 DEBUG_TRAINING_IP_ENGINE 1627 (DEBUG_LEVEL_TRACE, 1628 ("if_id %d sybphy_id %d min center %d max center %d center %d\n", /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1626 in ddr3_tip_ip_training_wrapper() 1620 } 1621 1622 /* calculate the center of the current subphy */ 1623 center_subphy_adll_window[sybphy_id] = 1624 max_center_subphy_adll[sybphy_id] - 1625 min_center_subphy_adll[sybphy_id]; >>> CID 408733: (OVERRUN) >>> Overrunning array "min_center_subphy_adll" of 9 bytes at byte offset 12 using index "sybphy_id" (which evaluates to 12). 1626 DEBUG_TRAINING_IP_ENGINE 1627 (DEBUG_LEVEL_TRACE, 1628 ("if_id %d sybphy_id %d min center %d max center %d center %d\n", 1629 if_id, sybphy_id, min_center_subphy_adll[sybphy_id], 1630 max_center_subphy_adll[sybphy_id], 1631 center_subphy_adll_window[sybphy_id])); /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1617 in ddr3_tip_ip_training_wrapper() 1611 max_center_subphy_adll[sybphy_id] = 1612 (l2h_adll_value[sybphy_id][bit_id] + 1613 h2l_adll_value[sybphy_id][bit_id]) / 2; 1614 if (((l2h_adll_value[sybphy_id][bit_id] + 1615 h2l_adll_value[sybphy_id][bit_id]) / 2) < 1616 min_center_subphy_adll[sybphy_id]) >>> CID 408733: (OVERRUN) >>> Overrunning array "min_center_subphy_adll" of 9 bytes at byte offset 12 using index "sybphy_id" (which evaluates to 12). 1617 min_center_subphy_adll[sybphy_id] = 1618 (l2h_adll_value[sybphy_id][bit_id] + 1619 h2l_adll_value[sybphy_id][bit_id]) / 2; 1620 } 1621 1622 /* calculate the center of the current subphy */ /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1614 in ddr3_tip_ip_training_wrapper() 1608 if (((l2h_adll_value[sybphy_id][bit_id] + 1609 h2l_adll_value[sybphy_id][bit_id]) / 2) > 1610 max_center_subphy_adll[sybphy_id]) 1611 max_center_subphy_adll[sybphy_id] = 1612 (l2h_adll_value[sybphy_id][bit_id] + 1613 h2l_adll_value[sybphy_id][bit_id]) / 2; >>> CID 408733: (OVERRUN) >>> Overrunning array "min_center_subphy_adll" of 9 bytes at byte offset 12 using index "sybphy_id" (which evaluates to 12). 1614 if (((l2h_adll_value[sybphy_id][bit_id] + 1615 h2l_adll_value[sybphy_id][bit_id]) / 2) < 1616 min_center_subphy_adll[sybphy_id]) 1617 min_center_subphy_adll[sybphy_id] = 1618 (l2h_adll_value[sybphy_id][bit_id] + 1619 h2l_adll_value[sybphy_id][bit_id]) / 2; ** CID 408732: (OVERRUN) /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1654 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1461 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1563 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1662 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1526 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1485 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1664 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1641 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1503 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1473 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1448 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1412 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1594 in ddr3_tip_ip_training_wrapper() ________________________________________________________________________________________________________ *** CID 408732: (OVERRUN) /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1654 in ddr3_tip_ip_training_wrapper() 1648 /* 1649 * in case all of the bits in the current subphy are 1650 * less than 32 which will find alignment in the subphy bits 1651 * mark this subphy as homogeneous split in 1652 */ 1653 if (center_subphy_adll_window[sybphy_id] <= 31) >>> CID 408732: (OVERRUN) >>> Overrunning array "byte_status[if_id]" of 9 bytes at byte offset 12 using index "sybphy_id" (which evaluates to 12). 1654 byte_status[if_id][sybphy_id] = BYTE_HOMOGENEOUS_SPLIT_IN; 1655 1656 /* 1657 * in case the current byte is split_out and the center is bigger than 31 1658 * the byte can be aligned. in this case add 64 to the the low ui bits aligning it 1659 * to the other ui bits /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1461 in ddr3_tip_ip_training_wrapper() 1455 if_id, sybphy_id, bit_id)); 1456 } else { 1457 /* low ui */ 1458 if (e1 <= 31 && e2 <= 31) { 1459 bit_state[sybphy_id * BUS_WIDTH_IN_BITS + bit_id] = 1460 BIT_LOW_UI; >>> CID 408732: (OVERRUN) >>> Overrunning array "byte_status[if_id]" of 9 bytes at byte offset 12 using index "sybphy_id" (which evaluates to 12). 1461 byte_status[if_id][sybphy_id] |= BYTE_HOMOGENEOUS_LOW; 1462 l2h_adll_value[sybphy_id][bit_id] = e1; 1463 h2l_adll_value[sybphy_id][bit_id] = e2; 1464 DEBUG_TRAINING_IP_ENGINE 1465 (DEBUG_LEVEL_TRACE, 1466 ("if_id %d sybphy_id %d bit %d BIT_LOW_UI\n", /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1563 in ddr3_tip_ip_training_wrapper() 1557 num_iter / 2, num_iter / 2, 1558 pattern, EDGE_FP, train_cs_type, 1559 cs_num, train_status); 1560 1561 for (sybphy_id = 0; sybphy_id < octets_per_if_num; sybphy_id++) { 1562 VALIDATE_BUS_ACTIVE(tm->bus_act_mask, sybphy_id); >>> CID 408732: (OVERRUN) >>> Overrunning array "byte_status[if_id]" of 9 bytes at byte offset 12 using index "sybphy_id" (which evaluates to 12). 1563 if (byte_status[if_id][sybphy_id] != BYTE_NOT_DEFINED) { 1564 if (bit_bit_mask[sybphy_id] == 0) 1565 continue; 1566 1567 for (bit_id = 0; bit_id < bit_end; bit_id++) { 1568 if ((bit_bit_mask[sybphy_id] & (1 << bit_id)) == 0) /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1662 in ddr3_tip_ip_training_wrapper() 1656 /* 1657 * in case the current byte is split_out and the center is bigger than 31 1658 * the byte can be aligned. in this case add 64 to the the low ui bits aligning it 1659 * to the other ui bits 1660 */ 1661 if (center_subphy_adll_window[sybphy_id] >= 32) { >>> CID 408732: (OVERRUN) >>> Overrunning array "byte_status[if_id]" of 9 bytes at byte offset 12 using index "sybphy_id" (which evaluates to 12). 1662 byte_status[if_id][sybphy_id] = BYTE_SPLIT_OUT_MIX; 1663 1664 DEBUG_TRAINING_IP_ENGINE 1665 (DEBUG_LEVEL_TRACE, 1666 ("if_id %d sybphy_id %d byte state 0x%x\n", 1667 if_id, sybphy_id, byte_status[if_id][sybphy_id])); /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1526 in ddr3_tip_ip_training_wrapper() 1520 num_iter / 2, num_iter / 2, 1521 pattern, EDGE_FP, train_cs_type, 1522 cs_num, train_status); 1523 1524 for (sybphy_id = 0; sybphy_id < octets_per_if_num; sybphy_id++) { 1525 VALIDATE_BUS_ACTIVE(tm->bus_act_mask, sybphy_id); >>> CID 408732: (OVERRUN) >>> Overrunning array "byte_status[if_id]" of 9 bytes at byte offset 12 using index "sybphy_id" (which evaluates to 12). 1526 if (byte_status[if_id][sybphy_id] != BYTE_NOT_DEFINED) { 1527 if (bit_bit_mask[sybphy_id] == 0) 1528 continue; /* this byte bits have no split out state */ 1529 1530 for (bit_id = 0; bit_id < bit_end; bit_id++) { 1531 if ((bit_bit_mask[sybphy_id] & (1 << bit_id)) == 0) /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1485 in ddr3_tip_ip_training_wrapper() 1479 if_id, sybphy_id, bit_id)); 1480 } 1481 /* split in */ 1482 if (e1 <= 31 && e2 >= 32) { 1483 bit_state[sybphy_id * BUS_WIDTH_IN_BITS + bit_id] = 1484 BIT_SPLIT_IN; >>> CID 408732: (OVERRUN) >>> Overrunning array "byte_status[if_id]" of 9 bytes at byte offset 12 using index "sybphy_id" (which evaluates to 12). 1485 byte_status[if_id][sybphy_id] |= 1486 BYTE_HOMOGENEOUS_SPLIT_IN; 1487 l2h_adll_value[sybphy_id][bit_id] = e1; 1488 h2l_adll_value[sybphy_id][bit_id] = e2; 1489 DEBUG_TRAINING_IP_ENGINE 1490 (DEBUG_LEVEL_TRACE, /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1664 in ddr3_tip_ip_training_wrapper() 1658 * the byte can be aligned. in this case add 64 to the the low ui bits aligning it 1659 * to the other ui bits 1660 */ 1661 if (center_subphy_adll_window[sybphy_id] >= 32) { 1662 byte_status[if_id][sybphy_id] = BYTE_SPLIT_OUT_MIX; 1663 >>> CID 408732: (OVERRUN) >>> Overrunning array "byte_status[if_id]" of 9 bytes at byte offset 12 using index "sybphy_id" (which evaluates to 12). 1664 DEBUG_TRAINING_IP_ENGINE 1665 (DEBUG_LEVEL_TRACE, 1666 ("if_id %d sybphy_id %d byte state 0x%x\n", 1667 if_id, sybphy_id, byte_status[if_id][sybphy_id])); 1668 for (bit_id = 0; bit_id < bit_end; bit_id++) { 1669 if (bit_state[sybphy_id * BUS_WIDTH_IN_BITS + bit_id] == BIT_LOW_UI) { /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1641 in ddr3_tip_ip_training_wrapper() 1635 * check byte state and fix bits state if needed 1636 * in case the level 1 and 2 above subphy results are 1637 * homogeneous continue to the next subphy 1638 */ 1639 for (sybphy_id = 0; sybphy_id < octets_per_if_num; sybphy_id++) { 1640 VALIDATE_BUS_ACTIVE(tm->bus_act_mask, sybphy_id); >>> CID 408732: (OVERRUN) >>> Overrunning array "byte_status[if_id]" of 9 bytes at byte offset 12 using index "sybphy_id" (which evaluates to 12). 1641 if ((byte_status[if_id][sybphy_id] == BYTE_HOMOGENEOUS_LOW) || 1642 (byte_status[if_id][sybphy_id] == BYTE_HOMOGENEOUS_HIGH) || 1643 (byte_status[if_id][sybphy_id] == BYTE_HOMOGENEOUS_SPLIT_IN) || 1644 (byte_status[if_id][sybphy_id] == BYTE_HOMOGENEOUS_SPLIT_OUT) || 1645 (byte_status[if_id][sybphy_id] == BYTE_NOT_DEFINED)) 1646 continue; /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1503 in ddr3_tip_ip_training_wrapper() 1497 (DEBUG_LEVEL_INFO, 1498 ("if_id %d sybphy_id %d bit %d l2h 0x%x (e1 0x%x)" 1499 "h2l 0x%x (e2 0x%x): bit cannot be categorized\n", 1500 if_id, sybphy_id, bit_id, result[HWS_LOW2HIGH][0], e1, 1501 result[HWS_HIGH2LOW][0], e2)); 1502 /* mark the byte as not defined */ >>> CID 408732: (OVERRUN) >>> Overrunning array "byte_status[if_id]" of 9 bytes at byte offset 12 using index "sybphy_id" (which evaluates to 12). 1503 byte_status[if_id][sybphy_id] = BYTE_NOT_DEFINED; 1504 break; /* continue to next pup - no reason to analyze this byte */ 1505 } 1506 } /* for all bits */ 1507 } /* for all PUPs */ 1508 /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1473 in ddr3_tip_ip_training_wrapper() 1467 if_id, sybphy_id, bit_id)); 1468 } 1469 /* high ui */ 1470 if (e1 >= 32 && e2 >= 32) { 1471 bit_state[sybphy_id * BUS_WIDTH_IN_BITS + bit_id] = 1472 BIT_HIGH_UI; >>> CID 408732: (OVERRUN) >>> Overrunning array "byte_status[if_id]" of 9 bytes at byte offset 12 using index "sybphy_id" (which evaluates to 12). 1473 byte_status[if_id][sybphy_id] |= BYTE_HOMOGENEOUS_HIGH; 1474 l2h_adll_value[sybphy_id][bit_id] = e1; 1475 h2l_adll_value[sybphy_id][bit_id] = e2; 1476 DEBUG_TRAINING_IP_ENGINE 1477 (DEBUG_LEVEL_TRACE, 1478 ("if_id %d sybphy_id %d bit %d BIT_HIGH_UI\n", /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1448 in ddr3_tip_ip_training_wrapper() 1442 if (direction == OPER_READ) { 1443 byte_status[if_id][sybphy_id] |= BYTE_HOMOGENEOUS_LOW; 1444 } else if ((e2 - e1) > 32) { /* oper_write */ 1445 /* split out */ 1446 bit_state[sybphy_id * BUS_WIDTH_IN_BITS + bit_id] = 1447 BIT_SPLIT_OUT; >>> CID 408732: (OVERRUN) >>> Overrunning array "byte_status[if_id]" of 9 bytes at byte offset 12 using index "sybphy_id" (which evaluates to 12). 1448 byte_status[if_id][sybphy_id] |= BYTE_HOMOGENEOUS_SPLIT_OUT; 1449 /* mark problem bits */ 1450 bit_bit_mask[sybphy_id] |= (1 << bit_id); 1451 bit_bit_mask_active = 1; 1452 DEBUG_TRAINING_IP_ENGINE 1453 (DEBUG_LEVEL_TRACE, /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1412 in ddr3_tip_ip_training_wrapper() 1406 bit_end = BUS_WIDTH_IN_BITS; 1407 else 1408 bit_end = 0; 1409 1410 /* zero the data base */ 1411 bit_bit_mask[sybphy_id] = 0; >>> CID 408732: (OVERRUN) >>> Overrunning array "byte_status[if_id]" of 9 bytes at byte offset 12 using index "sybphy_id" (which evaluates to 12). 1412 byte_status[if_id][sybphy_id] = BYTE_NOT_DEFINED; 1413 for (bit_id = 0; bit_id < bit_end; bit_id++) { 1414 h2l_adll_value[sybphy_id][bit_id] = 64; 1415 l2h_adll_value[sybphy_id][bit_id] = 0; 1416 for (search_dir_id = HWS_LOW2HIGH; search_dir_id <= HWS_HIGH2LOW; 1417 search_dir_id++) { /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1594 in ddr3_tip_ip_training_wrapper() 1588 * phase 3 will occur only in write operation 1589 * find the maximum and the minimum center of each subphy 1590 */ 1591 for (sybphy_id = 0; sybphy_id < octets_per_if_num; sybphy_id++) { 1592 VALIDATE_BUS_ACTIVE(tm->bus_act_mask, sybphy_id); 1593 >>> CID 408732: (OVERRUN) >>> Overrunning array "byte_status[if_id]" of 9 bytes at byte offset 12 using index "sybphy_id" (which evaluates to 12). 1594 if ((byte_status[if_id][sybphy_id] != BYTE_NOT_DEFINED) && (direction == OPER_WRITE)) { 1595 /* clear the arrays and parameters */ 1596 center_subphy_adll_window[sybphy_id] = 0; 1597 max_center_subphy_adll[sybphy_id] = 0; 1598 min_center_subphy_adll[sybphy_id] = 64; 1599 /* find the max and min center adll value in the current subphy */ ** CID 408731: Uninitialized variables (UNINIT) ________________________________________________________________________________________________________ *** CID 408731: Uninitialized variables (UNINIT) /drivers/marvell/mv_ddr/ddr3_training_leveling.c: 777 in ddr3_tip_dynamic_per_bit_read_leveling() 771 for (if_id = 0; if_id <= MAX_INTERFACE_NUM - 1; if_id++) { 772 VALIDATE_IF_ACTIVE(tm->if_act_mask, if_id); 773 for (bus_num = 0; bus_num < octets_per_if_num; 774 bus_num++) { 775 VALIDATE_BUS_ACTIVE(tm->bus_act_mask, bus_num); 776 if (per_bit_rl_pup_status[if_id][bus_num] == 1) >>> CID 408731: Uninitialized variables (UNINIT) >>> Using uninitialized value "data2_write[if_id][bus_num]" when calling "ddr3_tip_bus_write". 777 ddr3_tip_bus_write(dev_num, 778 ACCESS_TYPE_UNICAST, 779 if_id, 780 ACCESS_TYPE_UNICAST, 781 bus_num, DDR_PHY_DATA, 782 RL_PHY_REG(effective_cs), ** CID 408730: (OVERRUN) /drivers/marvell/mv_ddr/mv_ddr4_mpr_pda_if.c: 516 in mv_ddr4_dq_pins_mapping() /drivers/marvell/mv_ddr/mv_ddr4_mpr_pda_if.c: 508 in mv_ddr4_dq_pins_mapping() ________________________________________________________________________________________________________ *** CID 408730: (OVERRUN) /drivers/marvell/mv_ddr/mv_ddr4_mpr_pda_if.c: 516 in mv_ddr4_dq_pins_mapping() 510 } 511 512 /* stage 3: map dram dq to mc dq and update database */ 513 for (subphy_num = 0; subphy_num < subphy_max; subphy_num++) { 514 VALIDATE_BUS_ACTIVE(tm->bus_act_mask, subphy_num); 515 for (dq_num = 0; dq_num < BUS_WIDTH_IN_BITS; dq_num++) >>> CID 408730: (OVERRUN) >>> Overrunning array "dq_val" of 9 8-byte elements at element index 11 (byte offset 95) using index "subphy_num" (which evaluates to 11). 516 dram_to_mc_dq_map[subphy_num][7 - dq_val[subphy_num][dq_num]] = dq_num; 517 } 518 519 /* set dq_map_enable */ 520 dq_map_enable = 1; 521 /drivers/marvell/mv_ddr/mv_ddr4_mpr_pda_if.c: 508 in mv_ddr4_dq_pins_mapping() 502 /* extract pattern for each subphy */ 503 for (mpr_type = 0; mpr_type < MV_DDR4_MPR_READ_PATTERN_NUM; mpr_type++) 504 subphy_pattern[mpr_type] = ((mpr_pattern[mpr_type][2] >> (subphy_num * 8)) & 0xff); 505 506 for (dq_num = 0; dq_num < BUS_WIDTH_IN_BITS; dq_num++) 507 for (mpr_type = 0; mpr_type < MV_DDR4_MPR_READ_PATTERN_NUM; mpr_type++) >>> CID 408730: (OVERRUN) >>> Overrunning array "dq_val" of 9 8-byte elements at element index 11 (byte offset 95) using index "subphy_num" (which evaluates to 11). 508 dq_val[subphy_num][dq_num] += (((subphy_pattern[mpr_type] >> dq_num) & 1) * 509 (1 << mpr_type)); 510 } 511 512 /* stage 3: map dram dq to mc dq and update database */ 513 for (subphy_num = 0; subphy_num < subphy_max; subphy_num++) { ** CID 408729: (OVERRUN) /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 2228 in mv_ddr4_dm_tuning() /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 2225 in mv_ddr4_dm_tuning() /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 2222 in mv_ddr4_dm_tuning() /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 2200 in mv_ddr4_dm_tuning() /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 2223 in mv_ddr4_dm_tuning() /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 2205 in mv_ddr4_dm_tuning() /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 2226 in mv_ddr4_dm_tuning() /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 2229 in mv_ddr4_dm_tuning() ________________________________________________________________________________________________________ *** CID 408729: (OVERRUN) /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 2228 in mv_ddr4_dm_tuning() 2222 result[subphy][HWS_LOW2HIGH][bit] &= LEAST_SIGNIFICANT_BYTE_MASK; 2223 result[subphy][HWS_HIGH2LOW][bit] &= LEAST_SIGNIFICANT_BYTE_MASK; 2224 2225 if (result[subphy][HWS_LOW2HIGH][bit] > vw_sphy_lo_lmt[subphy]) 2226 vw_sphy_lo_lmt[subphy] = result[subphy][HWS_LOW2HIGH][bit]; 2227 >>> CID 408729: (OVERRUN) >>> Overrunning array "result" of 9 16-byte elements at element index 12 (byte offset 207) using index "subphy" (which evaluates to 12). 2228 if (result[subphy][HWS_HIGH2LOW][bit] < vw_sphy_hi_lmt[subphy]) 2229 vw_sphy_hi_lmt[subphy] = result[subphy][HWS_HIGH2LOW][bit]; 2230 } 2231 2232 DEBUG_DM_TUNING(DEBUG_LEVEL_INFO, 2233 ("loop %d, dm subphy %d, vw %d, %d\n", loop, subphy, /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 2225 in mv_ddr4_dm_tuning() 2219 continue; 2220 2221 for (bit = 0; bit < BUS_WIDTH_IN_BITS; bit++) { 2222 result[subphy][HWS_LOW2HIGH][bit] &= LEAST_SIGNIFICANT_BYTE_MASK; 2223 result[subphy][HWS_HIGH2LOW][bit] &= LEAST_SIGNIFICANT_BYTE_MASK; 2224 >>> CID 408729: (OVERRUN) >>> Overrunning array "result" of 9 16-byte elements at element index 12 (byte offset 207) using index "subphy" (which evaluates to 12). 2225 if (result[subphy][HWS_LOW2HIGH][bit] > vw_sphy_lo_lmt[subphy]) 2226 vw_sphy_lo_lmt[subphy] = result[subphy][HWS_LOW2HIGH][bit]; 2227 2228 if (result[subphy][HWS_HIGH2LOW][bit] < vw_sphy_hi_lmt[subphy]) 2229 vw_sphy_hi_lmt[subphy] = result[subphy][HWS_HIGH2LOW][bit]; 2230 } /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 2222 in mv_ddr4_dm_tuning() 2216 } 2217 2218 if (dm_status[subphy] == LOCKED) 2219 continue; 2220 2221 for (bit = 0; bit < BUS_WIDTH_IN_BITS; bit++) { >>> CID 408729: (OVERRUN) >>> Overrunning array "result" of 9 16-byte elements at element index 12 (byte offset 207) using index "subphy" (which evaluates to 12). 2222 result[subphy][HWS_LOW2HIGH][bit] &= LEAST_SIGNIFICANT_BYTE_MASK; 2223 result[subphy][HWS_HIGH2LOW][bit] &= LEAST_SIGNIFICANT_BYTE_MASK; 2224 2225 if (result[subphy][HWS_LOW2HIGH][bit] > vw_sphy_lo_lmt[subphy]) 2226 vw_sphy_lo_lmt[subphy] = result[subphy][HWS_LOW2HIGH][bit]; 2227 /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 2200 in mv_ddr4_dm_tuning() 2194 for (subphy = 0; subphy < subphy_max; subphy++) { 2195 VALIDATE_BUS_ACTIVE(tm->bus_act_mask, subphy); 2196 ddr3_tip_bus_write(0, ACCESS_TYPE_UNICAST, 0, ACCESS_TYPE_UNICAST, subphy, DDR_PHY_DATA, 2197 CTX_PHY_REG(cs), ctx_vector[subphy]); 2198 2199 for (search_dir = HWS_LOW2HIGH; search_dir <= HWS_HIGH2LOW; search_dir++) { >>> CID 408729: (OVERRUN) >>> "&result[subphy][search_dir]" evaluates to an address that is at byte offset 192 of an array of 144 bytes. 2200 ddr3_tip_read_training_result(0, 0, ACCESS_TYPE_UNICAST, subphy, 2201 ALL_BITS_PER_PUP, search_dir, dir, result_type, 2202 TRAINING_LOAD_OPERATION_UNLOAD, CS_SINGLE, 2203 &(result[subphy][search_dir]), 2204 1, 0, 0); 2205 DEBUG_DM_TUNING(DEBUG_LEVEL_INFO, /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 2223 in mv_ddr4_dm_tuning() 2217 2218 if (dm_status[subphy] == LOCKED) 2219 continue; 2220 2221 for (bit = 0; bit < BUS_WIDTH_IN_BITS; bit++) { 2222 result[subphy][HWS_LOW2HIGH][bit] &= LEAST_SIGNIFICANT_BYTE_MASK; >>> CID 408729: (OVERRUN) >>> Overrunning array "result" of 9 16-byte elements at element index 12 (byte offset 207) using index "subphy" (which evaluates to 12). 2223 result[subphy][HWS_HIGH2LOW][bit] &= LEAST_SIGNIFICANT_BYTE_MASK; 2224 2225 if (result[subphy][HWS_LOW2HIGH][bit] > vw_sphy_lo_lmt[subphy]) 2226 vw_sphy_lo_lmt[subphy] = result[subphy][HWS_LOW2HIGH][bit]; 2227 2228 if (result[subphy][HWS_HIGH2LOW][bit] < vw_sphy_hi_lmt[subphy]) /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 2205 in mv_ddr4_dm_tuning() 2199 for (search_dir = HWS_LOW2HIGH; search_dir <= HWS_HIGH2LOW; search_dir++) { 2200 ddr3_tip_read_training_result(0, 0, ACCESS_TYPE_UNICAST, subphy, 2201 ALL_BITS_PER_PUP, search_dir, dir, result_type, 2202 TRAINING_LOAD_OPERATION_UNLOAD, CS_SINGLE, 2203 &(result[subphy][search_dir]), 2204 1, 0, 0); >>> CID 408729: (OVERRUN) >>> Overrunning array "result" of 9 16-byte elements at element index 12 (byte offset 207) using index "subphy" (which evaluates to 12). 2205 DEBUG_DM_TUNING(DEBUG_LEVEL_INFO, 2206 ("dm cs %d if %d subphy %d result: 0x%x 0x%x 0x%x 0x%x 0x%x 0x%x 0x%x 0x%x\n", 2207 cs, 0, subphy, 2208 result[subphy][search_dir][0], 2209 result[subphy][search_dir][1], 2210 result[subphy][search_dir][2], /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 2226 in mv_ddr4_dm_tuning() 2220 2221 for (bit = 0; bit < BUS_WIDTH_IN_BITS; bit++) { 2222 result[subphy][HWS_LOW2HIGH][bit] &= LEAST_SIGNIFICANT_BYTE_MASK; 2223 result[subphy][HWS_HIGH2LOW][bit] &= LEAST_SIGNIFICANT_BYTE_MASK; 2224 2225 if (result[subphy][HWS_LOW2HIGH][bit] > vw_sphy_lo_lmt[subphy]) >>> CID 408729: (OVERRUN) >>> Overrunning array "result" of 9 16-byte elements at element index 12 (byte offset 207) using index "subphy" (which evaluates to 12). 2226 vw_sphy_lo_lmt[subphy] = result[subphy][HWS_LOW2HIGH][bit]; 2227 2228 if (result[subphy][HWS_HIGH2LOW][bit] < vw_sphy_hi_lmt[subphy]) 2229 vw_sphy_hi_lmt[subphy] = result[subphy][HWS_HIGH2LOW][bit]; 2230 } 2231 /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 2229 in mv_ddr4_dm_tuning() 2223 result[subphy][HWS_HIGH2LOW][bit] &= LEAST_SIGNIFICANT_BYTE_MASK; 2224 2225 if (result[subphy][HWS_LOW2HIGH][bit] > vw_sphy_lo_lmt[subphy]) 2226 vw_sphy_lo_lmt[subphy] = result[subphy][HWS_LOW2HIGH][bit]; 2227 2228 if (result[subphy][HWS_HIGH2LOW][bit] < vw_sphy_hi_lmt[subphy]) >>> CID 408729: (OVERRUN) >>> Overrunning array "result" of 9 16-byte elements at element index 12 (byte offset 207) using index "subphy" (which evaluates to 12). 2229 vw_sphy_hi_lmt[subphy] = result[subphy][HWS_HIGH2LOW][bit]; 2230 } 2231 2232 DEBUG_DM_TUNING(DEBUG_LEVEL_INFO, 2233 ("loop %d, dm subphy %d, vw %d, %d\n", loop, subphy, 2234 vw_sphy_lo_lmt[subphy], vw_sphy_hi_lmt[subphy])); ** CID 408728: (OVERRUN) /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 606 in ddr3_tip_vref() /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 412 in ddr3_tip_vref() /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 605 in ddr3_tip_vref() /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 370 in ddr3_tip_vref() /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 291 in ddr3_tip_vref() /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 285 in ddr3_tip_vref() /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 648 in ddr3_tip_vref() /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 440 in ddr3_tip_vref() /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 332 in ddr3_tip_vref() /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 677 in ddr3_tip_vref() /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 394 in ddr3_tip_vref() /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 554 in ddr3_tip_vref() /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 517 in ddr3_tip_vref() /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 487 in ddr3_tip_vref() /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 376 in ddr3_tip_vref() ________________________________________________________________________________________________________ *** CID 408728: (OVERRUN) /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 606 in ddr3_tip_vref() 600 vref_map[currrent_vref], 601 __LINE__)); 602 } 603 } else { 604 /* we change state and change step */ 605 if (pup_st[pup][if_id] == VREF_STEP_1) { >>> CID 408728: (OVERRUN) >>> Overrunning array "pup_st" of 9 bytes at byte offset 12 using index "pup" (which evaluates to 12). 606 pup_st[pup][if_id] = 607 VREF_STEP_2; 608 lim_vref[pup][if_id] = 609 current_vref[pup] 610 [if_id] - initial_step; 611 last_valid_window[pup] /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 412 in ddr3_tip_vref() 406 * better Vref value 407 * define the pup as 408 * converge and step 409 * back to nominal 410 * Vref. 411 */ >>> CID 408728: (OVERRUN) >>> Overrunning array "pup_st" of 9 bytes at byte offset 12 using index "pup" (which evaluates to 12). 412 pup_st[pup] 413 [if_id] = 414 VREF_CONVERGE; 415 algo_run_flag++; 416 interface_state 417 [if_id]++; /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 605 in ddr3_tip_vref() 599 (val & (~0xf)) | 600 vref_map[currrent_vref], 601 __LINE__)); 602 } 603 } else { 604 /* we change state and change step */ >>> CID 408728: (OVERRUN) >>> Overrunning array "pup_st" of 9 bytes at byte offset 12 using index "pup" (which evaluates to 12). 605 if (pup_st[pup][if_id] == VREF_STEP_1) { 606 pup_st[pup][if_id] = 607 VREF_STEP_2; 608 lim_vref[pup][if_id] = 609 current_vref[pup] 610 [if_id] - initial_step; /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 370 in ddr3_tip_vref() 364 /* Compare results and respond as function of state */ 365 for (if_id = 0; if_id < MAX_INTERFACE_NUM; if_id++) { 366 VALIDATE_IF_ACTIVE(tm->if_act_mask, if_id); 367 for (pup = 0; 368 pup < octets_per_if_num; pup++) { 369 VALIDATE_BUS_ACTIVE(tm->bus_act_mask, pup); >>> CID 408728: (OVERRUN) >>> Overrunning array "pup_st" of 9 bytes at byte offset 12 using index "pup" (which evaluates to 12). 370 DEBUG_TRAINING_HW_ALG(DEBUG_LEVEL_TRACE, 371 ("I/F[ %d ], pup[ %d ] STATE #%d (%d)\n", 372 if_id, pup, 373 pup_st[pup] 374 [if_id], __LINE__)); 375 /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 291 in ddr3_tip_vref() 285 pup_st[pup][if_id] = VREF_CONVERGE; 286 DEBUG_TRAINING_HW_ALG( 287 DEBUG_LEVEL_INFO, 288 ("VREF config, IF[ %d ]pup[ %d ] - Vref tune not requered (%d)\n", 289 if_id, pup, __LINE__)); 290 } else { >>> CID 408728: (OVERRUN) >>> Overrunning array "pup_st" of 9 bytes at byte offset 12 using index "pup" (which evaluates to 12). 291 pup_st[pup][if_id] = VREF_STEP_1; 292 CHECK_STATUS(ddr3_tip_bus_read 293 (dev_num, if_id, 294 ACCESS_TYPE_UNICAST, pup, 295 DDR_PHY_DATA, reg_addr, &val)); 296 CHECK_STATUS(ddr3_tip_bus_write /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 285 in ddr3_tip_vref() 279 last_vref[pup][if_id] = 0; 280 lim_vref[pup][if_id] = 0; 281 current_valid_window[pup][if_id] = 0; 282 last_valid_window[pup][if_id] = 0; 283 if (vref_window_size[if_id][pup] > 284 vref_window_size_th) { >>> CID 408728: (OVERRUN) >>> Overrunning array "pup_st" of 9 bytes at byte offset 12 using index "pup" (which evaluates to 12). 285 pup_st[pup][if_id] = VREF_CONVERGE; 286 DEBUG_TRAINING_HW_ALG( 287 DEBUG_LEVEL_INFO, 288 ("VREF config, IF[ %d ]pup[ %d ] - Vref tune not requered (%d)\n", 289 if_id, pup, __LINE__)); 290 } else { /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 648 in ddr3_tip_vref() 642 if_id, pup, 643 (val & (~0xf)) | 644 vref_map[current_vref[pup] 645 [if_id]], 646 __LINE__)); 647 >>> CID 408728: (OVERRUN) >>> Overrunning array "pup_st" of 9 bytes at byte offset 12 using index "pup" (which evaluates to 12). 648 } else if (pup_st[pup][if_id] == VREF_STEP_2) { 649 /* 650 * The last search was the max 651 * point set value and exit 652 */ 653 CHECK_STATUS /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 440 in ddr3_tip_vref() 434 : (current_vref[pup] 435 [if_id] + 436 initial_step); 437 if (current_vref[pup] 438 [if_id] == 439 VREF_MAX_INDEX) { >>> CID 408728: (OVERRUN) >>> Overrunning array "pup_st" of 9 bytes at byte offset 12 using index "pup" (which evaluates to 12). 440 pup_st[pup] 441 [if_id] 442 = 443 VREF_STEP_2; 444 } 445 lim_vref[pup] /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 332 in ddr3_tip_vref() 326 get_valid_win_rx(dev_num, if_id, res); 327 for (pup = 0; 328 pup < octets_per_if_num; 329 pup++) { 330 VALIDATE_BUS_ACTIVE 331 (tm->bus_act_mask, pup); >>> CID 408728: (OVERRUN) >>> Overrunning array "pup_st" of 9 bytes at byte offset 12 using index "pup" (which evaluates to 12). 332 if (pup_st[pup] 333 [if_id] == 334 VREF_CONVERGE) 335 continue; 336 337 current_valid_window[pup] /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 677 in ddr3_tip_vref() 671 ("VREF config, IF[ %d ]pup[ %d ] - Vref = %X (%d)\n", 672 if_id, pup, 673 (val & (~0xf)) | 674 vref_map[last_vref[pup] 675 [if_id]], 676 __LINE__)); >>> CID 408728: (OVERRUN) >>> Overrunning array "pup_st" of 9 bytes at byte offset 12 using index "pup" (which evaluates to 12). 677 pup_st[pup][if_id] = 678 VREF_CONVERGE; 679 algo_run_flag++; 680 interface_state[if_id]++; 681 DEBUG_TRAINING_HW_ALG 682 (DEBUG_LEVEL_TRACE, /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 394 in ddr3_tip_vref() 388 /* 389 * The -1 is for solution resolution +/- 1 tap 390 * of ADLL 391 */ 392 if (current_valid_window[pup][if_id] + 200 >= 393 (last_valid_window[pup][if_id])) { >>> CID 408728: (OVERRUN) >>> Overrunning array "pup_st" of 9 bytes at byte offset 12 using index "pup" (which evaluates to 12). 394 if (pup_st[pup][if_id] == VREF_STEP_1) { 395 /* 396 * We stay in the same state and 397 * step just update the window 398 * size (take the max) and Vref 399 */ /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 554 in ddr3_tip_vref() 548 * better Vref value 549 * define the pup as 550 * converge and step 551 * back to nominal 552 * Vref. 553 */ >>> CID 408728: (OVERRUN) >>> Overrunning array "pup_st" of 9 bytes at byte offset 12 using index "pup" (which evaluates to 12). 554 pup_st[pup] 555 [if_id] = 556 VREF_CONVERGE; 557 558 algo_run_flag++; 559 interface_state /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 517 in ddr3_tip_vref() 511 * better Vref value 512 * define the pup as 513 * converge and step 514 * back to nominal 515 * Vref. 516 */ >>> CID 408728: (OVERRUN) >>> Overrunning array "pup_st" of 9 bytes at byte offset 12 using index "pup" (which evaluates to 12). 517 pup_st[pup] 518 [if_id] = 519 VREF_CONVERGE; 520 algo_run_flag++; 521 522 interface_state /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 487 in ddr3_tip_vref() 481 (DEBUG_LEVEL_TRACE, 482 ("VREF config, IF[ %d ]pup[ %d ] - Vref = %X (%d)\n", 483 if_id, pup, 484 (val & (~0xf)) | 485 vref_map[currrent_vref], 486 __LINE__)); >>> CID 408728: (OVERRUN) >>> Overrunning array "pup_st" of 9 bytes at byte offset 12 using index "pup" (which evaluates to 12). 487 } else if (pup_st[pup][if_id] 488 == VREF_STEP_2) { 489 /* 490 * We keep on search back with 491 * the same step size. 492 */ /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 376 in ddr3_tip_vref() 370 DEBUG_TRAINING_HW_ALG(DEBUG_LEVEL_TRACE, 371 ("I/F[ %d ], pup[ %d ] STATE #%d (%d)\n", 372 if_id, pup, 373 pup_st[pup] 374 [if_id], __LINE__)); 375 >>> CID 408728: (OVERRUN) >>> Overrunning array "pup_st" of 9 bytes at byte offset 12 using index "pup" (which evaluates to 12). 376 if (pup_st[pup][if_id] == VREF_CONVERGE) 377 continue; 378 379 DEBUG_TRAINING_HW_ALG(DEBUG_LEVEL_TRACE, 380 ("I/F[ %d ], pup[ %d ] CHECK progress - Current %d Last %d, limit VREF %d (%d)\n", 381 if_id, pup, ** CID 408727: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /drivers/marvell/mv_ddr/drivers/snps/snps_update.c: 660 in dmem_1d_2d_rtt_nom_wr_park_get() ________________________________________________________________________________________________________ *** CID 408727: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /drivers/marvell/mv_ddr/drivers/snps/snps_update.c: 660 in dmem_1d_2d_rtt_nom_wr_park_get() 654 u16 ret_val = 0; 655 u16 rtt_park, rtt_nom, rtt_wr; 656 657 rtt_nom = mv_ddr_rtt_nom_get(); 658 rtt_park = mv_ddr_rtt_park_get(); 659 rtt_wr = mv_ddr_rtt_wr_get(); >>> CID 408727: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "rtt_nom != 4294967295U" is always true regardless of the values of its operands. This occurs as the logical first operand of "&&". 660 if (rtt_nom != PARAM_UNDEFINED && rtt_park != PARAM_UNDEFINED && rtt_wr != PARAM_UNDEFINED) { 661 ret_val = (rtt_nom & RTT_NOM_WR_PARK0_RTT_NOM_MR1_MASK) << RTT_NOM_WR_PARK0_RTT_NOM_MR1_OFFS; 662 ret_val |= (rtt_park & RTT_NOM_WR_PARK0_RTT_PARK_MR5_MASK) << RTT_NOM_WR_PARK0_RTT_PARK_MR5_OFFS; 663 ret_val |= (rtt_wr & RTT_NOM_WR_PARK0_RTT_WR_MR2_MASK) << RTT_NOM_WR_PARK0_RTT_WR_MR2_OFFS; 664 ret_val |= RTT_NOM_WR_PARK0_EN_VAL; 665 } ** CID 408726: Data race undermines locking (LOCK_EVASION) /plat/mediatek/common/lpm/mt_lp_rq.c: 152 in mt_lp_rq_get_status() ________________________________________________________________________________________________________ *** CID 408726: Data race undermines locking (LOCK_EVASION) /plat/mediatek/common/lpm/mt_lp_rq.c: 152 in mt_lp_rq_get_status() 146 for (i = 0; i < plat_mt_rqm.resource_num; i++) { 147 update_sta |= ((rs[i]->res_usage & plat_mt_rqm.user_valid) != 0) ? 148 rs[i]->res_rq : 0; 149 } 150 151 plat_mt_rqm.generic_resource_req = update_sta; >>> CID 408726: Data race undermines locking (LOCK_EVASION) >>> Thread1 sets "flag" to a new value. Now the two threads have an inconsistent view of "flag" and updates to fields correlated with "flag" may be lost. 152 plat_mt_rqm.flag = MT_LP_RQ_FLAG_DONE; 153 spin_unlock(&mt_lp_rq_lock); 154 } 155 156 switch (type) { 157 case PLAT_RQ_REQ_USAGE: ** CID 408725: (OVERRUN) /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 350 in mv_ddr4_dq_vref_calibration() /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 370 in mv_ddr4_dq_vref_calibration() /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 369 in mv_ddr4_dq_vref_calibration() ________________________________________________________________________________________________________ *** CID 408725: (OVERRUN) /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 350 in mv_ddr4_dq_vref_calibration() 344 valid_vref_cnt[if_id][subphy_num], 345 &center_vref[if_id][subphy_num], 346 &center_adll[if_id][subphy_num]); 347 if (status != MV_OK) 348 return status; 349 >>> CID 408725: (OVERRUN) >>> Overrunning array "center_vref[if_id]" of 9 bytes at byte offset 12 using index "subphy_num" (which evaluates to 12). 350 DEBUG_CALIBRATION(DEBUG_LEVEL_INFO, 351 ("center of mass results: vref %d, adll %d\n", 352 center_vref[if_id][subphy_num], center_adll[if_id][subphy_num])); 353 } else { 354 DEBUG_CALIBRATION(DEBUG_LEVEL_ERROR, 355 ("%s subphy %d no vref results to calculate the center of mass\n", /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 340 in mv_ddr4_dq_vref_calibration() 334 VALIDATE_BUS_ACTIVE(tm->bus_act_mask, subphy_num); 335 DEBUG_CALIBRATION(DEBUG_LEVEL_INFO, 336 ("calculating center of mass for subphy %d, valid window size %d\n", 337 subphy_num, valid_win_size[if_id][subphy_num])); 338 if (valid_vref_cnt[if_id][subphy_num] > 0) { 339 /* calculate center of mass sampling point (t, v) for each subphy */ >>> CID 408725: (OVERRUN) >>> Overrunning array of 9 bytes at byte offset 12 by dereferencing pointer "&center_vref[if_id][subphy_num]". 340 status = mv_ddr4_center_of_mass_calc(dev_num, if_id, subphy_num, TX_DIR, 341 dq_vref_start_win[if_id][subphy_num], 342 dq_vref_end_win[if_id][subphy_num], 343 valid_vref_ptr[if_id][subphy_num], 344 valid_vref_cnt[if_id][subphy_num], 345 &center_vref[if_id][subphy_num], /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 370 in mv_ddr4_dq_vref_calibration() 364 VALIDATE_IF_ACTIVE(tm->if_act_mask, if_id); 365 vref_avg = 0; 366 vref_subphy_num = 0; 367 for (subphy_num = 0; subphy_num < subphy_max; subphy_num++) { 368 VALIDATE_BUS_ACTIVE(tm->bus_act_mask, subphy_num); 369 vref_avg += center_vref[if_id][subphy_num]; >>> CID 408725: (OVERRUN) >>> Overrunning array "center_vref[if_id]" of 9 bytes at byte offset 12 using index "subphy_num" (which evaluates to 12). 370 dq_vref_vec[subphy_num] = center_vref[if_id][subphy_num]; 371 vref_subphy_num++; 372 } 373 374 mv_ddr4_vref_tap_set(dev_num, if_id, ACCESS_TYPE_UNICAST, 375 vref_avg / vref_subphy_num, MV_DDR4_VREF_TAP_START); /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 369 in mv_ddr4_dq_vref_calibration() 363 for (if_id = 0; if_id < MAX_INTERFACE_NUM; if_id++) { 364 VALIDATE_IF_ACTIVE(tm->if_act_mask, if_id); 365 vref_avg = 0; 366 vref_subphy_num = 0; 367 for (subphy_num = 0; subphy_num < subphy_max; subphy_num++) { 368 VALIDATE_BUS_ACTIVE(tm->bus_act_mask, subphy_num); >>> CID 408725: (OVERRUN) >>> Overrunning array "center_vref[if_id]" of 9 bytes at byte offset 12 using index "subphy_num" (which evaluates to 12). 369 vref_avg += center_vref[if_id][subphy_num]; 370 dq_vref_vec[subphy_num] = center_vref[if_id][subphy_num]; 371 vref_subphy_num++; 372 } 373 374 mv_ddr4_vref_tap_set(dev_num, if_id, ACCESS_TYPE_UNICAST, ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

2 years, 11 months

1
0
0 0

We cannot force Arm features for platforms

by Marcin Juszkiewicz

TL;DR: move Mandatory features to be runtime checked (value 2) Month ago there was changeset from Govindraj Raja merged [1]. The plan was to enable all mandatory features based on architecture version set by plaform (using ARM_ARCH_{MAJOR,MINOR} variables). 1. https://review.trustedfirmware.org/q/topic:%22gr/build_refactor%22 The idea is nice. But only for final products. If you are working on silicon bring up or on virtualization platform (QEMU or other) then you got hit badly... I am working on SBSA Reference Platform in QEMU. It can have one of several cpu models. From old v8.0 cores up to v9.0 ones. And then there is also 'max' core which cannot be mapped to any architecture level because it contains all Arm cpu features QEMU can emulate. We need to support all of them in one TF-A binary. Whenever something fails we have some cpu cores in non-bootable state. We had to enable FGT to get 'max' boot Linux. Now we have to move DIT to be runtime checked to boot anything below Neoverse-V1 at all. And HCX to get 'max' boot Linux again. At current state of TF-A we cannot handle it. Toplevel Makefile includes platform.mk which sets ARM_ARCH_{MAJOR,MINOR} and then make_helpers/arch_features.mk enables mandatory options by setting them to value "1" which means "present, no need to check". Due to this we have those changes in Gerrit: DIT: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/24870 TRF: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/23648 And instead of sending another one to switch FGT, RNG and HCX I decided to write this email. I have spent half of day today bisecting TF-A, booting several tools and operating systems to check how we are and where the problem is. Still have to get Neoverse-N2 booting properly but other than then I got to the point where all cpu cores boot into Linux. We need to change make_helpers/arch_features.mk to stop enabling mandatory features as "present, no need to check" (value '1') but to use runtime check (value '2') instead. This way any platform which contains CPU not yet fully developed can boot TF-A. Or platform where one firmware can boot different cpu models. I am sorry that I bring it so late in release cycle but was unable to use computer for a development for some time.

2 years, 11 months

5
8
0 0

Stack usage

by kbhuvanacbe＠gmail.com

We have executed below command on terminal to get stack size using ARMCLANG compiler. but we are getting "undefined symbol". armclang --target=arm-arm-none-eabi -march=armv8-a -c -g file.c -o file.o armlink file.o --info=stack armlink file.o --callgraph -o FileImage.axf Could anyone answer me that how to get stack size using ARMCLANG compiler for TFA code.

2 years, 11 months

3
10
0 0

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

by Olivier Deprez

This event has been canceled with a note: "Hi, Cancelling this week as no topic. Thanks & Regards, Olivier." TF-A Tech Forum Thursday Nov 16, 2023 ⋅ 5pm – 6pm Central European Time - Paris We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   Guests marek.bykowski(a)gmail.com okash.khawaja(a)gmail.com tf-a(a)lists.trustedfirmware.org ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years, 11 months

1
0
0 0

Trusted Firmware-A LTS v2.8.11 Release Announcement

by Varun Wadekar

Hello, Trusted Firmware-A LTS version 2.8.11 is now available. This release contains the workarounds for CPU errata, platform errata, and fixes for Versal/Versal-NET security vulnerabilities. The complete list of changes can be found here<https://ci-builds.trustedfirmware.org/static-files/NdY070C96xYcXq0KeqQzbFaI…>. Thanks.

2 years, 11 months

1
0
0 0

Changelog for v2.10 Release

by Juan Pablo Conde

Hello everyone, Please take a look at the changelog for your respective platforms ahead of the TF-A v2.10 release. The changelog is autogenerated from the commit messages of the patches that have been merged since the v2.9 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/+/24865 Rendered Version: https://ci-builds.trustedfirmware.org/static-files/cUYrGRM_T04eS_lYaTNfWT13… Thanks, Juan Pablo

2 years, 11 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. 3 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 1 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 3 of 3 defect(s) ** CID 405370: Memory - illegal accesses (OVERRUN) /lib/psci/psci_stat.c: 210 in psci_get_stat() ________________________________________________________________________________________________________ *** CID 405370: Memory - illegal accesses (OVERRUN) /lib/psci/psci_stat.c: 210 in psci_get_stat() 204 /* Get the index into the stats array */ 205 local_state = state_info.pwr_domain_state[pwrlvl]; 206 stat_idx = get_stat_idx(local_state, pwrlvl); 207 208 if (pwrlvl > PSCI_CPU_PWR_LVL) { 209 /* Get the power domain index */ >>> CID 405370: Memory - illegal accesses (OVERRUN) >>> Overrunning array "psci_cpu_pd_nodes" of 16 16-byte elements at element index 4294967295 (byte offset 68719476735) using index "target_idx" (which evaluates to 4294967295). 210 parent_idx = SPECULATION_SAFE_VALUE(psci_cpu_pd_nodes[target_idx].parent_node); 211 for (lvl = PSCI_CPU_PWR_LVL + 1U; lvl < pwrlvl; lvl++) 212 parent_idx = SPECULATION_SAFE_VALUE(psci_non_cpu_pd_nodes[parent_idx].parent_node); 213 214 /* Get the non cpu power domain stats */ 215 *psci_stat = psci_non_cpu_stat[parent_idx][stat_idx]; ** CID 405369: Memory - illegal accesses (OVERRUN) /lib/psci/psci_stat.c: 218 in psci_get_stat() ________________________________________________________________________________________________________ *** CID 405369: Memory - illegal accesses (OVERRUN) /lib/psci/psci_stat.c: 218 in psci_get_stat() 212 parent_idx = SPECULATION_SAFE_VALUE(psci_non_cpu_pd_nodes[parent_idx].parent_node); 213 214 /* Get the non cpu power domain stats */ 215 *psci_stat = psci_non_cpu_stat[parent_idx][stat_idx]; 216 } else { 217 /* Get the cpu power domain stats */ >>> CID 405369: Memory - illegal accesses (OVERRUN) >>> Overrunning array "psci_cpu_stat" of 16 32-byte elements at element index 4294967295 (byte offset 137438953471) using index "target_idx" (which evaluates to 4294967295). 218 *psci_stat = psci_cpu_stat[target_idx][stat_idx]; 219 } 220 221 return PSCI_E_SUCCESS; 222 } 223 ** CID 405368: (NEGATIVE_RETURNS) /lib/psci/psci_stat.c: 210 in psci_get_stat() /lib/psci/psci_stat.c: 218 in psci_get_stat() ________________________________________________________________________________________________________ *** CID 405368: (NEGATIVE_RETURNS) /lib/psci/psci_stat.c: 210 in psci_get_stat() 204 /* Get the index into the stats array */ 205 local_state = state_info.pwr_domain_state[pwrlvl]; 206 stat_idx = get_stat_idx(local_state, pwrlvl); 207 208 if (pwrlvl > PSCI_CPU_PWR_LVL) { 209 /* Get the power domain index */ >>> CID 405368: (NEGATIVE_RETURNS) >>> Using variable "target_idx" as an index to array "psci_cpu_pd_nodes". 210 parent_idx = SPECULATION_SAFE_VALUE(psci_cpu_pd_nodes[target_idx].parent_node); 211 for (lvl = PSCI_CPU_PWR_LVL + 1U; lvl < pwrlvl; lvl++) 212 parent_idx = SPECULATION_SAFE_VALUE(psci_non_cpu_pd_nodes[parent_idx].parent_node); 213 214 /* Get the non cpu power domain stats */ 215 *psci_stat = psci_non_cpu_stat[parent_idx][stat_idx]; /lib/psci/psci_stat.c: 218 in psci_get_stat() 212 parent_idx = SPECULATION_SAFE_VALUE(psci_non_cpu_pd_nodes[parent_idx].parent_node); 213 214 /* Get the non cpu power domain stats */ 215 *psci_stat = psci_non_cpu_stat[parent_idx][stat_idx]; 216 } else { 217 /* Get the cpu power domain stats */ >>> CID 405368: (NEGATIVE_RETURNS) >>> Using variable "target_idx" as an index to array "psci_cpu_stat". 218 *psci_stat = psci_cpu_stat[target_idx][stat_idx]; 219 } 220 221 return PSCI_E_SUCCESS; 222 } 223 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

2 years, 11 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-A