2387299_en-US

[#1]

IMX-8M-MINI DDR Controller timings for Winbond W664GG6RB-06

Hello,

We are looking for an explanation for a non-working DDR4 timing set. In short, the
timings generated by the DDR Tool passed calibration and stress tests, but led to
sporadic Linux kernel crashes during boot, with an "undefined instruction" error.

Setup (raw facts):
- The SoC is an i.MX8M Mini Solo (single Cortex-A53), DDR4 (Winbond W664GG6RB-06) at
1200 MHz (DDR4-2400) in 1:2 DFI (DDR PHY Interface) frequency-ratio mode, with a
single x16 4 Gb device (512 MB, no ECC).
- The BSP is NXP L4.14.98_2.0.0 (Linux 4.14.98, U-Boot 2018.03); the DDR config was
generated with MSCALE DDR Tool v3.31 (Windows version) and PHY training firmware
v201709. The same firmware is used in Yocto to build the U-Boot image.
- We are qualifying one common timing set for three interchangeable 4 Gb x16 DDR4
parts (Alliance AS4C256M16D4, ISSI IS43QR16256B, Winbond W664GG6RB-06), all operated
at 1200 MHz.
- To meet the slowest part's (Winbond) tRCD/tRP/tAA (~14.16 ns at the 2400 bin) we
set CL=17 (17-17-17), which the Tool encodes as MR0 = 0x0864 with the matching
CL-derived registers (e.g. DFITMG0 = 0x038C8207, DRAMTMG2 = 0x0609050D).
- The DRAM runs static at the 2400 setpoint (DVFS/busfreq disabled in the device
tree), so there is no frequency scaling by Linux at runtime.

Observations:
- The 17-17-17 config passes the DDR Tool stress test (~24 h) and U-Boot mtest (~1 h)
with no errors.
- Under Linux (on boots that reach the shell prompt) it also passes stressapptest +
fio (crc32c-verified), continuously and even at Tj = 84 °C, for over an hour with
zero data errors.
- Nevertheless, Linux sporadically crashes during boot with "Internal error:
undefined instruction" (corrupted kernel .text), ~1.1 s into the kernel, on roughly
5–7 % of cold boots (measured with an automated cold power-cycle loop).
- The failure is die-independent: the CL=17 image crashes the same way on a second of
these parts (ISSI), while the CL=16 image boots Linux reliably on that same ISSI
part.
- Both even-CL configs boot Linux reliably: 16-16-16 (our long-standing production
timing) and a newly built 18-18-18 (no kernel crashes observed) — only the odd-CL
17-17-17 fails.
- Only the CL-derived registers differ between the failing and working configs (MR0
CAS bits, DFITMG0 dfi_t_rddata_en, DRAMTMG2 read latency / rd2wr, DFITMG2 rdcslat,
ODTCFG rd_odt_delay).

Hypothesis:
We suspect odd CAS latency at the 1:2 DFI ratio is the root cause: the read-data
return latency is CL/2 in DFI clocks — a non-integer 8.5 for CL=17 versus integer 8.0
/ 9.0 for CL=16 / 18. Since the read FIFO (written by DQS, read by the controller
clock, Reference Manual §9.3.2.2.2) handles the steady state and steady stress
passes, we suspect the marginality surfaces at read burst-to-burst transitions, where
odd CL's half-DFI-clock offset would hit a first/last-beat edge case the RM does not
document.

Questions:
Is odd CAS latency (e.g. CL=17) supported on the i.MX8M Mini DDR4 PHY in 1:2 DFI
mode, or are there known constraints/errata for odd CL? In particular — can the DDR
Tool produce an odd-CL configuration that passes its own stress test yet is marginal
under real boot traffic, and is there a recommended way to constrain read
burst-to-burst timing for odd CL?

Attached: kernel crash console dump, the CL=17 .ds script for the DDR Tool, and the
produced ddr4_timing.c.

Any advice will be appreciated.

Re: IMX-8M-MINI DDR Controller timings for Winbond W664GG6RB-06

Sorry, somehow attachments didn't attach. Here are they.