On Fri, 2014-07-25 at 04:41 +0300, Siarhei Siamashka wrote: > On Mon, 21 Jul 2014 19:51:50 +0100 > Ian Campbell <[email protected]> wrote: > > > On Fri, 2014-07-18 at 19:22 +0300, Siarhei Siamashka wrote: > > > Before driving the CKE pin (Clock Enable) high, the DDR3 spec requires > > > to wait for additional 500 us after the RESET pin is de-asserted. > > > > > > The DRAM controller takes care of this delay by itself, using a > > > configurable counter in the SDR_IDCR register. This works in the same > > > way on sun4i/sun5i/sun7i hardware (even the default register value > > > 0x00c80064 is identical). Except that the counter is ticking a bit > > > slower on sun7i (3 DRAM clock cycles instead of 2), resulting in > > > longer actual delays for the same settings. > > > > > > This patch keeps the old code and only removes the CONFIG_SUN7I ifdef. > > > But maybe we should drop all of this and just add 'udelay(500)' after > > > the DDR3 reset without bothering to play with these undocumented > > > registers. > > > > I'm happy to go with whichever you think is better. > > If the total DRAM initialization time in u-boot is not really critical > (all the delays are only fractions of millisecond), then I would > probably go with the "cargo cult" approach and actually apply the > delays in both places ('udelay(500)' after the DDR3 reset and keep > the maximum delay in the SDR_IDCR register too).
Makes sense to me. If someone later decides they really care about boot time to this degree then they can implement the SDR_IDCR thing, hopefully with the aid of a logic analyser, as you say. Ian. _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
