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

[Marek Vasut]

On Friday, May 29, 2015 at 05:24:19 PM, Dinh Nguyen wrote:
[...]
> >>> 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.

OK

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

So this is a timeframe between "FPGA has been programmed (from EPCQ or 
whatever)" and "before HPS is released out of reset" ?

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

I think this is indeed a good idea.

btw. I cooked yocto 1.8 (master) support for generating NIOS2 toolchain.
I might as well work on it some more, but only once I'm back from LCJ.

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

So uh, why aren't we doing it here ? Maybe because the sticky registers
are not in the "hardware" the same way the NIOS2 core is ?