How to Resume from LPSR mode on imx7D sabre

[mooreaa]

Hello,

We’re working with a imx7D sabre board (EVK) and trying to test LPSR mode, but we’re not able to resume once the system enters the low power mode.

To enable LPSR, we modified the dts file per imx7d-12x12-lpddr3-arm2.dt (details below). Boot log shows message: LPSR mode enabled, DSM will go into LPSR mode!

We let the system enter LPSR mode via: “echo mem > /sys/power/state”  This results in power rails being disabled (except VSNVS and VLPSR).

However, once in LPSR mode, pressing the ON/OFF push button on the SABRE board results in the system cold booting (loading uboot and then OS) rather than resuming.

We're running the 4.1.15_ga_1.0.0 kernel and Yocto FS.

Did we miss something? Seems LPSR is supported on the arm2 board but I don't see any particular info on this configuration except the dts.

Thank you

Changes applied to add support for lpsr are based on the following dts for the arm2 board: http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/arch/arm/boot/dts/imx7d-12x12-lpddr...

diff --git a/arch/arm/boot/dts/imx7d-sdb.dts b/arch/arm/boot/dts/imx7d-sdb.dts

index 09089bb..ea2bc21 100644

--- a/arch/arm/boot/dts/imx7d-sdb.dts

+++ b/arch/arm/boot/dts/imx7d-sdb.dts

@@ -296,13 +296,15 @@

&i2c1 {

       clock-frequency = <100000>;

-       pinctrl-names = "default";

+       pinctrl-names = "default", "sleep";

       pinctrl-0 = <&pinctrl_i2c1>;

+       pinctrl-1 = <&pinctrl_i2c1>;

       status = "okay";

       pmic: pfuze3000@08 {

               compatible = "fsl,pfuze3000";

               reg = <0x08>;

+               fsl,lpsr-mode;

               regulators {

                       sw1a_reg: sw1a {

@@ -1008,6 +1009,10 @@

       };

};

+&ocrams {

+       fsl,enable-lpsr;

+};

+

&pcie {

       pinctrl-names = "default";

       reset-gpio = <&gpio_spi 1 GPIO_ACTIVE_LOW>;

[igorpadykov]

agree, linux saves lpsr return address in IOMUXC_LPSR_GPR_IOMUXC_LPSR_GPR0
(#0x30270000) and plugin checks whether it is a valid LPSR resume address and if !=0 , puts
DDR out of self-refresh and jumps there
http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/tree/board/freescale/mx7d_12x12_lpddr3_arm2/...
..
    /* jump to kernel resume */
    ldr    r1, =0x30270000
    ldr    r7, [r1]
    mov    pc, r7
kernel sets it in imx7_pm_set_lpsr_resume_addr(), pm-imx7.c
http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/arch/arm/mach-imx/pm-imx7.c?h=imx_4...
lpsr power design is given in RM :

[igorpadykov]

Hi Aaron

you are right, arm2 board populated with lpddr3 while sdb with ddr3

and NVCC_DRAM which powers ddr3, is turned off in lpsr mode.

In arm2 board lpddr3 has several ddr power lines (NVCC_DRAM, NVCC_DRAM_SW,

NVCC_1V8) which used differently.

Schematics (2)
Design files for i.MX 7Dual (REV D)
Design files, including hardware schematics, Gerbers, and OrCAD files for i.MX 7Dual (REV D)
http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/i.mx-applications-process...

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[ericnelsonaz]

Thanks Igor,

Do you know if there's a reason that the SABRE-SD doesn't have a configuration for use with LPSR?

The patch adding enable-lpsr to the ARM2 board says the following:

    Add property "fsl,enable-lpsr" to enable lpsr mode by default, when this property is set, DSM

    mode will go into LPSR mode.

    As many modules save/restore is NOT ready, to make tiny kernel enter/exit LPSR mode work,

    only enable those necessary modules for now.

    Other modules will be enabled after their drivers are ready to support LPSR mode.

We've tried cutting the device tree used for testing down to the minimal (UART + SD card), but see the same results, and it's not clear whether some updates are needed to U-Boot (to configure the PMIC), or whether there's something specific to the ARM2 in the kernel code.

The comments above hint that perhaps Anson Huang knows the answer.

[igorpadykov]

Hi Eric

every board specification is defined my marketing,

I do not know reasons why one board implemented

some features and other not. SABRE-SD and ARM2

board have compeltely different ddr3 chips: one ddr3 another lpddr3.

Memory power design of these boards are quite different.

Best regards
igor

[ericnelsonaz]

Be careful Igor. Anson may not like being called "marketing"! :smileyhappy:

I understand that the boards are different, but was hoping some guidance about this feature on the EVK.

[igorpadykov]

According to lpddr3 jedec in self refresh mode power supply pins (VDD1, VDD2,
and VDDCA) must be at valid levels, while VDDQ may be turned off during Self-Refresh.
On ARM2 board NVCC_DRAM_SW power line is connected to processor
NVCC_DRAM and lpddr3 VDDQ and may be turned off during LPSR mode.

Following  ddr3 jedec for self refresh operation, all power supply and reference pins
(VDD, VDDQ, VSS, VSSQ, VRefCA and VRefDQ) must be at valid levels.
(VrefDQ supply may be turned OFF). In i.MX7D Sabre SD processor
NVCC_DRAM connected to memory VDD, VDDQ lines. So putting processor
to LPSR mode (Table 5-4. Power Mode i.MX7 RM) turns off NVCC_DRAM and
powers off memory, loosing all data.

Best regards
igor

[ericnelsonaz]

The voltages are definitely not configured for power-off mode, and the SABRE SD equivalent of this patch for the mx7d_12x12_lpddr3_arm2 board is necessary to enable power to remain on for some rails.

It appears that some other changes to U-Boot are also needed though.

While trying to understand where DDR is taken out of self-refresh in LPSR mode, I ran across this patch for the mx7d_12x12_lpddr3_arm2 board. If I understand this correctly, the LPSR resume process actually boots through the boot rom, which will load U-Boot and that U-Boot must be configured with a plugin that operates out of internal RAM by un-commenting this #define in the board's configuration header file.

[ericnelsonaz]

Thanks Igor!

This was exactly the feedback we were hoping for.