Our custom board design is closely based on the i.MX7 Sabre board with the addition of a FPF1504L power switch to gate the i.MX7 NVCC_DRAM rail when the system goes into LPSR mode. The power switch is controlled by the i.MX7 SNVS_TAMPER9 pin as described in section 126.96.36.199.7 DRAM IO Power of the reference manual.
I have used the latest version of the i.MX7D DRAM Register Programming Aid to determine register settings for both 400 MHz and 533 MHz DDR3L operation. I have applied these register settings to u-boot to do the DDRC/DDRP configuration using DCD data as well as the other option which uses the plugin mode for initialization. Systems successfully boot and run at either clock frequency, but operation at 533 MHz for the memory will successfully resume after the memory is put into self-refresh.
A system configured to operate at 400 MHz will hang in various ways during the resume and I see the same behavior if a powered suspend is done (i.e. PMIC stays on with i.MX7 PMIC_STBY_REQ high) or if LPSR mode is used where the PMIC is turned off and only SW3, VLDO1 and VLDO3 are left on.
- I don't see anything in the DRAM Register Programming Aid that specifies the register values for changing the CCM_ANALOG_PLL_DDR register to something other than the default of 0x0060302c for 533 MHz operation. Shouldn't this be accounted for in the DStream tab of the spreadsheet so that the clock is configured properly for 400 MHz operation?
- Is there any clock frequency dependent DDR3 self-refresh entry / exit timing that isn't accounted for in the programming aid or by the Linux suspend / resume software? I know that this is a broad question but I can't pin down why the memory is getting corrupted when self-refresh is entered / exited at a slower clock rate, but at the more common higher clock rate of 533 MHz it works very well.
Has anyone had a similar experience? I'm clearly going to use 533 MHz until further notice, but issues like this should be understood to make sure that they are not indicators of other issues.