DDR3 self-refresh entry/exit sequence

[falstaff]

We try to implement suspend/resume in Linux with LPSTOP2 support (retain 16KB of data) on vanilla/mainline Linux kernel. Similar to the i.MX6 and Timesys Linux 3.0 kernel suspend/resume support, I relocate an assembler function into SRAM and go to deep sleep in there.

So far, the sleep part does the following steps:

• Save current memory registers
• Setup CCM_LPCR, GPC_PGCR and friends
  
• Flush D-cache
• Put the memory explicitly in self-refresh mode using LP_CMD(0xA), and wait for completion of this command
• Setup GPR0/GPR1 register
• Execute WFI instruction

The resume function executes this steps:

• Invalidate L1 cache
  
• Mask interrupts
  
• Ungate UART, ANADIG, SCSM, GPC, CCM, WKUP and MMDC
• Enable slow oscillators
• Enable fast oscillators and select external FOSC
• Enable PLL1/PLL2 and wait for lock (we use PLL2 as memory clock source...)
• Restore memory registers
• [Set PWUP_SREF_EX in CR34, see 2 below]
• Start memory controller (set START bit of DDRMC_CR00)
• Stopping self-refresh mode using LP_CMD(0x9)
  
• Jump to standard Linux resume routine in DDR memory (cpu_resume)
  

This works quite reliable, including jumping back to DDR and continue executing C-code. Currently, somewhere in the code located in DDR RAM, the kernel crashes. It is not yet clear why, but this is not my main concern here.

However, what I discovered when connecting a scope, that the memory controller is driving the RESET# signal to low, both when putting the memory into sleep state as well as when waking up the memory (see attached scope screenshots). We do have an external pull-up on the DDR3 RESET# (yellow in scope) signal as well as a pull-down on the CKE (blue in scope) signal. Those are my questions:

1. Is it ok that the memory controller issues a reset right before going to sleep (as shown in DDR3_SelfRefreshEntry.TIF). In my understanding, this resets the DDR3 memory, which would invalidate the self-refresh command... If reset commands are not harmful while in self-refresh, I guess the pull-up for the RESET# signal would not be required...?
2. Is it ok that the memory controller issues a reset right when waking up (see DDR3_SelfRefreshExit.TIF). I found the PWUP_SREF_EX bit, however when setting this bit, I cannot access the memory after initialization... (DDR3_SelfRefreshExitWith_PWUP_SREF_EX.TIF)
3. In chapter 34.6.6 Low Power Operation, the text says that Self-Refresh with Memory Clock Gating and Self-Refresh with Memory and Controller Clock Gating is only valid for LPDDR2. What does this mean exactly? As fair as I understood the low power architecture, the MMDC (memory controller) is in PD1, hence it will be turned off. In my understanding, this would mean that Memory and Controller Clock will be gated...  Is DDR3 self-refresh with LPSTOPx modes possible at all?

--

Stefan

[naoumgitnik]

Dear Stefan,

This sequence has been discussed in detail, with a sample code, on the internal Community space ("Vybrid-FAE") for the Freescale FAEs. They have a right to share a relevant part of this information with our customers.

There is no need for you to develop it from scratch - feel free to turn to a local Freescale FAE in your region to get this information.

Sincerely, Naoum Gitnik.

[falstaff]

Hi Naoum,

I have demo code from our local FAE called "Vybrid Low Power Demo Code". However, most is implemented in C, but on Linux I don't have a "full C" environment in SRAM. Like it is realized for i.MX6, the final suspend and the early resume logic is implemented in assembler which is relocated during runtime to SRAM when the user requests suspend to RAM. So it needs to be (re)implemented.

However, my main concern is not the implementation, I mainly point out the details of my implementation to draw a better picture of what we are doing... The main issue is the DDR3 Reset the controller is asserting. And we have so far not found a way to avoid that.

--

Stefan

[naoumgitnik]

Hello Stefan,

Got it.

Let's wait for a comment from Timesys Support.

Regards, Naoum Gitnik.

[falstaff · Accepted solution]

Hi Naoum,

Just "discovered" by chance the MISC2_0 bit in the SRC module, description says:

DDR RESET control on Standby

0 DDR memory reset is driven by DDR PHY

1 will remain high (inactive)

Sounds very promising! And indeed, verification showed, the DDR3 RESET signal is not driven low anymore! Yay! So with that, this thread can be closed.

--

Stefan

[karina_valencia]

timesyssupport do you have an update of this case?

[karina_valencia]

timesyssupport can you attend this case?