Hi,

On 9/6/22 16:53, Jorge Ramirez-Ortiz, Foundries wrote:
On 06/09/22, Patrick DELAUNAY wrote:
Hi,

On 9/5/22 19:33, Jorge Ramirez-Ortiz wrote:
Enabling CONFIG_SYSRESET_PSCI prevents CONFIG_RESET_SCMI
from executing.

The side effect observed are I2C devices no longer being
accessible from U-boot after a soft reset.

Fixes: 11517ccc8c52 ("configs: add stm32mp13 defconfig")
Fixes: 17aeb589fa9d ("stm32mp15: remove configs dependency on
                        CONFIG_TFABOOT")

Signed-off-by: Jorge Ramirez-Ortiz <jo...@foundries.io>
---
   configs/stm32mp13_defconfig         | 1 -
   configs/stm32mp15_defconfig         | 1 -
   configs/stm32mp15_trusted_defconfig | 1 -
   3 files changed, 3 deletions(-)

The reset driver (used to managed Hardware device reset with RCC)

based on RCC register or on SCMI for 'system' / 'secured' ressource

and the sysret for global platform based on PSCI are indendent.
Yes. But AFAICS in the trace only one executes during the sys reset walk and
PSCI gets in first (so SCMI doesnt run when U-boot reboots).


For my understanding the STM32MP15 Linux Kernel also use

PSCI for reset (for command reboot)

drivers/firmware/psci/psci.c::psci_sys_reset

ref: https://wiki.st.com/stm32mpu/wiki/Power_overview


You should have also the issue with reboot command in Linux...


And for SCMI device tree or downstream the PSCI is the only support

SYSRESET driver supported (SYSCON on RCC not available on secured

device and I don't known SCMI sysreset driver in U-Boot)


We have also STPMIC1 sysreset support by only when the PMIC is managed by U-Boot

(present in U-Boot device DT, not secured).


STM32MP> dm tree
 Class     Index  Probed  Driver                Name
-----------------------------------------------------------
 root          0  [ + ]   root_driver           root_driver
 firmware      0  [   ]   psci                  |-- psci
 sysreset      0  [   ]   psci-sysreset         |   `-- psci-sysreset
 i2c           1  [ + ]   stm32f7-i2c           |   |-- i2c@5c002000
 i2c_generi    0  [   ]   stusb160x             |   |   |-- stusb1600@28
 pmic          0  [ + ]   stpmic1_pmic          |   |   `-- stpmic@33

...
 misc          0  [   ]   stpmic1-nvm           |   |       |-- stpmic1-nvm
 sysreset      1  [   ]   stpmic1-sysreset      |   |       `-- stpmic1-sysreset


For me, the PSCI can be used in the sysreset_walk() without issue on I2C devices

managed in secure world or in non secure world

(tested on STMicroelectronics boards with several I2C device

  = STPMIC, STUSB1600, STMFX, touchscreen, panel...).


But we don't test I2C device used by booth worlds.


Deactivate CONFIG_SYSRESET_PSCI only prevent soft reset support
with the command reset or after crash.
Also AFAICS, the kernel only uses SCMI for reset (which probably explains why
OP-TEE controlled I2C devices still work when the board reboots).


I don't think it is the correct solution if the I2C devices is no longer 
accessible
after SW reset.

i think that it is more a bug / problem for reinit of I2C in STM32 driver
so the configuration is not correct after a SW reset.
Not sure about that...but lets find out because something is wrong for sure.


We have not detect this issue for I2C communication to PMIC after SW reset.
that could be because the PMIC uses the only I2C mode that works with
OP-TEE (the master transfer mode is broken until my fixes are merged...hopefully
soon)


Can you provide more information for your use-case, for reproduction on my
side

- platform used (STM32MP13 or STM32MP15), board used
STM32MP15

- I2C instance used and I2C device connected
NXPSE050 - i2c in master xfer mode, accessible only from OP-TEE
https://www.nxp.com/docs/en/data-sheet/SE050-DATASHEET.pdf


So in your use-case, if I correctly understood


1/ I2C accesses in OP-TEE to NXPSE050 in secure world = OP-TEE I2C driver

2/ jump to normal world during boot = U-Boot

3/ I2C accesses in U-Boot (or kernel ?) to NXPSE050 in normal world => U-Boot I2C driver

4/ <<< reset request in U-Boot !? >>>

a) when PSCI sysreset is used (without your patch)

      => PSCI stack manage in OP-TEE request system reset....

            => psci_system_reset()
              =>   io_write32(rcc_base + RCC_MP_GRSTCSETR, RCC_MP_GRSTCSETR_MPSYSRST);


      => OP-TEE I2C driver failed after reboot !?

            it is the problem


b) when an other sysreset is used, STPMIC1 ?

     => OP-TEE I2C driver ok after reboot

           I assumed that here that STPMIC1 is used, it is the only other sysreset supported

           so it is a cold boot has the STM32MP15x supply is shut-down


so my analysis:

    you have a I2C issue when the same I2C instance is used in OP-TEE and in normal world

    after a application / system reset generated by RCC_MP_GRSTCSETR.MPSYSRST

    the I2C bus that you are using for NXPSE050 is not correctly re-initialized and communication failed


At this point I don't understood the root cause of the issue,

as all the I2C instances (in master mode) are reseted in STM32MP15 MPU after a system reset

(including clock and pincontrol configuration) and the init of the I2C IP is done again

in OP-TEE after a system reset.


So for the OP-TEE I2C driver the cold bot and boot after system reset have no difference

(the I2C IP registers and internal state are reseted).


I see only one reason to have communication issue:

  the I2C bus is frozen by a I2C device on this bus (NXPSE050, ...)


Perhaps the I2C device NXPSE050 is not reinitialized on STM32MP15x system reset

(see app_rst or nreset in reference manuel),  the MPU reset signal is really propagated to

each device on the I2C bus in you HW design ?.


For me no more using PSCI syreset driver in U-Boot only mask the issue on I2C bus:

that avoids to have a WARM RESET performed with RCC application reset done in OP-TEE PSCI stack

and replaced it by a STPMIC1 reset.


For STMicroelectronics board, the STPMIC1 access can be secured (only accessible by OP-TEE)

then the PSCI sysreset is the only / the main / preferred supported sysreset for non-secure (U-Boot or Linux),

This option should keep in the STMicroelectronics defconfigs, used with the STMicroelectronics device tree.


but you can create your defconfig for your board if you really deactivet it.


or you can modify the device tree for your board:


in kernel DT file = = ./arch/arm/dts/stm32mp157c-<youboard>.dts

or in addon file = ./arch/arm/dts/stm32mp157c-<youboard>-u-boot.dtsi


option 1 => degrade PSCI support to 0.1 to deactivate the sysreset support

/ {
    psci {
        compatible = "arm,psci-0.1";
    };

  };


option 2 => deactivate the PSCI support (including the power-off support)


/ {

    /delete-node/ psci;

  };



- version of TF-A / OP-TEE used
OP-TEE: 3.18
TF-A: 2.7.0


Patrick



Patrick

Reply via email to