From: Marek Vasut <marex@denx.de>
To: Francesco Dolcini <francesco.dolcini@toradex.com>
Cc: Stefano Babic <sbabic@denx.de>,
Fabio Estevam <festevam@gmail.com>,
uboot-imx@nxp.com, Tim Harvey <tharvey@gateworks.com>,
u-boot@lists.denx.de
Subject: Re: [RFC PATCH 2/3] mx6: ddr: Wait before issuing the first MRS cmd
Date: Mon, 4 Apr 2022 21:56:50 +0200 [thread overview]
Message-ID: <07f3d911-fe98-9fcd-d34d-07cee18b48b3@denx.de> (raw)
In-Reply-To: <20220404145332.GA114170@francesco-nb.int.toradex.com>
On 4/4/22 16:53, Francesco Dolcini wrote:
> Hello Marek,
> thanks for your review.
>
> On Mon, Apr 04, 2022 at 03:39:35PM +0200, Marek Vasut wrote:
>> On 4/4/22 10:51, Francesco Dolcini wrote:
>>> Wait 1ms before issuing the first MRS command to write DDR3 Mode
>>> registers.
>>>
>>> There is a requirement to wait minimum of Reset CKE Exit time, tXPR,
>>> with tXPR = max(tXS, 5tCK) and to wait 500 useconds after reset is
>>> de-asserted. It seems that for some reason this is not enforced by the
>>> MMDC controller, despite MMDCx_MDOR RST_to_CKE and tXPR being correctly
>>> configured.
>>>
>>> Without this change we experienced random memory initialization failures
>>> with about 2% boot failure rate on specific problematic boards, after
>>> this change we were able to do more than 10.000 power-cycle without a
>>> single failure.
>>>
>>> Fixes: fe0f7f7842e1 ("mx6: add mmdc configuration for MX6Q/MX6DL")
>>> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
>>> ---
>>> arch/arm/mach-imx/mx6/ddr.c | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/arch/arm/mach-imx/mx6/ddr.c b/arch/arm/mach-imx/mx6/ddr.c
>>> index 08e2f0f130a6..7b3d620094c4 100644
>>> --- a/arch/arm/mach-imx/mx6/ddr.c
>>> +++ b/arch/arm/mach-imx/mx6/ddr.c
>>> @@ -1526,6 +1526,8 @@ void mx6_ddr3_cfg(const struct mx6_ddr_sysinfo *sysinfo,
>>> ((sysinfo->ncs == 2) ? 1 : 0) << 30; /* SDE_1 for CS1 */
>>> /* Step 8: Write Mode Registers to Init DDR3 devices */
>>> + mdelay(1); /* Wait before issuing the first MRS command
>>> + (tXPR / 500us CKE delay after reset deassertion) */
>>
>> Should we infer this delay from tXPR instead ?
>
> I could just delay(tXPR + 500us) and do the exact worst case delay.
>
> However I wonder if it is worth doing it, the 1ms delay works in
> practice, it is big enough to be correct in any case, but small enough
> not to be a concern on the boot time.
>
> Please note that I do not know which timing is violated here
> (tXPR, the 500us after reset de-assertion or both of them).
Can the tXPR ever be larger than 500us ?
next prev parent reply other threads:[~2022-04-04 19:57 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-04 8:51 [RFC PATCH 0/3] Fix iMX6 DDR configuration issues and update toradex apalis-imx6 Francesco Dolcini
2022-04-04 8:51 ` [RFC PATCH 1/3] mx6: ddr: Restore ralat/walat in write level calibration Francesco Dolcini
2022-04-04 13:40 ` Marek Vasut
2022-04-04 8:51 ` [RFC PATCH 2/3] mx6: ddr: Wait before issuing the first MRS cmd Francesco Dolcini
2022-04-04 13:39 ` Marek Vasut
2022-04-04 14:53 ` Francesco Dolcini
2022-04-04 19:56 ` Marek Vasut [this message]
2022-04-05 9:09 ` Francesco Dolcini
2022-04-05 9:28 ` Marek Vasut
2022-04-04 8:51 ` [RFC PATCH 3/3] board: apalis_imx6: DDR init using mx6_dram_cfg() Francesco Dolcini
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=07f3d911-fe98-9fcd-d34d-07cee18b48b3@denx.de \
--to=marex@denx.de \
--cc=festevam@gmail.com \
--cc=francesco.dolcini@toradex.com \
--cc=sbabic@denx.de \
--cc=tharvey@gateworks.com \
--cc=u-boot@lists.denx.de \
--cc=uboot-imx@nxp.com \
/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