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

I've been able to get some more information on this comment. As it turns
out, this comment is only applicable to configurations where the DDR
calibration/configuration is being done by the FGPA(NiOS processor). So
for Cyclone5/Arria5, this comment is not applicable and can be removed.

"configuration time" in this comment refers to a power-up, and "reset"
refers to a warm reset of the SoC, which may or may not involve
reconfiguration of the FPGA(NiOS processor). This situation will come
into play for the Arria10 platform, as it will have a NiOS processor
that will do the DDR configuration/calibration. The reason why we may
want to preserve variables from a warm reset is that we might not want
to go through the FPGA configuration procedure on a warm reset.

I hope this explains this comment a bit further.

Thanks,
Dinh