From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dinh Nguyen Date: Fri, 29 May 2015 10:24:19 -0500 Subject: [U-Boot] [PATCHv3 2/3] driver/ddr/altera/: Add the sdram calibration portion In-Reply-To: <201505282018.32492.marex@denx.de> References: <1431977809-23652-1-git-send-email-dinguyen@opensource.altera.com> <20150525132358.216463811E9@gemini.denx.de> <55673726.9030600@opensource.altera.com> <201505282018.32492.marex@denx.de> Message-ID: <556884A3.3080408@opensource.altera.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 05/28/2015 01:18 PM, Marek Vasut wrote: > 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 :-/ That's fine. I'll send a v4 with further clean ups. > >> 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 ? I think configuration time is only applicable when FPGA is programmed. > >> 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 ? > On the Arria10, the NIOS2 is a hardened block and 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. > That does sound like a great idea. I think some of our customers are probably doing that already that. Dinh