- TF-A - lists.trustedfirmware.org

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 487973: Memory - corruptions (ARRAY_VS_SINGLETON) _____________________________________________________________________________________________ *** CID 487973: Memory - corruptions (ARRAY_VS_SINGLETON) /plat/xilinx/versal_net/bl31_versal_net_setup.c: 167 in bl31_early_platform_setup2() 161 xbl_ret = xbl_handover(&bl32_image_ep_info, &bl33_image_ep_info, 162 tfa_handoff_addr); 163 if (xbl_ret == XBL_HANDOFF_SUCCESS) { 164 goto success; 165 } 166 #if DEBUG >>> CID 487973: Memory - corruptions (ARRAY_VS_SINGLETON) >>> Passing "&boot_mode" to function "get_boot_mode" which uses it as an array. This might corrupt or misinterpret adjacent memory locations. 167 get_boot_mode(&boot_mode); 168 if ((xbl_ret != XBL_HANDOFF_SUCCESS) && (boot_mode == JTAG_MODE)) { 169 bl31_set_default_config(); 170 goto success; 171 } 172 #endif ** CID 487972: Memory - corruptions (OVERRUN) _____________________________________________________________________________________________ *** CID 487972: Memory - corruptions (OVERRUN) /plat/xilinx/versal_net/bl31_versal_net_setup.c: 167 in bl31_early_platform_setup2() 161 xbl_ret = xbl_handover(&bl32_image_ep_info, &bl33_image_ep_info, 162 tfa_handoff_addr); 163 if (xbl_ret == XBL_HANDOFF_SUCCESS) { 164 goto success; 165 } 166 #if DEBUG >>> CID 487972: Memory - corruptions (OVERRUN) >>> Overrunning buffer pointed to by "&boot_mode" of 1 4-byte elements by passing it to a function which accesses it at element index 5 (byte offset 23). 167 get_boot_mode(&boot_mode); 168 if ((xbl_ret != XBL_HANDOFF_SUCCESS) && (boot_mode == JTAG_MODE)) { 169 bl31_set_default_config(); 170 goto success; 171 } 172 #endif ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://scan.coverity.com/projects/arm-software-arm-trusted-firmware?tab=ov…

2 hours, 16 minutes

1
0
0 0

Rusted Firmware-A is live!

by Olivier Deprez

Hi, Relaying an important announcement about the new Rusted Firmware-A project hosted on trustedfirmware.org: Today, the Trusted Firmware organization proudly unveils Rusted Firmware-A (RF-A) v0.1 \u2014 a ground breaking open-source prototype that reimagines Trusted Firmware-A (TF-A) through the adoption of the Rust programming language. Developed in close collaboration between Arm and Google, both Diamond members of the Trusted Firmware community, RF-A has been architected from the ground up for the latest Arm® A-class processors. With a security-first approach, RF-A delivers strong memory safety, enhanced reliability, and modern modularity. Unlike incremental updates, Rusted Firmware-A is a complete redesign \u2014 free from legacy constraints, built to leverage modern hardware, and designed to provide a robust, maintainable, and future-ready firmware foundation. This milestone reflects years of industry learnings, community insights, and deep collaboration between leading software and silicon providers. Press release - https://www.trustedfirmware.org/news/rf-a-press-release Technical blog - https://www.trustedfirmware.org/blog/rf-a-blog Linkedin post - https://www.linkedin.com/posts/trustedfirmware-org_rusted-firmware-a-rf-a-a… Regards, Olivier on behalf of Arm RF-A team.

3 days, 20 hours

1
0
0 0

Trusted Firmware-A LTS v2.10.20 Release Announcement

by svc_openci_enginfra＠arm.com

