[U-Boot] [RFC PATCH 00/12] imx: mx6: add virtual mx6memcal board

[Tim Harvey]

On Fri, Aug 26, 2016 at 8:33 AM, Eric Nelson <eric at nelint.com> wrote:
> Hi Tim,
>
<snip>
> It's been lingering due to un-related client demands.
>
> I was also hoping to get some feedback from Fabio and Peng regarding
> placement in the board/freescale tree and get some additional hardware
> to test against before V2.
>
> I now have the hardware, but haven't put any cycles into it.
>
> In particular, I now have a WaRP (i.MX6SL), mx6ulevk, and mx7dsabresd
> to test against, though the i.MX7 may require some code movement.

and I have quite a variety of IMX6 base boards to test against with
16bit, 32bit, 64bit memory layouts on both IMX6DL and IMX6Q.

>
>> I love the idea of providing an easier way of obtaining calibration
>> values and removing the dependence on the Freescale tool. This SPL
>> would use the auto-calibration features that Marek added to obtain the
>> calibration instead of the 'brute force' method used by the Freescale
>> tool - which I think is likely an improvement as well. I would love to
>> see this re-submitted with Marek's suggestions and perhaps the
>> addition of a stress test as well that could iterate over memtest
>> loops (could be added later but I think I recall you saying you may
>> have ported some of the memory tests from Freescale's tool to u-boot
>> already).
>>
>
> I'm glad to hear an ack of the premise. I have found the tool
> (virtual memory test board) useful for gathering calibration data
> on a handful of new board designs.
>
> I haven't implemented a stress test, but think that could easily
> follow.
>
> I think the V1 patch set also didn't define a "full" U-Boot (only
> SPL is buildable). Expanding that should allow U-Boot's mtest,
> but my experience has been that it rarely exposes issues.

I would rather see something in the SPL that ran out of IRAM.

>
> The frequency-changing routines in the DDR stress tool and especially
> memory tests under a heavily loaded Linux have proven to be much
> better at detecting issues.

really? I've never bothered with testing at frequencies other than
what gets typically configured per the CPU.

What do you use under Linux that you like? I always prefer the memory
to be tested at a very low level with cache disabled.

>
>> Regarding Marek's imx6 auto-calibration features: I did run a test
>> across a range of boards in a thermal chamber using nothing but
>> auto-calibration and found many failures, but I need to go back and
>> spend more time with that. I believe my failing there was that I the
>> same thing you did in '03/12 imx: mx6: ddr: make calibration optional
>> in config routines' and made passing in a null calib structure skip
>> writing to the various registers completely and I'm thinking that if
>> the power on default values of these registers are so off for your
>> system that you can hang just trying to talk to the DDR in general. If
>> I recall the boot failures I saw when testing this were all hangs in
>> mx6_ddr3_cfg() before I even got to running
>> mmdc_do_write_level_calibration() or mmdc_do_dqs_calibration(). I was
>> also using an older u-boot fork that I rebased Marek's patches on top
>> of, so its possible I was missing some relevant fix-ups in
>> mx6_ddr3_cfg.
>>
>
> It's hard to comment about what may be going on there.
>
> I seem to recall having some issues if RALAT and/or WALAT are out of
> whack, but I don't think these should be affected by temperature.

I'll hopefully start running some tests next week and won't think too
hard about it unless I can show the same failures under the current
mainline code.

Tim