Hi Tim,
On 08/26/2016 08:00 AM, Tim Harvey wrote:
On Tue, Jun 21, 2016 at 11:41 AM, Eric Nelson eric@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