August 2025 - TF-A - lists.trustedfirmware.org

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

3 weeks, 3 days

2
1
0 0

Trusted Firmware-A LTS v2.12.6 Release Announcement

by svc_openci_enginfra＠arm.com

Hello, Trusted Firmware-A LTS version 2.12.6 is now available. This release contains the following patches: 27fa107db fix(cpus): put back the global declaration for erratum #3701747 [1] 621560d74 fix(cpus): check minor revision before applying runtime errata [2] 44fc77fef fix(cpus): workaround for Cortex-X3 erratum 3692984 [3] cafd1afdc fix(cpus): workaround for Cortex-X3 erratum 3827463 [4] e9bc0b98b fix(cpus): workaround for Cortex-X3 erratum 3213672 [5] 76a1cce97 docs(security): security advisory for CVE-2024-5660 [6] e90ce7577 docs(security): security advisory for CVE-2024-7881 [7] 4b559e72c fix(cpus): workaround for Cortex-X2 erratum 1901946 [8] 7054fa4e7 fix(cpus): workaround for Cortex-X2 erratum 1916945 [9] 7f0fc6bd0 fix(cpus): workaround for Cortex-X2 erratum 1917258 [10] 47ddedb4d fix(cpus): workaround for Cortex-X2 erratum 1927200 [11] 851c5bf1a fix(cpus): workaround for Cortex-X2 erratum 1934260 [12] 66f25a832 fix(cpus): workaround for Cortex-X2 erratum 2136059 [13] 7430412db fix(cpus): workaround for Cortex-X2 erratum 2267065 [14] d1ed44d64 fix(cpus): workaround for Cortex-X2 erratum 2291219 [15] 885b1291a fix(cpus): organize Cortex-X2 errata entries [16] 7fc7f929c fix(cpus): workaround for Cortex-X4 erratum 3133195 [17] ace292ef2 fix(cpus): workaround for Cortex-X4 erratum 3887999 [18] [1] https://review.trustedfirmware.org/q/Ic7a5a13ae89b0b86ccbea56fecfe12bef57a9… [2] https://review.trustedfirmware.org/q/I46b2ba8b524a073e02b4b5de641ae97795bc1… [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/I0d0428061f60b6fe83d03362b27b960f6ddcc… [7] https://review.trustedfirmware.org/q/Ide976bc8754dc94d23e76001aaecf52556e70… [8] https://review.trustedfirmware.org/q/I5a65db60f06982191994db49815419c4d7250… [9] https://review.trustedfirmware.org/q/If810b1d0a07c43b3e1aa70d2ec88c1dcfa6f7… [10] https://review.trustedfirmware.org/q/Ic18a5179856f861701f09b2556906a6722db8… [11] https://review.trustedfirmware.org/q/I8d9038df1907888b3c5b2520d06bc150665e7… [12] https://review.trustedfirmware.org/q/I180d38fee27175dc8ac5fa6726e5b71c33402… [13] https://review.trustedfirmware.org/q/I156467537c3f235b50fc8aa19a969f2798bd8… [14] https://review.trustedfirmware.org/q/I540e113f209ef11ec7103d4ef4e48ffb52416… [15] https://review.trustedfirmware.org/q/I43af57961feba3a1c001d09ad804740b996f1… [16] https://review.trustedfirmware.org/q/Ic01517d58d3ca1b2d39be5282b0058c94fa5d… [17] https://review.trustedfirmware.org/q/Id44daf950124e7c2d46cb5d6d6a1083d06fad… [18] https://review.trustedfirmware.org/q/I851746b7b430eac85184c8d402d1aa5bb3c94… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.12.6/change-log.html Thanks, TF-A LTS team

3 weeks, 6 days

1
0
0 0

Trusted Firmware-A LTS v2.8.36 Release Announcement

by svc_openci_enginfra＠arm.com

