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

[Eric Nelson]

Hi Tim,

On 08/26/2016 08:00 AM, Tim Harvey wrote:
> 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.
>>

Fabio and Peng, do you have any comments?

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

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

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.

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

Regards,


Eric