From: Sascha Hauer <sha@pengutronix.de>
To: Matthias Feser <m.feser@kbs-gmbh.de>
Cc: barebox@lists.infradead.org
Subject: Re: AM335x DDR3 initialization / timing violation
Date: Fri, 16 Dec 2022 09:45:43 +0100 [thread overview]
Message-ID: <20221216084543.GH11668@pengutronix.de> (raw)
In-Reply-To: <3454916a.1d9106b.748ad6.4d5c@kbs-gmbh.de>
On Thu, Dec 15, 2022 at 10:54:00AM +0100, Matthias Feser wrote:
> Hi,
>
> we are using the AM3352 processor in combination with a single 512MB
> Micron DDR3 chip running the barebox bootloader in our products for
> several years now. A minor amount of boards (around 5 of 2000) fail
> the production test, because they do not boot properly after warm
> reset. In such cases the MLO is loaded, initializes the EMIF and then
> crashes after a certain amount of accesses to the DDR3. After a cold
> reset all of these boards run stable and produce no errors when
> running a deep RAM test.
>
> I am currently in discussion with a TI employee about this topic. He
> told me that the bootloader should detect a warm reset and EMIF should
> not be reinitialized, because DDR3 is automatically put into
> self-refresh on warm reset. So far he hasnt told me what the
> desired init sequence actually is. From what I have observed while
> debugging, at least the EMIF clock has to be enabled and CKE brought
> high. Unfortunately the TRM does not give guidance about this.
>
> Our board initialization code is very similar to other AM335x based
> boards like beaglebone (400MHz DDR clock), which effectively always
> initializes the EMIF in the same way by calling am335x_sdram_init(),
> no matter if cold or warm reset has brought up the processor. From
> investigating the signals DDR_RESET and DDR_CKE with an oscilloscope,
> I can tell that even with this same init code the hardware behaves
> differently in both reset cases.
>
> On cold reset both DDR_RESET and DDR_CKE remain low until
> initialization, and there is a delay of roughly 436us between the
> rising edges of DDR_RESET and DDR_CKE. After warm reset DDR_RESET is
> high and DDR_CKE is low. EMIF initialization results in a short pulse
> on DDR_RESET with 5us low phase and there is only about 38us delay
> between the rising edges of DDR_RESET and DDR_CKE.
> Both cases violate the DDR3 specification, according to which the
> delay between the rising edges of DDR_RESET and DDR_CKE has to be
> 500us min.
>
> In am33xx_config_sdram() a value of 0x2800 is written to
> EMIF4_SDRAM_REF_CTRL. TI recommends a value of 0x3100 during
> initialization, which is used in u-boot EMIF initialization code and
> does not violate the DDR3 specification. I think barebox EMIF init
> code requires some revision.
>
> I also wonder why EMIF4_SDRAM_CONFIG, REF_CTRL and REF_CTRL_SHADOW are
> accessed twice when regs->zq_config is not zero (see code snippet
> below taken from barebox 2022.12.0). Is there any reason behind this?
The code is from U-Boot.
>
> if (regs->zq_config) {
> /*
> * A value of 0x2800 for the REF CTRL will give us
> * about 570us for a delay, which will be long enough
> * to configure things.
> */
> writel(0x2800, emif4 + EMIF4_SDRAM_REF_CTRL);
> writel(regs->zq_config, emif4 + EMIF4_ZQ_CONFIG);
> writel(regs->sdram_config, CM_EMIF_SDRAM_CONFIG);
> writel(regs->sdram_config, emif4 + EMIF4_SDRAM_CONFIG);
> writel(regs->sdram_ref_ctrl, emif4 + EMIF4_SDRAM_REF_CTRL);
> writel(regs->sdram_ref_ctrl, emif4 + EMIF4_SDRAM_REF_CTRL_SHADOW);
> }
>
> writel(regs->sdram_ref_ctrl, emif4 + EMIF4_SDRAM_REF_CTRL);
> writel(regs->sdram_ref_ctrl, emif4 + EMIF4_SDRAM_REF_CTRL_SHADOW);
> writel(regs->sdram_config, emif4 + EMIF4_SDRAM_CONFIG);
>
The second access to EMIF4_SDRAM_REF_CTRL goes down to U-Boot commit
1c382ead7a00 ("am33xx: Update DDR3 EMIF configuration sequence"). This
commit also introduces the 0x2800 value we still find in barebox.
The 0x2800 value was removed in fc46bae2ae38 ("arm: am437x: Enable
hardware leveling for EMIF"). In this commit we also see the value
0x3100 for the first time.
I can't say much more to this, except that I am happy to accept patches
to clean that up.
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
prev parent reply other threads:[~2022-12-16 8:47 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-15 9:54 Matthias Feser
2022-12-16 8:45 ` Sascha Hauer [this message]
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=20221216084543.GH11668@pengutronix.de \
--to=sha@pengutronix.de \
--cc=barebox@lists.infradead.org \
--cc=m.feser@kbs-gmbh.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