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

[Tim Harvey]

On Tue, Jun 21, 2016 at 11:41 AM, Eric Nelson <eric at nelint.com> wrote:
> This patch set makes use of the dynamic DDR calibration routines added in commit
> d339f16 to define an alternative to the Freescale DDR stress tester tool.
>
> The goals of this effort are to make the process of DDR validation easier
> and more robust:
>         - The use of SPL simplifies the process of running DDR calibration
>         through the imx_usb or SB_LOADER.exe tools (no need for JTAG)
>
>         - The use of Kconfig makes the set of board-specific parameters
>         more obvious.
>
>         - The output of the SPL image can be directly pasted into either the DCD
>         configuration file or U-Boot sources.
>
> The notable feature of the DDR stress tool which isn't present in this virtual
> board file is the testing across CPU frequencies.
>
> Patches 1-3 contain structural changes to those routines to return the
> calibration data and allow configuration of memory without a pre-defined
> set of calibration data.
>
> Patches 4 and 5 add a struct mx6_ddr_sysinfo parameter to the calibration
> routines and use it to fix the use of the calibration routines on CPU
> variants which don't have two MMDC ports (tested on i.MX6SL).
>
> Patches 6-7 simplify the selection of the DDR calibration routines and
> allow use on other CPU variants (again, tested on i.MX6SL).
>
> Patch 8 is the meat of the patch set and defines the board itself and
> a single configuration sample that can be used on mx6sabresd or mx6qsabreauto.
>
> Patches 9-12 define a set of other configurations to match other boards that
> I've tested during development. Note that the configurations with LPDDR (mx6slevk
> and WaRP) are not currently functional.
>
> I believe that patches 1-7 are minor and can be applied after a short
> review, but the patch set is an RFC because of some fundamental questions:
>
>         - Is it okay with Freescale that I'm the maintainer for a board
>         in the board/freescale tree? I don't particularly want to be the
>         maintainer of this set of tools, but I want them, so I will try
>         to maintain those portions that I'm in a position to test.
>
>         - What about the board name? Though I haven't looked deeply at it,
>         but I think that some of this code could be shared with i.MX7.
>
>         - I'm including some configurations for boards that don't currently
>         function (mx6slevk) or haven't been tested (warp) for reference and
>         further updates. I'm also including a configuration for a board that
>         isn't supported in main-line U-Boot (nitrogen6_max).
>

Eric,

I currently have the time and resources to run some large-scale tests
and prove out the reliability of auto-calibration.

It looks like you never got a whole lot of feedback on this series in
the general sense - probably because there are only a few of us who
need to deal with imx6 ddr calibration. Where do you stand with it?

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

Regarding Merak'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.

Regards,

Tim