- TF-A - lists.trustedfirmware.org

by Tamas Ban

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

1 year

3
3
0 0

Interaction with TF-a from NS World

by Max Adam

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

1 year

2
1
0 0

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

by Soby Mathew

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

1 year

1
0
0 0

Trusted Firmware-A LTS v2.8.25 Release Announcement

by ci_notify＠trustedfirmware.org

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

1 year

1
0
0 0

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

by Olivier Deprez

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

1 year

1
0
0 0

Trusted Firmware v2.12 release announcement

by Olivier Deprez

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

1 year

1
0
0 0

Changelog for v2.12 Release

by Govindraj Raja

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

1 year

1
0
0 0

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

by Olivier Deprez

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

1 year

1
0
0 0

Reference Secure Partition Code with FF-A

by Belsare, Akshay

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

1 year, 1 month

3
2
0 0

TF-A: Compilation issues for Rockchip platforms

by Quentin Schulz

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

1 year, 1 month

3
15
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-A