- TF-A - lists.trustedfirmware.org

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

10 months, 2 weeks

1
0
0 0

Firmware-A v2.12 release code freeze notification

by Govindraj Raja

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

10 months, 2 weeks

1
1
0 0

Reference Secure Partition Code with FF-A

by Belsare, Akshay

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

10 months, 3 weeks

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

10 months, 3 weeks

3
15
0 0

Re: TF-A: Compilation issues for Rockchip platforms

by Chris Kay

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

10 months, 3 weeks

1
0
0 0

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

by scan-admin＠coverity.com

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

10 months, 3 weeks

1
0
0 0

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

by Olivier Deprez

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

10 months, 4 weeks

1
0
0 0

TF-A Tech Forum regular call

by Olivier Deprez

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

10 months, 4 weeks

1
0
0 0

How to configure TZC-400 in ATF?

by 钱非凡

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

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

11 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-A