All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.