Hello, Trusted Firmware-A LTS version 2.8.36 is now available. This release contains the following patches: c1555a4b8 docs(security): security advisory for CVE-2024-5660 [1] 624fc1ef2 fix(cpus): workaround for Cortex-X3 erratum 3692984 [2] 016cec654 fix(cpus): workaround for Cortex-X3 erratum 3827463 [3] aecd38e2d fix(cpus): workaround for Cortex-X3 erratum 3213672 [4] 4e7482dec docs(security): security advisory for CVE-2024-7881 [5] 697b97b1c fix(cpus): check minor revision before applying runtime errata [6] e98240355 fix(cpus): workaround for Cortex-X2 erratum 1901946 [7] 09561550a fix(cpus): workaround for Cortex-X2 erratum 1916945 [8] 030aeeb41 fix(cpus): workaround for Cortex-X2 erratum 1917258 [9] 7285f895b fix(cpus): workaround for Cortex-X2 erratum 1927200 [10] d7e3d8d03 fix(cpus): workaround for Cortex-X2 erratum 1934260 [11] 7b27723e3 fix(cpus): workaround for Cortex-X2 erratum 2136059 [12] 9ba7b304f fix(cpus): workaround for Cortex-X2 erratum 2267065 [13] c7de7e847 feat(cpus): add sysreg_bit_toggle [14] c1e2ccbe9 fix(cpus): workaround for Cortex-X2 erratum 2291219 [15] eff911ae6 fix(cpus): organize Cortex-X2 errata entries [16] 23c71d54d fix(cpus): workaround for Cortex-X4 erratum 3133195 [17] c55f75f33 fix(cpus): workaround for Cortex-X4 erratum 3887999 [18] d8f885dda chore(deps-dev): Bump commitizen [19] 083ec60a7 chore(deps-dev): Bump click from 8.1.7 to 8.1.8 [20] [1] https://review.trustedfirmware.org/q/I0d0428061f60b6fe83d03362b27b960f6ddcc… [2] https://review.trustedfirmware.org/q/I054b47d33fd1ff7bde3ae12e8ee3d99e92039… [3] https://review.trustedfirmware.org/q/I1d4a2b9641400d8b9061f7cb32a8312c39956… [4] https://review.trustedfirmware.org/q/Ia1c03217f4e1816b4e8754a090cf5bc17546b… [5] https://review.trustedfirmware.org/q/Ide976bc8754dc94d23e76001aaecf52556e70… [6] https://review.trustedfirmware.org/q/I46b2ba8b524a073e02b4b5de641ae97795bc1… [7] https://review.trustedfirmware.org/q/I5a65db60f06982191994db49815419c4d7250… [8] https://review.trustedfirmware.org/q/If810b1d0a07c43b3e1aa70d2ec88c1dcfa6f7… [9] https://review.trustedfirmware.org/q/Ic18a5179856f861701f09b2556906a6722db8… [10] https://review.trustedfirmware.org/q/I8d9038df1907888b3c5b2520d06bc150665e7… [11] https://review.trustedfirmware.org/q/I180d38fee27175dc8ac5fa6726e5b71c33402… [12] https://review.trustedfirmware.org/q/I156467537c3f235b50fc8aa19a969f2798bd8… [13] https://review.trustedfirmware.org/q/I540e113f209ef11ec7103d4ef4e48ffb52416… [14] https://review.trustedfirmware.org/q/I058bad58f5949b2d5fe058101410e33b6be1b… [15] https://review.trustedfirmware.org/q/I43af57961feba3a1c001d09ad804740b996f1… [16] https://review.trustedfirmware.org/q/Ic01517d58d3ca1b2d39be5282b0058c94fa5d… [17] https://review.trustedfirmware.org/q/Id44daf950124e7c2d46cb5d6d6a1083d06fad… [18] https://review.trustedfirmware.org/q/I851746b7b430eac85184c8d402d1aa5bb3c94… [19] https://review.trustedfirmware.org/q/Id7a94e085b8cab73efc935e5c71e7b43f6149… [20] https://review.trustedfirmware.org/q/I0e616fa4e45fc803522f1f5fe108fa75e9198… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.8.36/change-log.html Thanks, TF-A LTS team

3 weeks, 6 days

1
0
0 0

