On Fri, Aug 26, 2016 at 8:33 AM, Eric Nelson eric@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