[U-Boot] [PATCH 12/18] arm: mx6: add support for Compulab cm-fx6 CoM

[Nikita Kiryanov]

On 08/08/14 10:19, Tim Harvey wrote:
> On Wed, Aug 6, 2014 at 10:29 AM, Nikita Kiryanov <nikita at 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 at 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
>