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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot