Message ID | 20220905173357.2231466-1-jorge@foundries.io |
---|---|
State | Rejected |
Delegated to: | Patrice Chotard |
Headers | show |
Series | configs: stm32mp*: fix system reset | expand |
On Mon, Sep 5, 2022 at 8:34 PM Jorge Ramirez-Ortiz <jorge@foundries.io> 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@foundries.io> Acked-by: Oleksandr Suvorov <oleksandr.suvorov@foundries.io> > --- > configs/stm32mp13_defconfig | 1 - > configs/stm32mp15_defconfig | 1 - > configs/stm32mp15_trusted_defconfig | 1 - > 3 files changed, 3 deletions(-) > > diff --git a/configs/stm32mp13_defconfig b/configs/stm32mp13_defconfig > index 673b468d31..44cee2e656 100644 > --- a/configs/stm32mp13_defconfig > +++ b/configs/stm32mp13_defconfig > @@ -69,7 +69,6 @@ CONFIG_RNG_OPTEE=y > CONFIG_DM_RTC=y > CONFIG_RTC_STM32=y > CONFIG_SERIAL_RX_BUFFER=y > -CONFIG_SYSRESET_PSCI=y > CONFIG_TEE=y > CONFIG_OPTEE=y > # CONFIG_OPTEE_TA_AVB is not set > diff --git a/configs/stm32mp15_defconfig b/configs/stm32mp15_defconfig > index e5a2996c2c..2ad02f3652 100644 > --- a/configs/stm32mp15_defconfig > +++ b/configs/stm32mp15_defconfig > @@ -133,7 +133,6 @@ CONFIG_SPI=y > CONFIG_DM_SPI=y > CONFIG_STM32_QSPI=y > CONFIG_STM32_SPI=y > -CONFIG_SYSRESET_PSCI=y > CONFIG_TEE=y > CONFIG_OPTEE=y > # CONFIG_OPTEE_TA_AVB is not set > diff --git a/configs/stm32mp15_trusted_defconfig b/configs/stm32mp15_trusted_defconfig > index e14668042f..9e24e82920 100644 > --- a/configs/stm32mp15_trusted_defconfig > +++ b/configs/stm32mp15_trusted_defconfig > @@ -134,7 +134,6 @@ CONFIG_SPI=y > CONFIG_DM_SPI=y > CONFIG_STM32_QSPI=y > CONFIG_STM32_SPI=y > -CONFIG_SYSRESET_PSCI=y > CONFIG_TEE=y > CONFIG_OPTEE=y > # CONFIG_OPTEE_TA_AVB is not set > -- > 2.34.1 >
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@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. Deactivate CONFIG_SYSRESET_PSCI only prevent soft reset support with the command reset or after crash. 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. We have not detect this issue for I2C communication to PMIC after SW reset. Can you provide more information for your use-case, for reproduction on my side - platform used (STM32MP13 or STM32MP15), board used - I2C instance used and I2C device connected - version of TF-A / OP-TEE used Patrick > diff --git a/configs/stm32mp13_defconfig b/configs/stm32mp13_defconfig > index 673b468d31..44cee2e656 100644 > --- a/configs/stm32mp13_defconfig > +++ b/configs/stm32mp13_defconfig > @@ -69,7 +69,6 @@ CONFIG_RNG_OPTEE=y > CONFIG_DM_RTC=y > CONFIG_RTC_STM32=y > CONFIG_SERIAL_RX_BUFFER=y > -CONFIG_SYSRESET_PSCI=y > CONFIG_TEE=y > CONFIG_OPTEE=y > # CONFIG_OPTEE_TA_AVB is not set > diff --git a/configs/stm32mp15_defconfig b/configs/stm32mp15_defconfig > index e5a2996c2c..2ad02f3652 100644 > --- a/configs/stm32mp15_defconfig > +++ b/configs/stm32mp15_defconfig > @@ -133,7 +133,6 @@ CONFIG_SPI=y > CONFIG_DM_SPI=y > CONFIG_STM32_QSPI=y > CONFIG_STM32_SPI=y > -CONFIG_SYSRESET_PSCI=y > CONFIG_TEE=y > CONFIG_OPTEE=y > # CONFIG_OPTEE_TA_AVB is not set > diff --git a/configs/stm32mp15_trusted_defconfig b/configs/stm32mp15_trusted_defconfig > index e14668042f..9e24e82920 100644 > --- a/configs/stm32mp15_trusted_defconfig > +++ b/configs/stm32mp15_trusted_defconfig > @@ -134,7 +134,6 @@ CONFIG_SPI=y > CONFIG_DM_SPI=y > CONFIG_STM32_QSPI=y > CONFIG_STM32_SPI=y > -CONFIG_SYSRESET_PSCI=y > CONFIG_TEE=y > CONFIG_OPTEE=y > # CONFIG_OPTEE_TA_AVB is not set
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@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). > > 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 > > - version of TF-A / OP-TEE used OP-TEE: 3.18 TF-A: 2.7.0 > > > Patrick > > > > diff --git a/configs/stm32mp13_defconfig b/configs/stm32mp13_defconfig > > index 673b468d31..44cee2e656 100644 > > --- a/configs/stm32mp13_defconfig > > +++ b/configs/stm32mp13_defconfig > > @@ -69,7 +69,6 @@ CONFIG_RNG_OPTEE=y > > CONFIG_DM_RTC=y > > CONFIG_RTC_STM32=y > > CONFIG_SERIAL_RX_BUFFER=y > > -CONFIG_SYSRESET_PSCI=y > > CONFIG_TEE=y > > CONFIG_OPTEE=y > > # CONFIG_OPTEE_TA_AVB is not set > > diff --git a/configs/stm32mp15_defconfig b/configs/stm32mp15_defconfig > > index e5a2996c2c..2ad02f3652 100644 > > --- a/configs/stm32mp15_defconfig > > +++ b/configs/stm32mp15_defconfig > > @@ -133,7 +133,6 @@ CONFIG_SPI=y > > CONFIG_DM_SPI=y > > CONFIG_STM32_QSPI=y > > CONFIG_STM32_SPI=y > > -CONFIG_SYSRESET_PSCI=y > > CONFIG_TEE=y > > CONFIG_OPTEE=y > > # CONFIG_OPTEE_TA_AVB is not set > > diff --git a/configs/stm32mp15_trusted_defconfig b/configs/stm32mp15_trusted_defconfig > > index e14668042f..9e24e82920 100644 > > --- a/configs/stm32mp15_trusted_defconfig > > +++ b/configs/stm32mp15_trusted_defconfig > > @@ -134,7 +134,6 @@ CONFIG_SPI=y > > CONFIG_DM_SPI=y > > CONFIG_STM32_QSPI=y > > CONFIG_STM32_SPI=y > > -CONFIG_SYSRESET_PSCI=y > > CONFIG_TEE=y > > CONFIG_OPTEE=y > > # CONFIG_OPTEE_TA_AVB is not set
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@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
diff --git a/configs/stm32mp13_defconfig b/configs/stm32mp13_defconfig index 673b468d31..44cee2e656 100644 --- a/configs/stm32mp13_defconfig +++ b/configs/stm32mp13_defconfig @@ -69,7 +69,6 @@ CONFIG_RNG_OPTEE=y CONFIG_DM_RTC=y CONFIG_RTC_STM32=y CONFIG_SERIAL_RX_BUFFER=y -CONFIG_SYSRESET_PSCI=y CONFIG_TEE=y CONFIG_OPTEE=y # CONFIG_OPTEE_TA_AVB is not set diff --git a/configs/stm32mp15_defconfig b/configs/stm32mp15_defconfig index e5a2996c2c..2ad02f3652 100644 --- a/configs/stm32mp15_defconfig +++ b/configs/stm32mp15_defconfig @@ -133,7 +133,6 @@ CONFIG_SPI=y CONFIG_DM_SPI=y CONFIG_STM32_QSPI=y CONFIG_STM32_SPI=y -CONFIG_SYSRESET_PSCI=y CONFIG_TEE=y CONFIG_OPTEE=y # CONFIG_OPTEE_TA_AVB is not set diff --git a/configs/stm32mp15_trusted_defconfig b/configs/stm32mp15_trusted_defconfig index e14668042f..9e24e82920 100644 --- a/configs/stm32mp15_trusted_defconfig +++ b/configs/stm32mp15_trusted_defconfig @@ -134,7 +134,6 @@ CONFIG_SPI=y CONFIG_DM_SPI=y CONFIG_STM32_QSPI=y CONFIG_STM32_SPI=y -CONFIG_SYSRESET_PSCI=y CONFIG_TEE=y CONFIG_OPTEE=y # CONFIG_OPTEE_TA_AVB is not set
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@foundries.io> --- configs/stm32mp13_defconfig | 1 - configs/stm32mp15_defconfig | 1 - configs/stm32mp15_trusted_defconfig | 1 - 3 files changed, 3 deletions(-)