Trusted Firmware-A LTS v2.10.21 Release Announcement

by svc_openci_enginfra＠arm.com

Hello, Trusted Firmware-A LTS version 2.10.21 is now available. This release contains the following patches: a8a944318 build(deps-dev): Bump pip-tools from 6.13.0 to 6.14.0 [1] c4e1d4aa4 build(deps-dev): Bump @commitlint/cli from 19.0.0 to 19.8.1 [2] 8fd01f672 build(deps-dev): Bump @commitlint/cz-commitlint from 19.0.0 to 19.8.1 [3] 11ac166ca build(deps-dev): Bump @commitlint/config-conventional [4] f13bcf9b1 feat(cpus): add sysreg_bit_toggle [5] 0c79e2503 fix(cpus): workaround for Cortex-X2 erratum 1901946 [6] 8c1313b57 fix(cpus): workaround for Cortex-X2 erratum 1916945 [7] 79048ea18 fix(cpus): workaround for Cortex-X2 erratum 1917258 [8] 7f237698e fix(cpus): workaround for Cortex-X2 erratum 1927200 [9] 10388d941 fix(cpus): workaround for Cortex-X2 erratum 1934260 [10] d1320024f fix(cpus): workaround for Cortex-X2 erratum 2136059 [11] 158b26749 fix(cpus): workaround for Cortex-X2 erratum 2267065 [12] 211f2681b fix(cpus): workaround for Cortex-X2 erratum 2291219 [13] 23da5c284 fix(cpus): organize Cortex-X2 errata entries [14] 45e66bf45 fix(cpus): workaround for Cortex-X4 erratum 3133195 [15] dbef7f7f4 fix(cpus): workaround for Cortex-X4 erratum 3887999 [16] d30f0ff2c docs(security): update Advisory TFV-6 [17] [1] https://review.trustedfirmware.org/q/I5b529430588b599402553aed2b4929885053c… [2] https://review.trustedfirmware.org/q/I3c0f687e72c1bd02ef297387f5d2155576e31… [3] https://review.trustedfirmware.org/q/I4baeb1055066d580af5df08ebb4f0f96d6fc2… [4] https://review.trustedfirmware.org/q/Ic27f9c7211ef6535702a9475aeed57c9f2864… [5] https://review.trustedfirmware.org/q/I058bad58f5949b2d5fe058101410e33b6be1b… [6] https://review.trustedfirmware.org/q/I5a65db60f06982191994db49815419c4d7250… [7] https://review.trustedfirmware.org/q/If810b1d0a07c43b3e1aa70d2ec88c1dcfa6f7… [8] https://review.trustedfirmware.org/q/Ic18a5179856f861701f09b2556906a6722db8… [9] https://review.trustedfirmware.org/q/I8d9038df1907888b3c5b2520d06bc150665e7… [10] https://review.trustedfirmware.org/q/I180d38fee27175dc8ac5fa6726e5b71c33402… [11] https://review.trustedfirmware.org/q/I156467537c3f235b50fc8aa19a969f2798bd8… [12] https://review.trustedfirmware.org/q/I540e113f209ef11ec7103d4ef4e48ffb52416… [13] https://review.trustedfirmware.org/q/I43af57961feba3a1c001d09ad804740b996f1… [14] https://review.trustedfirmware.org/q/Ic01517d58d3ca1b2d39be5282b0058c94fa5d… [15] https://review.trustedfirmware.org/q/Id44daf950124e7c2d46cb5d6d6a1083d06fad… [16] https://review.trustedfirmware.org/q/I851746b7b430eac85184c8d402d1aa5bb3c94… [17] https://review.trustedfirmware.org/q/Icb3d039c8949fd6036c729a845646170710ba… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.10.21/change-log.html Thanks, TF-A LTS team

3 weeks, 6 days

1
0
0 0

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

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 2 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 2 of 2 defect(s) ** CID 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…

1 month

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.

1 month, 1 week

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

1 month, 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…

1 month, 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

1 month, 2 weeks

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

1 month, 2 weeks

3
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-A August 2025