Hello, Trusted Firmware-A LTS version 2.10.20 is now available. This release contains the following patches: 0f23418f7 docs(security): security advisory for CVE-2024-5660 [1] 2749de008 docs(security): security advisory for CVE-2024-7881 [2] dc0b5b922 fix(cpus): workaround for Cortex-X3 erratum 3692984 [3] fe66ffc80 fix(cpus): workaround for Cortex-X3 erratum 3827463 [4] bf658f6e6 fix(cpus): workaround for Cortex-X3 erratum 3213672 [5] dd846c6b4 fix(cpus): check minor revision before applying runtime errata [6] 588d93fe4 chore(deps): bump sphinxcontrib-svg2pdfconverter from 1.2.2 to 1.3.0 [7] a843ce313 chore(deps): bump commitizen [8] d7d698694 fix(cpus): put back the global declaration for erratum #3701747 [9] [1] https://review.trustedfirmware.org/q/I0d0428061f60b6fe83d03362b27b960f6ddcc… [2] https://review.trustedfirmware.org/q/Ide976bc8754dc94d23e76001aaecf52556e70… [3] https://review.trustedfirmware.org/q/I054b47d33fd1ff7bde3ae12e8ee3d99e92039… [4] https://review.trustedfirmware.org/q/I1d4a2b9641400d8b9061f7cb32a8312c39956… [5] https://review.trustedfirmware.org/q/Ia1c03217f4e1816b4e8754a090cf5bc17546b… [6] https://review.trustedfirmware.org/q/I46b2ba8b524a073e02b4b5de641ae97795bc1… [7] https://review.trustedfirmware.org/q/Ia884121a4eeaf8033ff251e509264c9c97299… [8] https://review.trustedfirmware.org/q/I0cd50a9d7df7dac842a781b5f05a507d6f79d… [9] https://review.trustedfirmware.org/q/Ic7a5a13ae89b0b86ccbea56fecfe12bef57a9… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.10.20/change-log.html Thanks, TF-A LTS team

2 weeks

1
0
0 0

Does FVP_Base_RevC-2xAEMvA platform model has a full support for address translation at PL2 stage-1 MMU in aarch32?

by Marek

