TF-A February 2024

tf-a@lists.trustedfirmware.org

14 participants
22 discussions

MMIO with pre/post indexing instructions

by ff

Hi, I am using hypervisors to allow execution of EL3 code directly and had to deal with MMIO caused by instructions that have post-indexing parameters. Xen community had to deal with this in 2022: https://www.mail-archive.com/xen-devel@lists.xenproject.org/msg113335.html This does not cause any trouble and have implemented ways to deal with this expeditiously. Yet, I wonder if it is desirable to from a synchronisation perspective? Cheers FF Compiling TFA 2.10 for PLAT=a80x0_mcbin The following line https://elixir.bootlin.com/arm-trusted-firmware/v2.10.0/source/drivers/marv… Is compiled as: win_reg = mmio_read_32(AMB_WIN_CR_OFFSET(win_id)); 4026d9c: f9470260 ldr x0, [x19, #3584] 4026da0: 9100e002 add x2, x0, #0x38 4026da4: b9400001 ldr w1, [x0] win_reg &= ~WIN_ENABLE_BIT; 4026da8: 121f7821 and w1, w1, #0xfffffffe *(volatile uint32_t*)addr = value; // post-indexing 4026dac: b8008401 str w1, [x0], #8 #gcc --version gcc (Ubuntu 10.3.0-1ubuntu1) 10.3.0 Copyright (C) 2020 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. #objdump --version GNU objdump (GNU Binutils for Ubuntu) 2.36.1 Copyright (C) 2021 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) any later version. This program has absolutely no warranty. #I can’t get access to latests compiler and binutils versions to overcome # « ../.. array subscript 0 is outside array bounds of ‘volatile void[0] » # « ../.. has a LOAD segment with RWX permissions » # so I don’t know if this behaviour is changed when using this latests toolchain

9 months, 2 weeks

Handling of normal world interrupts with BL31 PSCI handler

by caleb.ethridge＠analog.com

Hello, If normal world interrupts are received while invoking TF-A's PSCI reset handler, we have observed that the reset can be aborted. In TF-A's PSCI reset handler, a call out to OP-TEE is made before performing the platform-specific reset: https://github.com/ARM-software/arm-trusted-firmware/blob/master/lib/psci/p… https://github.com/ARM-software/arm-trusted-firmware/blob/master/services/s… When OP-TEE is entered, it is possible to receive foreign (normal world) interrupts, which invokes the procedure described here: https://optee.readthedocs.io/en/3.16.0/architecture/core.html#deliver-non-s… When the SMC call is aborted as described above, this results in the reboot failing. Linux does not retry the PSCI reset (https://github.com/torvalds/linux/blob/master/drivers/firmware/psci/psci.c#…). This makes sense because it is not expecting the SMC call to fail (it expected to make an uninterruptable SMC call into the secure monitor, not a call into OP-TEE). If OP-TEE itself is setup to handle PSCI reset calls, it also handles them in (uninterruptable) SMC context: https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/sm/psci.c#L140 https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/sm/sm_a32.S#L96 Based on this, we see two possible solutions: a) Masking the non-secure interrupts in BL31 while we are doing a reset b) Removing the call to OPTEE in the reset handler so that we never leave the SMC context Which option do you suggest? Or are we missing an important detail here? Thanks, Caleb

9 months, 3 weeks

2024

2023

2022

2021

2020

2019

2018

TF-A February 2024