[U-Boot] [PATCHv3 2/3] driver/ddr/altera/: Add the sdram calibration portion

[Dinh Nguyen]

On 05/25/2015 08:23 AM, Wolfgang Denk wrote:
> Dear Pavel,
> 
> In message <20150525123750.GD9943 at 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.

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.

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, 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.

> 
> 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.

Dinh