| Message ID | 20191206184536.2507-1-linux.amoon@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | RK3399 clean shutdown issue | expand |
Hi Anand, Am Freitag, 6. Dezember 2019, 19:45:28 CET schrieb Anand Moon: > Most of the RK3399 SBC boards do not perform clean > shutdown and clean reboot. > > These patches try to help resolve the issue with proper > shutdown by turning off the PMIC. > > For reference > RK805 PMCI data sheet: > [0] http://rockchip.fr/RK805%20datasheet%20V1.3.pdf > RK808 PMIC data sheet: > [1] http://rockchip.fr/RK808%20datasheet%20V1.4.pdf > RK817 PMIC data sheet: > [2] http://rockchip.fr/RK817%20datasheet%20V1.01.pdf > RK818 PMIC data sheet: > [3] http://rockchip.fr/RK818%20datasheet%20V1.0.pdf > > Reboot issue: > My guess is that we need to some proper sequence of > setting to PMCI to perform clean. > > If you have any input please share them. The rk8xx pmics may not on all devices be responsible for powering down the device. That is what the system-power-controller dt-property is for. So that property is there for a reason - to indicate that the pmic is responsible for power-off-handling. Heiko > Tested on SBC > Rock960 Model A > Odroid N1 > Rock64 > > -Anand Moon > > Anand Moon (8): > mfd: rk808: Refactor shutdown functions > mfd: rk808: use syscore for RK805 PMIC shutdown > mfd: rk808: use syscore for RK808 PMIC shutdown > mfd: rk808: use syscore for RK818 PMIC shutdown > mfd: rk808: cleanup unused function pointer > mfd: rk808: use common syscore for all PMCI for clean shutdown > arm64: rockchip: drop unused field from rk8xx i2c node > arm: rockchip: drop unused field from rk8xx i2c node > > arch/arm/boot/dts/rk3036-kylin.dts | 1 - > arch/arm/boot/dts/rk3188-px3-evb.dts | 1 - > arch/arm/boot/dts/rk3288-evb-rk808.dts | 1 - > arch/arm/boot/dts/rk3288-phycore-som.dtsi | 1 - > arch/arm/boot/dts/rk3288-popmetal.dts | 1 - > arch/arm/boot/dts/rk3288-tinker.dtsi | 1 - > arch/arm/boot/dts/rk3288-veyron.dtsi | 1 - > arch/arm/boot/dts/rk3288-vyasa.dts | 1 - > arch/arm/boot/dts/rv1108-elgin-r1.dts | 1 - > arch/arm/boot/dts/rv1108-evb.dts | 1 - > arch/arm64/boot/dts/rockchip/px30-evb.dts | 1 - > arch/arm64/boot/dts/rockchip/rk3328-a1.dts | 1 - > arch/arm64/boot/dts/rockchip/rk3328-evb.dts | 1 - > .../arm64/boot/dts/rockchip/rk3328-roc-cc.dts | 1 - > .../arm64/boot/dts/rockchip/rk3328-rock64.dts | 1 - > .../boot/dts/rockchip/rk3368-geekbox.dts | 1 - > arch/arm64/boot/dts/rockchip/rk3368-lion.dtsi | 1 - > .../boot/dts/rockchip/rk3368-px5-evb.dts | 1 - > .../boot/dts/rockchip/rk3399-firefly.dts | 1 - > .../boot/dts/rockchip/rk3399-hugsun-x99.dts | 1 - > .../boot/dts/rockchip/rk3399-khadas-edge.dtsi | 1 - > .../boot/dts/rockchip/rk3399-leez-p710.dts | 1 - > .../boot/dts/rockchip/rk3399-nanopi4.dtsi | 1 - > .../boot/dts/rockchip/rk3399-orangepi.dts | 1 - > arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi | 1 - > .../boot/dts/rockchip/rk3399-roc-pc.dtsi | 1 - > .../boot/dts/rockchip/rk3399-rock-pi-4.dts | 1 - > .../boot/dts/rockchip/rk3399-rock960.dtsi | 1 - > .../boot/dts/rockchip/rk3399-rockpro64.dts | 1 - > .../boot/dts/rockchip/rk3399-sapphire.dtsi | 1 - > drivers/mfd/rk808.c | 144 +++++------------- > include/linux/mfd/rk808.h | 2 - > 32 files changed, 42 insertions(+), 134 deletions(-) > >
Hi Heiko, On Sat, 7 Dec 2019 at 04:02, Heiko Stuebner <heiko@sntech.de> wrote: > > Hi Anand, > > Am Freitag, 6. Dezember 2019, 19:45:28 CET schrieb Anand Moon: > > Most of the RK3399 SBC boards do not perform clean > > shutdown and clean reboot. > > > > These patches try to help resolve the issue with proper > > shutdown by turning off the PMIC. > > > > For reference > > RK805 PMCI data sheet: > > [0] http://rockchip.fr/RK805%20datasheet%20V1.3.pdf > > RK808 PMIC data sheet: > > [1] http://rockchip.fr/RK808%20datasheet%20V1.4.pdf > > RK817 PMIC data sheet: > > [2] http://rockchip.fr/RK817%20datasheet%20V1.01.pdf > > RK818 PMIC data sheet: > > [3] http://rockchip.fr/RK818%20datasheet%20V1.0.pdf > > > > Reboot issue: > > My guess is that we need to some proper sequence of > > setting to PMCI to perform clean. > > > > If you have any input please share them. > > The rk8xx pmics may not on all devices be responsible for powering down > the device. That is what the system-power-controller dt-property is for. > > So that property is there for a reason - to indicate that the pmic is > responsible for power-off-handling. > > Heiko > Ok, my intent was to have common framework for shutdown, restart, suspend, resume routines. -Anand
Am Samstag, 7. Dezember 2019, 06:07:49 CET schrieb Anand Moon: > Hi Heiko, > > On Sat, 7 Dec 2019 at 04:02, Heiko Stuebner <heiko@sntech.de> wrote: > > > > Hi Anand, > > > > Am Freitag, 6. Dezember 2019, 19:45:28 CET schrieb Anand Moon: > > > Most of the RK3399 SBC boards do not perform clean > > > shutdown and clean reboot. > > > > > > These patches try to help resolve the issue with proper > > > shutdown by turning off the PMIC. > > > > > > For reference > > > RK805 PMCI data sheet: > > > [0] http://rockchip.fr/RK805%20datasheet%20V1.3.pdf > > > RK808 PMIC data sheet: > > > [1] http://rockchip.fr/RK808%20datasheet%20V1.4.pdf > > > RK817 PMIC data sheet: > > > [2] http://rockchip.fr/RK817%20datasheet%20V1.01.pdf > > > RK818 PMIC data sheet: > > > [3] http://rockchip.fr/RK818%20datasheet%20V1.0.pdf > > > > > > Reboot issue: > > > My guess is that we need to some proper sequence of > > > setting to PMCI to perform clean. > > > > > > If you have any input please share them. > > > > The rk8xx pmics may not on all devices be responsible for powering down > > the device. That is what the system-power-controller dt-property is for. > > > > So that property is there for a reason - to indicate that the pmic is > > responsible for power-off-handling. > > > > Heiko > > > > Ok, my intent was to have common framework for > shutdown, restart, suspend, resume routines. That is a great goal actually :-) I guess just keep in mind that it should only handle power-off if instructed by the devicetree property.
On 06/12/2019 6:45 pm, Anand Moon wrote: > Most of the RK3399 SBC boards do not perform clean > shutdown and clean reboot. FWIW reboot problems on RK3399 have been tracked down to issues in upstream ATF, and are unrelated to the PMIC. > These patches try to help resolve the issue with proper > shutdown by turning off the PMIC. As mentioned elsewhere[1], although this is what the BSP kernel seems to do, and in practice it's unlikely to matter for the majority of devboard users like you and me, I still feel a bit uncomfortable with this solution for systems using ATF as in principle the secure world might want to know about orderly shutdowns, and this effectively makes every shutdown an unexpected power loss from secure software's point of view. Robin. [1] http://lists.infradead.org/pipermail/linux-rockchip/2019-December/028183.html > For reference > RK805 PMCI data sheet: > [0] http://rockchip.fr/RK805%20datasheet%20V1.3.pdf > RK808 PMIC data sheet: > [1] http://rockchip.fr/RK808%20datasheet%20V1.4.pdf > RK817 PMIC data sheet: > [2] http://rockchip.fr/RK817%20datasheet%20V1.01.pdf > RK818 PMIC data sheet: > [3] http://rockchip.fr/RK818%20datasheet%20V1.0.pdf > > Reboot issue: > My guess is that we need to some proper sequence of > setting to PMCI to perform clean. > > If you have any input please share them. > > Tested on SBC > Rock960 Model A > Odroid N1 > Rock64 > > -Anand Moon > > Anand Moon (8): > mfd: rk808: Refactor shutdown functions > mfd: rk808: use syscore for RK805 PMIC shutdown > mfd: rk808: use syscore for RK808 PMIC shutdown > mfd: rk808: use syscore for RK818 PMIC shutdown > mfd: rk808: cleanup unused function pointer > mfd: rk808: use common syscore for all PMCI for clean shutdown > arm64: rockchip: drop unused field from rk8xx i2c node > arm: rockchip: drop unused field from rk8xx i2c node > > arch/arm/boot/dts/rk3036-kylin.dts | 1 - > arch/arm/boot/dts/rk3188-px3-evb.dts | 1 - > arch/arm/boot/dts/rk3288-evb-rk808.dts | 1 - > arch/arm/boot/dts/rk3288-phycore-som.dtsi | 1 - > arch/arm/boot/dts/rk3288-popmetal.dts | 1 - > arch/arm/boot/dts/rk3288-tinker.dtsi | 1 - > arch/arm/boot/dts/rk3288-veyron.dtsi | 1 - > arch/arm/boot/dts/rk3288-vyasa.dts | 1 - > arch/arm/boot/dts/rv1108-elgin-r1.dts | 1 - > arch/arm/boot/dts/rv1108-evb.dts | 1 - > arch/arm64/boot/dts/rockchip/px30-evb.dts | 1 - > arch/arm64/boot/dts/rockchip/rk3328-a1.dts | 1 - > arch/arm64/boot/dts/rockchip/rk3328-evb.dts | 1 - > .../arm64/boot/dts/rockchip/rk3328-roc-cc.dts | 1 - > .../arm64/boot/dts/rockchip/rk3328-rock64.dts | 1 - > .../boot/dts/rockchip/rk3368-geekbox.dts | 1 - > arch/arm64/boot/dts/rockchip/rk3368-lion.dtsi | 1 - > .../boot/dts/rockchip/rk3368-px5-evb.dts | 1 - > .../boot/dts/rockchip/rk3399-firefly.dts | 1 - > .../boot/dts/rockchip/rk3399-hugsun-x99.dts | 1 - > .../boot/dts/rockchip/rk3399-khadas-edge.dtsi | 1 - > .../boot/dts/rockchip/rk3399-leez-p710.dts | 1 - > .../boot/dts/rockchip/rk3399-nanopi4.dtsi | 1 - > .../boot/dts/rockchip/rk3399-orangepi.dts | 1 - > arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi | 1 - > .../boot/dts/rockchip/rk3399-roc-pc.dtsi | 1 - > .../boot/dts/rockchip/rk3399-rock-pi-4.dts | 1 - > .../boot/dts/rockchip/rk3399-rock960.dtsi | 1 - > .../boot/dts/rockchip/rk3399-rockpro64.dts | 1 - > .../boot/dts/rockchip/rk3399-sapphire.dtsi | 1 - > drivers/mfd/rk808.c | 144 +++++------------- > include/linux/mfd/rk808.h | 2 - > 32 files changed, 42 insertions(+), 134 deletions(-) >
On Mon, Dec 9, 2019 at 8:29 AM Robin Murphy <robin.murphy@arm.com> wrote: > > On 06/12/2019 6:45 pm, Anand Moon wrote: > > Most of the RK3399 SBC boards do not perform clean > > shutdown and clean reboot. > > FWIW reboot problems on RK3399 have been tracked down to issues in > upstream ATF, and are unrelated to the PMIC. > > > These patches try to help resolve the issue with proper > > shutdown by turning off the PMIC. > > As mentioned elsewhere[1], although this is what the BSP kernel seems to > do, and in practice it's unlikely to matter for the majority of devboard > users like you and me, I still feel a bit uncomfortable with this > solution for systems using ATF as in principle the secure world might > want to know about orderly shutdowns, and this effectively makes every > shutdown an unexpected power loss from secure software's point of view. > > Robin. Since ATF is operating completely in volatile memory, and shouldn't be touching hardware once it passes off control to the kernel anyways, what is the harm of pulling the rug out from under it? If this idea is to prevent issues in the future, such as if ATF does gain the ability to preempt hardware control, then at that time ATF will need to be able to handle actually powering off devices using the same functionality. But as we discussed previously, ATF doesn't have this capability, so in this case any board without a dedicated power-off gpio will be unable to power off at all. Also it seems that giving ATF this functionality, with the current state of ATF, would be cost prohibitive. I personally feel that allowing the kernel to do this is a solution to the problem we have now. > > [1] > http://lists.infradead.org/pipermail/linux-rockchip/2019-December/028183.html > > > For reference > > RK805 PMCI data sheet: > > [0] http://rockchip.fr/RK805%20datasheet%20V1.3.pdf > > RK808 PMIC data sheet: > > [1] http://rockchip.fr/RK808%20datasheet%20V1.4.pdf > > RK817 PMIC data sheet: > > [2] http://rockchip.fr/RK817%20datasheet%20V1.01.pdf > > RK818 PMIC data sheet: > > [3] http://rockchip.fr/RK818%20datasheet%20V1.0.pdf > > > > Reboot issue: > > My guess is that we need to some proper sequence of > > setting to PMCI to perform clean. > > > > If you have any input please share them. > > > > Tested on SBC > > Rock960 Model A > > Odroid N1 > > Rock64 > > > > -Anand Moon > > > > Anand Moon (8): > > mfd: rk808: Refactor shutdown functions > > mfd: rk808: use syscore for RK805 PMIC shutdown > > mfd: rk808: use syscore for RK808 PMIC shutdown > > mfd: rk808: use syscore for RK818 PMIC shutdown > > mfd: rk808: cleanup unused function pointer > > mfd: rk808: use common syscore for all PMCI for clean shutdown > > arm64: rockchip: drop unused field from rk8xx i2c node > > arm: rockchip: drop unused field from rk8xx i2c node > > > > arch/arm/boot/dts/rk3036-kylin.dts | 1 - > > arch/arm/boot/dts/rk3188-px3-evb.dts | 1 - > > arch/arm/boot/dts/rk3288-evb-rk808.dts | 1 - > > arch/arm/boot/dts/rk3288-phycore-som.dtsi | 1 - > > arch/arm/boot/dts/rk3288-popmetal.dts | 1 - > > arch/arm/boot/dts/rk3288-tinker.dtsi | 1 - > > arch/arm/boot/dts/rk3288-veyron.dtsi | 1 - > > arch/arm/boot/dts/rk3288-vyasa.dts | 1 - > > arch/arm/boot/dts/rv1108-elgin-r1.dts | 1 - > > arch/arm/boot/dts/rv1108-evb.dts | 1 - > > arch/arm64/boot/dts/rockchip/px30-evb.dts | 1 - > > arch/arm64/boot/dts/rockchip/rk3328-a1.dts | 1 - > > arch/arm64/boot/dts/rockchip/rk3328-evb.dts | 1 - > > .../arm64/boot/dts/rockchip/rk3328-roc-cc.dts | 1 - > > .../arm64/boot/dts/rockchip/rk3328-rock64.dts | 1 - > > .../boot/dts/rockchip/rk3368-geekbox.dts | 1 - > > arch/arm64/boot/dts/rockchip/rk3368-lion.dtsi | 1 - > > .../boot/dts/rockchip/rk3368-px5-evb.dts | 1 - > > .../boot/dts/rockchip/rk3399-firefly.dts | 1 - > > .../boot/dts/rockchip/rk3399-hugsun-x99.dts | 1 - > > .../boot/dts/rockchip/rk3399-khadas-edge.dtsi | 1 - > > .../boot/dts/rockchip/rk3399-leez-p710.dts | 1 - > > .../boot/dts/rockchip/rk3399-nanopi4.dtsi | 1 - > > .../boot/dts/rockchip/rk3399-orangepi.dts | 1 - > > arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi | 1 - > > .../boot/dts/rockchip/rk3399-roc-pc.dtsi | 1 - > > .../boot/dts/rockchip/rk3399-rock-pi-4.dts | 1 - > > .../boot/dts/rockchip/rk3399-rock960.dtsi | 1 - > > .../boot/dts/rockchip/rk3399-rockpro64.dts | 1 - > > .../boot/dts/rockchip/rk3399-sapphire.dtsi | 1 - > > drivers/mfd/rk808.c | 144 +++++------------- > > include/linux/mfd/rk808.h | 2 - > > 32 files changed, 42 insertions(+), 134 deletions(-) > > > > _______________________________________________ > Linux-rockchip mailing list > Linux-rockchip@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-rockchip
Hi, Am Montag, 9. Dezember 2019, 14:37:28 CET schrieb Peter Geis: > On Mon, Dec 9, 2019 at 8:29 AM Robin Murphy <robin.murphy@arm.com> wrote: > > > > On 06/12/2019 6:45 pm, Anand Moon wrote: > > > Most of the RK3399 SBC boards do not perform clean > > > shutdown and clean reboot. > > > > FWIW reboot problems on RK3399 have been tracked down to issues in > > upstream ATF, and are unrelated to the PMIC. > > > > > These patches try to help resolve the issue with proper > > > shutdown by turning off the PMIC. > > > > As mentioned elsewhere[1], although this is what the BSP kernel seems to > > do, and in practice it's unlikely to matter for the majority of devboard > > users like you and me, I still feel a bit uncomfortable with this > > solution for systems using ATF as in principle the secure world might > > want to know about orderly shutdowns, and this effectively makes every > > shutdown an unexpected power loss from secure software's point of view. > > > > Robin. > > Since ATF is operating completely in volatile memory, and shouldn't be > touching hardware once it passes off control to the kernel anyways, > what is the harm of pulling the rug out from under it? Secure-world doesn't end with ATF :-) There can also be an instance of OP-TEE or another TEE on top and they often actually do secure storage encrypted onto the hosts mass storage (see kernel's optee module). > If this idea is to prevent issues in the future, such as if ATF does > gain the ability to preempt hardware control, then at that time ATF > will need to be able to handle actually powering off devices using the > same functionality. > > But as we discussed previously, ATF doesn't have this capability, so > in this case any board without a dedicated power-off gpio will be > unable to power off at all. > Also it seems that giving ATF this functionality, with the current > state of ATF, would be cost prohibitive. > > I personally feel that allowing the kernel to do this is a solution to > the problem we have now. For the rest I guess I'll just point to Robin's text and Ack under your system-power-controller patch ;-) Heiko > > [1] > > http://lists.infradead.org/pipermail/linux-rockchip/2019-December/028183.html > > > > > For reference > > > RK805 PMCI data sheet: > > > [0] http://rockchip.fr/RK805%20datasheet%20V1.3.pdf > > > RK808 PMIC data sheet: > > > [1] http://rockchip.fr/RK808%20datasheet%20V1.4.pdf > > > RK817 PMIC data sheet: > > > [2] http://rockchip.fr/RK817%20datasheet%20V1.01.pdf > > > RK818 PMIC data sheet: > > > [3] http://rockchip.fr/RK818%20datasheet%20V1.0.pdf > > > > > > Reboot issue: > > > My guess is that we need to some proper sequence of > > > setting to PMCI to perform clean. > > > > > > If you have any input please share them. > > > > > > Tested on SBC > > > Rock960 Model A > > > Odroid N1 > > > Rock64 > > > > > > -Anand Moon > > > > > > Anand Moon (8): > > > mfd: rk808: Refactor shutdown functions > > > mfd: rk808: use syscore for RK805 PMIC shutdown > > > mfd: rk808: use syscore for RK808 PMIC shutdown > > > mfd: rk808: use syscore for RK818 PMIC shutdown > > > mfd: rk808: cleanup unused function pointer > > > mfd: rk808: use common syscore for all PMCI for clean shutdown > > > arm64: rockchip: drop unused field from rk8xx i2c node > > > arm: rockchip: drop unused field from rk8xx i2c node > > > > > > arch/arm/boot/dts/rk3036-kylin.dts | 1 - > > > arch/arm/boot/dts/rk3188-px3-evb.dts | 1 - > > > arch/arm/boot/dts/rk3288-evb-rk808.dts | 1 - > > > arch/arm/boot/dts/rk3288-phycore-som.dtsi | 1 - > > > arch/arm/boot/dts/rk3288-popmetal.dts | 1 - > > > arch/arm/boot/dts/rk3288-tinker.dtsi | 1 - > > > arch/arm/boot/dts/rk3288-veyron.dtsi | 1 - > > > arch/arm/boot/dts/rk3288-vyasa.dts | 1 - > > > arch/arm/boot/dts/rv1108-elgin-r1.dts | 1 - > > > arch/arm/boot/dts/rv1108-evb.dts | 1 - > > > arch/arm64/boot/dts/rockchip/px30-evb.dts | 1 - > > > arch/arm64/boot/dts/rockchip/rk3328-a1.dts | 1 - > > > arch/arm64/boot/dts/rockchip/rk3328-evb.dts | 1 - > > > .../arm64/boot/dts/rockchip/rk3328-roc-cc.dts | 1 - > > > .../arm64/boot/dts/rockchip/rk3328-rock64.dts | 1 - > > > .../boot/dts/rockchip/rk3368-geekbox.dts | 1 - > > > arch/arm64/boot/dts/rockchip/rk3368-lion.dtsi | 1 - > > > .../boot/dts/rockchip/rk3368-px5-evb.dts | 1 - > > > .../boot/dts/rockchip/rk3399-firefly.dts | 1 - > > > .../boot/dts/rockchip/rk3399-hugsun-x99.dts | 1 - > > > .../boot/dts/rockchip/rk3399-khadas-edge.dtsi | 1 - > > > .../boot/dts/rockchip/rk3399-leez-p710.dts | 1 - > > > .../boot/dts/rockchip/rk3399-nanopi4.dtsi | 1 - > > > .../boot/dts/rockchip/rk3399-orangepi.dts | 1 - > > > arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi | 1 - > > > .../boot/dts/rockchip/rk3399-roc-pc.dtsi | 1 - > > > .../boot/dts/rockchip/rk3399-rock-pi-4.dts | 1 - > > > .../boot/dts/rockchip/rk3399-rock960.dtsi | 1 - > > > .../boot/dts/rockchip/rk3399-rockpro64.dts | 1 - > > > .../boot/dts/rockchip/rk3399-sapphire.dtsi | 1 - > > > drivers/mfd/rk808.c | 144 +++++------------- > > > include/linux/mfd/rk808.h | 2 - > > > 32 files changed, 42 insertions(+), 134 deletions(-) > > > > > > > _______________________________________________ > > Linux-rockchip mailing list > > Linux-rockchip@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-rockchip >
On 09/12/2019 1:37 pm, Peter Geis wrote: > On Mon, Dec 9, 2019 at 8:29 AM Robin Murphy <robin.murphy@arm.com> wrote: >> >> On 06/12/2019 6:45 pm, Anand Moon wrote: >>> Most of the RK3399 SBC boards do not perform clean >>> shutdown and clean reboot. >> >> FWIW reboot problems on RK3399 have been tracked down to issues in >> upstream ATF, and are unrelated to the PMIC. >> >>> These patches try to help resolve the issue with proper >>> shutdown by turning off the PMIC. >> >> As mentioned elsewhere[1], although this is what the BSP kernel seems to >> do, and in practice it's unlikely to matter for the majority of devboard >> users like you and me, I still feel a bit uncomfortable with this >> solution for systems using ATF as in principle the secure world might >> want to know about orderly shutdowns, and this effectively makes every >> shutdown an unexpected power loss from secure software's point of view. >> >> Robin. > > Since ATF is operating completely in volatile memory, and shouldn't be > touching hardware once it passes off control to the kernel anyways, > what is the harm of pulling the rug out from under it? > If this idea is to prevent issues in the future, such as if ATF does > gain the ability to preempt hardware control, then at that time ATF > will need to be able to handle actually powering off devices using the > same functionality. It's not ATF itself I'm concerned about, but arbitrary Secure EL1 payloads. In theory, a TEE might want to do something like cycle keys or log events in a TPM (or just encrypted in an external SPI flash), or scrub secure DRAM for cold boot protection. I'm pretty sure none of us are running such a thing on our boards today, but an upstream solution really wants to be robust for the general case. > But as we discussed previously, ATF doesn't have this capability, so > in this case any board without a dedicated power-off gpio will be > unable to power off at all. > Also it seems that giving ATF this functionality, with the current > state of ATF, would be cost prohibitive. > > I personally feel that allowing the kernel to do this is a solution to > the problem we have now. Sure - I do like your cool idea of using a custom reboot reason to handle a 'trusted' poweroff in the U-Boot SPL - but in the meantime anything would be a practical improvement over the current situation. I reckon this other patch[1] (this seems to be a popular issue all of a sudden!) looks like the neatest interim step. Robin. [1] http://lists.infradead.org/pipermail/linux-rockchip/2019-December/028245.html >>> For reference >>> RK805 PMCI data sheet: >>> [0] http://rockchip.fr/RK805%20datasheet%20V1.3.pdf >>> RK808 PMIC data sheet: >>> [1] http://rockchip.fr/RK808%20datasheet%20V1.4.pdf >>> RK817 PMIC data sheet: >>> [2] http://rockchip.fr/RK817%20datasheet%20V1.01.pdf >>> RK818 PMIC data sheet: >>> [3] http://rockchip.fr/RK818%20datasheet%20V1.0.pdf >>> >>> Reboot issue: >>> My guess is that we need to some proper sequence of >>> setting to PMCI to perform clean. >>> >>> If you have any input please share them. >>> >>> Tested on SBC >>> Rock960 Model A >>> Odroid N1 >>> Rock64 >>> >>> -Anand Moon >>> >>> Anand Moon (8): >>> mfd: rk808: Refactor shutdown functions >>> mfd: rk808: use syscore for RK805 PMIC shutdown >>> mfd: rk808: use syscore for RK808 PMIC shutdown >>> mfd: rk808: use syscore for RK818 PMIC shutdown >>> mfd: rk808: cleanup unused function pointer >>> mfd: rk808: use common syscore for all PMCI for clean shutdown >>> arm64: rockchip: drop unused field from rk8xx i2c node >>> arm: rockchip: drop unused field from rk8xx i2c node >>> >>> arch/arm/boot/dts/rk3036-kylin.dts | 1 - >>> arch/arm/boot/dts/rk3188-px3-evb.dts | 1 - >>> arch/arm/boot/dts/rk3288-evb-rk808.dts | 1 - >>> arch/arm/boot/dts/rk3288-phycore-som.dtsi | 1 - >>> arch/arm/boot/dts/rk3288-popmetal.dts | 1 - >>> arch/arm/boot/dts/rk3288-tinker.dtsi | 1 - >>> arch/arm/boot/dts/rk3288-veyron.dtsi | 1 - >>> arch/arm/boot/dts/rk3288-vyasa.dts | 1 - >>> arch/arm/boot/dts/rv1108-elgin-r1.dts | 1 - >>> arch/arm/boot/dts/rv1108-evb.dts | 1 - >>> arch/arm64/boot/dts/rockchip/px30-evb.dts | 1 - >>> arch/arm64/boot/dts/rockchip/rk3328-a1.dts | 1 - >>> arch/arm64/boot/dts/rockchip/rk3328-evb.dts | 1 - >>> .../arm64/boot/dts/rockchip/rk3328-roc-cc.dts | 1 - >>> .../arm64/boot/dts/rockchip/rk3328-rock64.dts | 1 - >>> .../boot/dts/rockchip/rk3368-geekbox.dts | 1 - >>> arch/arm64/boot/dts/rockchip/rk3368-lion.dtsi | 1 - >>> .../boot/dts/rockchip/rk3368-px5-evb.dts | 1 - >>> .../boot/dts/rockchip/rk3399-firefly.dts | 1 - >>> .../boot/dts/rockchip/rk3399-hugsun-x99.dts | 1 - >>> .../boot/dts/rockchip/rk3399-khadas-edge.dtsi | 1 - >>> .../boot/dts/rockchip/rk3399-leez-p710.dts | 1 - >>> .../boot/dts/rockchip/rk3399-nanopi4.dtsi | 1 - >>> .../boot/dts/rockchip/rk3399-orangepi.dts | 1 - >>> arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi | 1 - >>> .../boot/dts/rockchip/rk3399-roc-pc.dtsi | 1 - >>> .../boot/dts/rockchip/rk3399-rock-pi-4.dts | 1 - >>> .../boot/dts/rockchip/rk3399-rock960.dtsi | 1 - >>> .../boot/dts/rockchip/rk3399-rockpro64.dts | 1 - >>> .../boot/dts/rockchip/rk3399-sapphire.dtsi | 1 - >>> drivers/mfd/rk808.c | 144 +++++------------- >>> include/linux/mfd/rk808.h | 2 - >>> 32 files changed, 42 insertions(+), 134 deletions(-) >>> >> >> _______________________________________________ >> Linux-rockchip mailing list >> Linux-rockchip@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-rockchip
Hi, > On Mon, Dec 9, 2019 at 8:29 AM Robin Murphy <robin.murphy@arm.com> wrote: >> On 06/12/2019 6:45 pm, Anand Moon wrote: >>> Most of the RK3399 SBC boards do not perform clean >>> shutdown and clean reboot. >> FWIW reboot problems on RK3399 have been tracked down to issues in >> upstream ATF, and are unrelated to the PMIC. >> >>> These patches try to help resolve the issue with proper >>> shutdown by turning off the PMIC. >> As mentioned elsewhere[1], although this is what the BSP kernel seems to >> do, and in practice it's unlikely to matter for the majority of devboard >> users like you and me, I still feel a bit uncomfortable with this >> solution for systems using ATF as in principle the secure world might >> want to know about orderly shutdowns, and this effectively makes every >> shutdown an unexpected power loss from secure software's point of view. >> >> Robin. > Since ATF is operating completely in volatile memory, and shouldn't be > touching hardware once it passes off control to the kernel anyways, > what is the harm of pulling the rug out from under it? > If this idea is to prevent issues in the future, such as if ATF does > gain the ability to preempt hardware control, then at that time ATF > will need to be able to handle actually powering off devices using the > same functionality. As far as I know ATF implements PSCI, doesn't it? Thus I would assume that it should most definitely handle power off for all platforms as indicated by the presence of platform handlers in [1]. > But as we discussed previously, ATF doesn't have this capability, so > in this case any board without a dedicated power-off gpio will be > unable to power off at all. > Also it seems that giving ATF this functionality, with the current > state of ATF, would be cost prohibitive. > > I personally feel that allowing the kernel to do this is a solution to > the problem we have now. Maybe I'm missing something here but I'd suggest that implementing an i2c driver in the rockchip platform part of ATF using libfdt to find the PMIC from the devicetree would be the way to go. [1] https://github.com/ARM-software/arm-trusted-firmware/blob/master/lib/psci/psci_system_off.c#L31
Hi Robin, On Mon, 9 Dec 2019 at 18:59, Robin Murphy <robin.murphy@arm.com> wrote: > > On 06/12/2019 6:45 pm, Anand Moon wrote: > > Most of the RK3399 SBC boards do not perform clean > > shutdown and clean reboot. > > FWIW reboot problems on RK3399 have been tracked down to issues in > upstream ATF, and are unrelated to the PMIC. Yes I am aware of this changes. But, I have tired to study *RK808 datasheet V1.4* [0] below section *5.2.3 Power Channel Control/Monitor Registers* for clean reboot I was going to try disable some bit in below into reboot handle in the future patch. DCDC_EN_REG SLEEP_SET_OFF_REG1 SLEEP_SET_OFF_REG2 DCDC_UV_STS_REG I was going see if this helps to do clean reboot. further more use this in suspend/resume operation. [0] http://rockchip.fr/RK808%20datasheet%20V1.4.pdf But I feed that their is some more issue with related to mmc or PCIe not able to cleanly release the resources while reboot which caused then to disable after reboot. > > > These patches try to help resolve the issue with proper > > shutdown by turning off the PMIC. > > As mentioned elsewhere[1], although this is what the BSP kernel seems to > do, and in practice it's unlikely to matter for the majority of devboard > users like you and me, I still feel a bit uncomfortable with this > solution for systems using ATF as in principle the secure world might > want to know about orderly shutdowns, and this effectively makes every > shutdown an unexpected power loss from secure software's point of view. > > Robin. > > [1] > http://lists.infradead.org/pipermail/linux-rockchip/2019-December/028183.html > Yes I have follow the mailing list and I read this thread. I am not aware of ATF complete architecture. -Anand