On 08/08/14 10:19, Tim Harvey wrote:
On Wed, Aug 6, 2014 at 10:29 AM, Nikita Kiryanov nikita@compulab.co.il wrote:
On 04/08/14 16:36, Nikita Kiryanov wrote:
On 04/08/14 07:45, Tim Harvey wrote:
On Sun, Aug 3, 2014 at 12:34 AM, Nikita Kiryanov nikita@compulab.co.il wrote:
Add initial support for Compulab CM-FX6 CoM. Support includes MMC, SPI flash, and SPL with dynamic DRAM detection.
<snip> > > + > +static void spl_mx6s_dram_init(enum ddr_config dram_config, int reset) > +{ > + struct mx6_mmdc_calibration calib; > + struct mx6_ddr_sysinfo sysinfo; > + struct mx6_ddr3_cfg ddr3_cfg; > + > + if (reset) > + ((struct mmdc_p_regs *)MX6_MMDC_P0_MDCTL)->mdmisc = 2; > + > + calib.p0_mpwldectrl0 = 0x005B0061; > + calib.p0_mpwldectrl1 = 0x004F0055; > + calib.p0_mpdgctrl0 = 0x0314030C; > + calib.p0_mpdgctrl1 = 0x025C0268; > + calib.p0_mprddlctl = 0x42464646; > + calib.p0_mpwrdlctl = 0x36322C34; > + ddr3_cfg.mem_speed = 800; > + ddr3_cfg.density = 4; > + ddr3_cfg.rowaddr = 14; > + ddr3_cfg.coladdr = 10; > + ddr3_cfg.pagesz = 2; > + ddr3_cfg.trcd = 1800; > + ddr3_cfg.trcmin = 5200; > + ddr3_cfg.trasmin = 3600; > + ddr3_cfg.SRT = 0; > + sysinfo.cs1_mirror = 1; > + sysinfo.cs_density = 16; > + sysinfo.bi_on = 1; > + sysinfo.rtt_nom = 1; > + sysinfo.rtt_wr = 0; > + sysinfo.ralat = 5; > + sysinfo.walat = 1; > + sysinfo.mif3_mode = 3; > + sysinfo.rst_to_cke = 0x23; > + sysinfo.sde_to_rst = 0x10; > + switch (dram_config) { > + case DDR_16BIT_256MB: > + sysinfo.dsize = 0; > + sysinfo.ncs = 1; > + break; > + case DDR_32BIT_512MB: > + sysinfo.dsize = 1; > + sysinfo.ncs = 1; > + break; > + case DDR_32BIT_1GB: > + sysinfo.dsize = 1; > + sysinfo.ncs = 2; > + break; > + default: > + puts("Tried to setup invalid DDR configuration\n"); > + hang(); > + } > + > + mx6_dram_cfg(&sysinfo, &calib, &ddr3_cfg); > + udelay(100); > +}
Nikita,
I'm curious why you add an extra udelay(100) here? There is an mdelay(1) before the return of mx6_dram_cfg() to wait for auto-ZQ calibration to complete (I never found a way to determine when it was complete via registers).
Yes you're right. This udelay can probably be removed (unless I catch the board misbehaving during multiple resets).
Caught the DRAM config failing during multiple resets when udelay(100) is removed, so I guess they stay..
Nikita,
What exactly was failing? Was the subsequent to get_ram_size() failing?
Yes.
If the extra delay is really needed we should add it to the mx6_dram_cfg() function. The issue I ran into before I added the mdelay(1) there to wait for auto-ZQ calib to complete was that SDRAM operations immediately following the call to mx6_dram_cfg() would be un-reliable, specifically a memset to 0 would fail to clear memory where GD was which caused some interesting failures down the line.
In my case the failures appeared after the board had been operational long enough for the soc to heat up. I'm curious to hear what kind of temperatures you tested your board under. If a warm temperature that is within reasonable limits can cause failures on your board as well, that would be a clear indication that the 1 msec delay is a borderline value and needs to be increased.
Maybe I'll open up an issue with Freescale and ask them if there is a way to know when auto-ZQ calibration is complete because it isn't clear to me how to do that. The 1ms delay was because the 0 value we set to MPZQHWCTRL ZQ_HW_PER configures it for a 1ms ZQ calibration cycle.... maybe we simply need a little more headroom.
Maybe. If a Freescale representative can provide an analytical reason like the one you're proposing, that would be great. The question is what to do if a good explanation is not given. We can simply increase the mdelay tentatively in mx6_dram_cfg(), or we can keep the udelay() for cm_fx6 and wait to see if someone else complains. I'm fine with both options.
Tim