From mboxrd@z Thu Jan 1 00:00:00 1970 From: York Sun Date: Thu, 12 Nov 2015 08:43:18 -0800 Subject: [U-Boot] [PATCH v1 0/7] Enable high speed and heavy load for DDR4 for LSCH3 In-Reply-To: <1447313748.13088.51.camel@transmode.se> References: <1446660203-18047-1-git-send-email-yorksun@freescale.com> <1446710633.21216.119.camel@transmode.se> <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> <1447313748.13088.51.camel@transmode.se> Message-ID: <5644C1A6.1060209@freescale.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 11/11/2015 11:35 PM, Joakim Tjernlund wrote: > 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 ... > I haven't heard anything back yet. York