Have you ever succeeded in performing a Stage-1 MMU translation using LPAE (Long Physical Address Extension) on the FVP_Base_RevC-2xAEMvA platform model running in AArch32 Hyp mode (CONFIG64=0) into any other Memory but Strongly-Ordered? My environment is - FVP_Base_RevC-2xAEMvA booting SW stack from bullet point below - SW stack from Yocto, 'meta-arm'. I use 'fvp-base-arm32' that builds bl1, bl2, bl32, bl33, Linux kernel and rootfs. The only component that works there at PL2 HYP mode is u-boot (bl33). Whichever attributes I assign there Normal Memory with Inner or Outer Cacheability, Write-Through, or Write-Back, or Non-cacheable I always end up with Strongly-Ordered. To me it looks like it doesn't read the MAIR correctly and/or ignores the Cachability in HCTR. I inspected the MMU code thoroughly there, compared with the other codes for MMU, from trusted-firmware-a, xen, and Linux kernel and it seems u-boot does it correct. U-boot sets there identity-mapping for all 4GB with 0GB through 2GB Strongly-Ordered, 3G - 4G Normal Memory, Cachable Write-Back Write-Allocate, Non-Shareable and the last 1GB also Strongly-Ordered. Here is a brief execution steps it goes through: #1 Sets up the 2M-block at the 2nd level table with attributes. - sample block descriptor for translating from 0x8000_0000 virt to phys: 0x8000044d - bits[1:0] = 0b01 -> valid descriptor, descriptor type: block - bits[4:2] = 0b011 -> AttrIndx[2:0] points to MAIR0[3] . MAIR0[3] is 0xff - bits[5] = 0b0 - Non-secure - bits[7:6] = 0b01 - Access Permission: Read/write - bits[9:8] = 0b00 -> Shareability: non-shareable #2 Sets up 1st level table descriptor pointing to the descriptor shown above. It sets bits[1:0] to 0b11 meaning it is a table descriptor and valid. #3 Set control registers as follows HTCR is: 0x80000500 so - bits[9:8] = 0b01 -> Inner Cacheability to Normal memory, Outer Write-Back Write-Allocate Cacheable - bits[11:10] = 0b01 -> Outer Cacheability to Normal memory, Outer Write-Back Write-Allocate Cacheable - bits[13:12] = 0b00 -> Non-shareable HTTBR is: 0x00000000feff4000 -> points to 1st lavel table set in #2 HMAIR0 is: 0xffeeaa00 -> as shown above AttrIndx[2:0] points to MAIR0 and the four nibble being 0xff. 0xff is Normal memory, Inner Write-Back Cacheablea, Non-transientb HMAIR1 is: 0x00000000 - I set it to zero there as not used. #4 Finally it sets the M and C bits in HSCTLR registers Inspecting the page tables with amrds the region 3GB through 4GB that should be Normal and Cachable is Strongly-Ordered - 0x80000000 | L2 Block | NP:0x0000000080000000 | XN=0, PXN=0, Contiguous=0, nG=0, AF=1, SH=0x0, AP=0x1, AttrIndx=0x3 - H:0x80000000-0xFEFFFFFF | NP:0x80000000-0xFEFFFFFF | Strongly-ordered | NA | False | True | True Least not last are the parameters I pass to the model: FVP_Base_RevC-2xAEMvA --parameter bp.ve_sysregs.exit_on_shutdown=1 --parameter bp.virtio_net.enabled=1 --parameter bp.virtio_net.hostbridge.userNetworking=1 --parameter bp.virtio_net.hostbridge.userNetPorts=8022=22 --parameter cache_state_modelled=0 --parameter bp.secureflashloader.fname=/home/ubuntu/yocto/poky/arm32-aem-build/tmp/deploy/images/fvp-base-arm32/bl1-fvp.bin --parameter bp.flashloader0.fname=/home/ubuntu/yocto/poky/arm32-aem-build/tmp/deploy/images/fvp-base-arm32/fip-fvp.bin --parameter bp.virtioblockdevice.image_path=/home/ubuntu/yocto/poky/arm32-aem-build/tmp/deploy/images/fvp-base-arm32/core-image-minimal-fvp-base-arm32-20250630100348.rootfs.wic --parameter cluster0.has_arm_v8-4=1 --parameter cluster1.has_arm_v8-4=1 --parameter cluster0.cpu0.CONFIG64=0 --parameter cluster0.cpu1.CONFIG64=0 --parameter cluster0.cpu2.CONFIG64=0 --parameter cluster0.cpu3.CONFIG64=0 --parameter cluster1.cpu0.CONFIG64=0 --parameter cluster1.cpu1.CONFIG64=0 --parameter cluster1.cpu2.CONFIG64=0 --parameter cluster1.cpu3.CONFIG64=0 --data cluster0.cpu0=/home/ubuntu/yocto/poky/arm32-aem-build/tmp/deploy/images/fvp-base-arm32/zImage@0x80080000 --data cluster0.cpu0=/home/ubuntu/yocto/poky/arm32-aem-build/tmp/deploy/images/fvp-base-arm32/fvp-base-revc.dtb@0x8fc00000 --parameter 'bp.terminal_0.terminal_command=tmux new-window -n "%title" "telnet localhost %port"' --parameter bp.terminal_1.start_telnet=0 --parameter bp.terminal_2.start_telnet=0 --parameter bp.terminal_3.start_telnet=0 --iris-server --iris-port 7102 --iris-allow-remote And an interrupted (not full for longevity) console log: NOTICE: Booting Trusted Firmware NOTICE: BL1: v2.8(debug):dd37aa5be-dirty NOTICE: BL1: Built : 20:04:50, Aug 4 2025 NOTICE: BL1: Booting BL2 NOTICE: BL2: v2.8(debug):dd37aa5be-dirty NOTICE: BL2: Built : 20:04:50, Aug 4 2025 NOTICE: BL1: Booting BL32 WARNING: FCONF: Invalid config id 26 INFO: SP_MIN FCONF: HW_CONFIG address = 0x7f00000 INFO: FCONF: Reading HW_CONFIG firmware configuration file from: 0x7f00000 INFO: FCONF: Reading firmware configuration information for: cpu_timer INFO: FCONF: Reading firmware configuration information for: uart_config INFO: FCONF: Reading firmware configuration information for: topology INFO: FCONF: Reading firmware configuration information for: gicv3_config NOTICE: SP_MIN: v2.8(debug):dd37aa5be-dirty NOTICE: SP_MIN: Built : 20:04:50, Aug 4 2025 U-Boot 2022.04 (Aug 06 2025 - 16:41:21 +0000) vexpress_aemv8a fvp aarch32 DRAM: 2 GiB WARNING: Caches not enabled Core: 2 devices, 2 uclasses Flash: 64 MiB MMC: Loading Environment from nowhere... OK In: serial_pl01x Out: serial_pl01x Err: serial_pl01x Net: SMC91111-0 Error: SMC91111-0 address not set. Hit any key to stop autoboot: 0 fvp32# dcache on fvp32# run bootcmd OTE: Dereference aliases by omitting the leading '/', e.g. fdt print ethernet0. Kernel image @ 0x80080000 [ 0x000000 - 0x687970 ] ## Flattened Device Tree blob at 8fc00000 Booting using the fdt blob at 0x8fc00000 Loading Device Tree to feb8b000, end feb90fff ... OK Starting kernel ... Booting Linux on physical CPU 0x0 Linux version 6.1.57-yocto-standard (oe-user@oe-host) (arm-poky-linux-gnueabi-gcc (GCC) 12.3.0, GNU ld (GNU Binutils) 2.40.0.20230703) #1 SMP PREEMPT Wed Oct 11 23:03:27 UTC 2023 CPU: ARMv7 Processor [410fd0f0] revision 0 (ARMv7), cr=10c5387d CPU: div instructions available: patching division code CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache OF: fdt: Machine model: FVP Base RevC earlycon: pl11 at MMIO 0x1c090000 (options '') amba 1c1f0000.clcd: deferred probe pending Poky (Yocto Project Reference Distro) 4.2.4 fvp-base-arm32 /dev/ttyAMA0 fvp-base-arm32 login: root root@fvp-base-arm32:~# random: crng init done random: 1 urandom warning(s) missed due to ratelimiting root@fvp-base-arm32:~# Is there a chance FVP_Base_RevC-2xAEMvA doesn't support the 1-stage MMU translation for anything else but Strongly-Ordered? Thanks, Marek

2 weeks

1
0
0 0

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

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 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 487601: Control flow issues (DEADCODE) /plat/mediatek/drivers/spm/mt8189/mt_spm_pmic_lp.c: 157 in set_vcore_lp_volt() _____________________________________________________________________________________________ *** CID 487601: Control flow issues (DEADCODE) /plat/mediatek/drivers/spm/mt8189/mt_spm_pmic_lp.c: 157 in set_vcore_lp_volt() 151 { 152 /* allow 0.35V ~ 0.75V */ 153 if (volt < VCORE_0_35V) 154 return; 155 if (volt > VCORE_0_75V) 156 return; >>> CID 487601: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "vcore_suspend_vol = volt;". 157 vcore_suspend_vol = volt; 158 } 159 160 uint32_t get_vcore_lp_volt(void) 161 { 162 return vcore_suspend_vol; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://scan.coverity.com/projects/arm-software-arm-trusted-firmware?tab=ov…

2 weeks

1
0
0 0

optee_ftpm + ms-tpm-20-ref support for RSA key sizes 3072 or 4096 causes a panic

by Dennis Kong

Dear community: I apologize in advance if this is the incorrect place to solicit for input on an issue I am having when enabling support of RSA key sizes > 2048. The environment is described below: TI AM642-EVM board Debian Bookworm running kernel 6.6.100, tpm_ftpm_tee.ko kernel module Uboot booting from sdcard UEFI partition and rootfs partition optee_os version 4.5.0 , 4.6.0, 4.7.0 (no difference in behaviour) optee_client version 4.5.0, 4.6.0, 4.7.0 (no difference in behaviour) optee_ftpm version 4.5.0 or 4.6.0, 4.7.0 (no difference in behaviour) ms-tpm-20-ref commit id 98b60a44aba79b15fcce1c0d1e46cf5918400f6a and e9fc7b89d865536c46deb63f9c7d0121a3ded49c Due to issues with RPMB, we decided to use REE_FS instead. Everything works correctly when I create RSA 2048 keys using tpm2-openssl and related tools: sudo tpm2_createprimary -C o -G rsa2048 -g sha256 -c primary.ctx, When I try rsa3072 or 4096, I get errors from the command line response saying invalid input parameters. I changed the ms-tpm-20-ref include file TpmProfile.h to set RSA_3072 and RSA_4096 macros both to (ALG_RSA && YES). After rebuilding and running, I now get an optee panic for ANY RSA key request INCLUDING rsa2048. I read suggestions to increase the MAX_COMMAND_SIZE/MAX_RESPONSE_SIZE on both the kernel driver tpm_ftpm_tee.ko and also optee_os/optee_ftpm, as well to increase relevant TA_STACK_SIZE and TA_HEAP_SIZE and TA_DATA_SIZE, but nothing seems to change the panic output: sudo tpm2_createprimary -C o -G rsa2048 -g sha256 -c primary.ctx============================================================ E/TC:? 0 E/TC:? 0 TA panicked with code 0xffff0007 E/LD: Status of TA bc50d971-d4c9-42c4-82cb-343fb7f37896 E/LD: arch: aarch64 E/LD: region 0: va 0x40005000 pa 0x9e8b0000 size 0x002000 flags rw-s (ldelf) E/LD: region 1: va 0x40007000 pa 0x9e8b2000 size 0x008000 flags r-xs (ldelf) E/LD: region 2: va 0x4000f000 pa 0x9e8ba000 size 0x001000 flags rw-s (ldelf) E/LD: region 3: va 0x40010000 pa 0x9e8bb000 size 0x004000 flags rw-s (ldelf) E/LD: region 4: va 0x40014000 pa 0x9e8bf000 size 0x001000 flags r--s E/LD: region 5: va 0x40015000 pa 0x9e934000 size 0x011000 flags rw-s (stack) E/LD: region 6: va 0x40026000 pa 0x8ebf0000 size 0x002000 flags rw-- (param) E/LD: region 7: va 0x4006e000 pa 0x9e8c0000 size 0x058000 flags r-xs [0] E/LD: region 8: va 0x400c6000 pa 0x9e918000 size 0x01c000 flags rw-s [0] E/LD: [0] bc50d971-d4c9-42c4-82cb-343fb7f37896 @ 0x4006e000 E/LD: Call stack: E/LD: 0x4006f394 E/LD: 0x40095edc E/LD: 0x4007b5a8 E/LD: 0x400985fc E/LD: 0x40098a70 E/LD: 0x4006fae0 E/LD: 0x400a5508 E/LD: 0x40098b9c D/TC:? 0 user_ta_enter:195 tee_user_ta_enter: TA panicked with code 0xffff0007 D/TC:? 0 release_ta_ctx:670 Releasing panicked TA ctx D/TC:? 0 tee_ta_invoke_command:798 Error: ffff3024 of 3 [ 218.944680] tpm tpm0: ftpm_tee_tpm_op_send: SUBMIT_COMMAND invoke error: 0xffff3024 [ 218.952379] tpm tpm0: tpm_try_transmit: send(): error -53212 D/TC:? 0 tee_ta_invoke_command:798 Error: ffff3024 of 3 [ 218.963359] tpm tpm0: ftpm_tee_tpm_op_send: SUBMIT_COMMAND invoke error: 0xffff3024 [ 218.974241] tpm tpm0: tpm_try_transmit: send(): error -53212 D/TC:? 0 tee_ta_invoke_command:798 Error: ffff3024 of 3 [ 218.985675] tpm tpm0: ftpm_tee_tpm_op_send: SUBMIT_COMMAND invoke error: 0xffff3024 [ 218.993366] tpm tpm0: tpm_try_transmit: send(): error -53212 [ 218.999044] tpm tpm0: tpm2_commit_space: error -14 ERROR:tcti:src/tss2-tcti/tcti-device.c:198:tcti_device_receive()D/TC:? 0 tee_ta_invoke_command:798 Error: ffff3024 of 3 Failed to get response size fd 3, got errno 14: Bad address E[ 219.015351] tpm tpm0: ftpm_tee_tpm_op_send: SUBMIT_COMMAND invoke error: 0xffff3024 RROR:esys:src/tss2-esys/api/Esys_CreatePrimary.c:404:Esys_Create[ 219.028348] tpm tpm0: tpm_try_transmit: send(): error -53212 Primary_Finish() Received a non-TPM Error ERROR:esys:src/tss2-esys/api/Esys_CreatePrimary.c:135:Esys_CreatePrimary() Esys Finish ErrorCode (0x000a000a) ERROR: Esys_CreatePrimary(0xA000A) - tcti:IO failure ERROR:esys:src/tss2-esys/esys_iutil.c:1145:iesys_check_sequence_async() Esys called in bad sequence. ERROR:esys:src/tss2-esys/api/Esys_FlushContext.c:66:Esys_FlushContext() Error in async function ErrorCode (0x00070007) ============================================================================= The last suggestion I saw was to change my dtb file to include a reserved memory region for optee shared memory and not use the default dynamic shared memory. The issue I have is kernel 6.6.100's tpm_ftpm_tee ignores the "memory-region" dts statement that references the optee_shm reserved memory at at 0xa4000000 in my case. Below is my snippet of the dts file. I heard there are patches in the kernel ftpm driver to support the reserved shared memory, but before I try the patches, can anyone opine whether this could cause the panic that I am seeing? Thanks in advance for anyone who can share any information optee_shm: optee-shm@a4000000 { compatible = "shared-dma-pool"; reg = <0x0 0xa4000000 0x0 0x01000000>; no-map; reusable; }; .... firmware { optee { compatible = "linaro,optee-tz"; method = "smc"; memory-region = <&optee_shm>; }; } Dennis Kong, P.Eng. Staff Engineer Perle Systems Limited 60 Renfrew Drive, Markham, ON L3R 0E1 (905) 475-6070 ext. 2126

2 weeks, 1 day

1
0
0 0

Does spmd_group0_interrupt_handler_nwd() need to take into account handling of special INTIDs?

by YANG Jun

Hi there, Do spmd_group0_interrupt_handler_nwd() and spmd_handle_group0_intr_swd() need to take into account handling of special INTIDs? Like ehf_el3_interrupt_handler(): /* * Acknowledge interrupt. Proceed with handling only for valid interrupt * IDs. This situation may arise because of Interrupt Management * Framework identifying an EL3 interrupt, but before it's been * acknowledged here, the interrupt was either deasserted, or there was * a higher-priority interrupt of another type. */ intr_raw = plat_ic_acknowledge_interrupt(); intr = plat_ic_get_interrupt_id(intr_raw); if (intr == INTR_ID_UNAVAILABLE) return 0; Best Regards, Joe Yang

2 weeks, 2 days

3
3
0 0

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

by Olivier Deprez

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

2 weeks, 2 days

1
0
0 0

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

by Olivier Deprez

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

2 weeks, 2 days

1
0
0 0

Re: Does spmd_group0_interrupt_handler_nwd() need to take into account handling of special INTIDs?

by Yang Joe

Hi Madhukar, Yes, I have encountered a spurious ID(1023) issue once. Best Regards, Joe Yang

3 weeks, 2 days

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-A