[PATCH] configs: stm32mp*: fix system reset

[Patrick DELAUNAY]

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 <jorge at 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 at 5c002000
  i2c_generi    0  [   ]   stusb160x             |   |   |-- stusb1600 at 28
  pmic          0  [ + ]   stpmic1_pmic          |   |   `-- stpmic at 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