From: York Sun <yorksun@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v1 0/7] Enable high speed and heavy load for DDR4 for LSCH3
Date: Thu, 5 Nov 2015 12:47:09 -0800 [thread overview]
Message-ID: <563BC04D.3030000@freescale.com> (raw)
In-Reply-To: <1446753193.21216.168.camel@transmode.se>
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.
York
next prev parent reply other threads:[~2015-11-05 20:47 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-04 18:03 [U-Boot] [PATCH v1 0/7] Enable high speed and heavy load for DDR4 for LSCH3 York Sun
2015-11-04 18:03 ` [U-Boot] [PATCH v1 1/7] driver/ddr/fsl: Update DDR4 RTT values York Sun
2015-11-04 18:03 ` [U-Boot] [PATCH v1 2/7] driver/ddr/fsl: Update DDR4 MR6 for Vref range York Sun
2015-11-04 18:03 ` [U-Boot] [PATCH v1 3/7] driver/ddr/fsl: Update MR5 RTT park York Sun
2015-11-04 18:03 ` [U-Boot] [PATCH v1 4/7] driver/ddr/fsl: Update workaround for A008511 for vref range York Sun
2015-11-04 18:03 ` [U-Boot] [PATCH v1 5/7] driver/ddr/fsl: Update timing config for heavy load York Sun
2015-11-04 18:03 ` [U-Boot] [PATCH v1 6/7] armv8/ls2085aqds: Update DDR settings for four chip-select case York Sun
2015-11-04 18:03 ` [U-Boot] [PATCH v1 7/7] armv8/ls2085ardb: " York Sun
2015-11-05 8:03 ` [U-Boot] [PATCH v1 0/7] Enable high speed and heavy load for DDR4 for LSCH3 Joakim Tjernlund
2015-11-05 8:23 ` Yuantian Tang
2015-11-05 9:55 ` Joakim Tjernlund
2015-11-05 17:42 ` York Sun
2015-11-05 18:19 ` Joakim Tjernlund
2015-11-05 18:29 ` York Sun
2015-11-05 19:53 ` Joakim Tjernlund
2015-11-05 20:47 ` York Sun [this message]
2015-11-12 7:35 ` Joakim Tjernlund
2015-11-12 16:43 ` York Sun
2015-11-06 2:24 ` Yuantian Tang
2015-11-06 11:10 ` Joakim Tjernlund
2015-12-15 0:41 ` York Sun
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=563BC04D.3030000@freescale.com \
--to=yorksun@freescale.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox