Re: [RFCv1 0/8] RK3399 clean shutdown issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 09/12/2019 1:37 pm, Peter Geis wrote:
On Mon, Dec 9, 2019 at 8:29 AM Robin Murphy <robin.murphy@xxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/linux-rockchip



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux