public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCHv3 2/3] driver/ddr/altera/: Add the sdram calibration portion
Date: Thu, 28 May 2015 20:18:32 +0200	[thread overview]
Message-ID: <201505282018.32492.marex@denx.de> (raw)
In-Reply-To: <55673726.9030600@opensource.altera.com>

On Thursday, May 28, 2015 at 05:41:26 PM, Dinh Nguyen wrote:
> On 05/25/2015 08:23 AM, Wolfgang Denk wrote:
> > Dear Pavel,
> > 
> > In message <20150525123750.GD9943@amd> you wrote:
> >>> + ** All global variables that are explicitly initialized (including   
> >>>       ** + ** explicitly initialized to zero), are only initialized
> >>> once, during       ** + ** configuration time, and not again on reset.
> >>>  This means that they        ** + ** preserve their current contents
> >>> across resets, which is needed for some  ** + ** special cases
> >>> involving communication with external modules.  In         ** + **
> >>> addition, this avoids paying the price to have the memory initialized,
> >>>   ** + ** even for zeroed data, provided it is explicitly set to zero
> >>> in the code, ** + ** and doesn't rely on implicit initialization.     
> >>>                        ** +
> >>> **********************************************************************
> >>> ******** +
> >> 
> >> Is this sane thing to do? How does it work for variables in other
> >> sources?
> > 
> > My concern is if this is actually true (and I asked this before, in an
> > earlier round ov reviews).   I cannot make heads or tails of this
> > comment, as I don't understand what "configuration time" and "reset"
> > are supposed to mean in U-Boot context.  In my understanding, after a
> > reset the memory content is uninitialized, i. e. random, and thus MUST
> > always be properly initialized.

Meh, since there's a pushback, I'll wait a bit with applying these until
these remaining concerns settle :-/

> This comment is related to the configuration where we have the NiOS cpu
> doing the ddr calibration and is not applicable for the Cyclone5/Arria5.
> So I think I can remove the comment for the the A5/C5 configuration.

OK, then this should be removed. A10 support should then be added in a
separate patch please.

> This situation will come into play for the Arria10 SoCFPGA, because that
> part will have a NiOS cpu that will do the DDR configuration.
> "configuration time" happens at power-up

So "configuration time" happens if the FPGA loads itself from EPCQ or
does it happen also if the FPGA is not loaded at all ?

> and "reset" is a warm reset.
> From what I was told, the situation where we might want to preserve a
> variable after a reset is to avoid reconfiguring the NiOS in the FPGA
> for DDR operations.

Can't you synthesize a sticky register for this purpose in the FPGA instead?
Or is it that this NIOS2 which configures the DRAM is actually a hardware,
not a softcore ?

> > Also, what are "external modules"?
> 
> I think these could be different FPGA instances that needs these
> variables that have survived a warm reset to the CPU.

I _think_ I understand most of the above, but I kinda wonder why don't you
cook a small IP block on the avalon bus in the FPGA which would contain a
sticky register to hold all those configuration sticky bits. That'd look
much more sensible to me.

Best regards,
Marek Vasut

  reply	other threads:[~2015-05-28 18:18 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-18 19:36 [U-Boot] [PATCHv3 0/3] drivers/ddr/altera: Add the DDR controller driver for SoCFPGA dinguyen at opensource.altera.com
2015-05-18 19:36 ` [U-Boot] [PATCHv3 1/3] driver/ddr/altera: Add DDR driver for Altera's SDRAM controller dinguyen at opensource.altera.com
2015-05-21 23:33   ` Marek Vasut
2015-05-18 19:36 ` [U-Boot] [PATCHv3 2/3] driver/ddr/altera/: Add the sdram calibration portion dinguyen at opensource.altera.com
2015-05-21 23:35   ` Marek Vasut
2015-05-22  2:43     ` Dinh Nguyen
2015-05-22  6:39       ` Stefan Roese
2015-05-22 10:36         ` Marek Vasut
2015-05-25 12:37   ` Pavel Machek
2015-05-25 13:23     ` Wolfgang Denk
2015-05-28 15:41       ` Dinh Nguyen
2015-05-28 18:18         ` Marek Vasut [this message]
2015-05-29 15:24           ` Dinh Nguyen
2015-06-01 13:17             ` Marek Vasut
2015-05-28 15:49       ` Dinh Nguyen
2015-05-18 19:36 ` [U-Boot] [PATCHv3 3/3] arm: socfpga: enable the Altera SDRAM controller driver dinguyen at opensource.altera.com
2015-05-21 23:35   ` Marek Vasut

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=201505282018.32492.marex@denx.de \
    --to=marex@denx.de \
    --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