From: Joakim Tjernlund <joakim.tjernlund@transmode.se>
Date: Thu, 12 Nov 2015 07:35:49 +0000
Subject: [U-Boot] [PATCH v1 0/7] Enable high speed and heavy load for
 DDR4 for LSCH3
In-Reply-To: <563BC04D.3030000@freescale.com>
References: <1446660203-18047-1-git-send-email-yorksun@freescale.com>
 <1446710633.21216.119.camel@transmode.se>
 <DM2PR03MB57442D557F7409E3425AF13FA290@DM2PR03MB574.namprd03.prod.outlook.com>
 <1446717317.21216.131.camel@transmode.se> <563B9501.40203@freescale.com>
 <1446747596.21216.166.camel@transmode.se> <563BA012.6010704@freescale.com>
 <1446753193.21216.168.camel@transmode.se> <563BC04D.3030000@freescale.com>
Message-ID: <1447313748.13088.51.camel@transmode.se>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On Thu, 2015-11-05 at 12:47 -0800, York Sun wrote:
> 
> On 11/05/2015 11:53 AM, Joakim Tjernlund wrote:
> > On Thu, 2015-11-05 at 10:29 -0800, York Sun wrote:
> > > 
> > > On 11/05/2015 10:19 AM, Joakim Tjernlund wrote:
> > > > On Thu, 2015-11-05 at 09:42 -0800, York Sun wrote:
> > > > > 
> > > > > On 11/05/2015 01:55 AM, Joakim Tjernlund wrote:
> > > > > > On Thu, 2015-11-05 at 08:23 +0000, Yuantian Tang wrote:
> > > > > > > Hi Jocke,
> > > > > > > 
> > > > > > > we achieved deep sleep mode that did exactly what you asked for.
> > > > > > > If waken up from deep sleep, soc will resume from uboot and re-initialized DDR controller with
> > > > > > > contents
> > > > > > > untouched.
> > > > > > > Please refer to drivers/ddr/fsl/fsl_ddr_gen4.c and look at DEEP_SLEEP related code.
> > > > > > 
> > > > > > Looking at it now and it looks the same as for ddr3? Some questions though:
> > > > > > ?289		if (is_warm_boot()) {
> > > > > > ?289?????????????????/* enter self-refresh */
> > > > > > ?290?????????????????temp_sdram_cfg = ddr_in32(&ddr->sdram_cfg_2);
> > > > > > ?291?????????????????temp_sdram_cfg |= SDRAM_CFG2_FRC_SR;
> > > > > > ?292?????????????????ddr_out32(&ddr->sdram_cfg_2, temp_sdram_cfg);
> > > > > > 
> > > > > > Why do you need to force SR here? The DDR RAM must already be in SR at this point?
> > > > > > I come from CPU reset state so my DDR controller has HW default values so
> > > > > > this does not feel safe.
> > > > > 
> > > > > This may be redundant. If the code runs to this line, it should come back from a
> > > > > deep sleep. The core is in reset state but the DDR controller is not. It should
> > > > > be in self-refresh mode. I will leave that to Yuantian to comment.
> > > > 
> > > > OK
> > > > 
> > > > > 
> > > > > > 
> > > > > > ?293?????????????????/* do board specific memory setup */
> > > > > > ?294?????????????????board_mem_sleep_setup();
> > > > > > ?295 
> > > > > > ?296?????????????????temp_sdram_cfg = (ddr_in32(&ddr->sdram_cfg) | SDRAM_CFG_BI);
> > > > > > SDRAM_CFG_BI skips a lot(all?) init of DDR RAM. What if you want to change some DDR RAM
> > > > > > timing/config due to a bug? Then you would have to force a cold start.
> > > > > > 
> > > > > > Do you use ECC? Seems to be some issues with ECC if you skip D_INIT
> > > > > > 
> > > > > 
> > > > > To perform a warm start, the data in DDR is preserved. So you don't need to init
> > > > > the data again for ECC. To preserve data, you cannot run D_INIT again, which
> > > > > will destroy the data for sure.
> > > > 
> > > > yes, but what about SDRAM_CFG_BI? Why do you need to set that here?
> > > > I much rather just skip D_INIT and reconfigure DDR RAM, just in case one wants
> > > > to correct some aspect of DDR config in later releases and feels a lot more robust.
> > > > 
> > > > Our systems cannot be coldstarted just because you upgrade SW on them.
> > > 
> > > Jocke,
> > > 
> > > If your memory has been intialized, you can set [BI] bit to bypass
> > > re-initialization. It does different things than D_INIT. In short, D_INIT
> > > initialize the data, i.e. the content of DDR, while BI bypassing initializing
> > > DDR memory (or "chip" if that is easier to understand).
> > 
> > Yes, that is what I want, reinit of chip, but not data contents.
> > I wrote why:
> > "just in case one wants to correct some aspect of DDR config in later releases and feels a lot more
> > robust"
> 
> Jocke,
> 
> I am not 100% sure. I will take this question to our DDR designer.

I am really want to know ...