lpddr4 training code generation

[AlexyTarasov]

Our company is developing several computational modules which are based on pairs imx8mp + lpddr4(AS4C256M32MD4-062BAN 1 chip) and imx8m + lpddr4(MT53E512M32D2NP-046 WT:E 1 chip). Currently our primary goal is to prepare DDR memory trainings for each of modules. In accordance with this https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX-8M-Family-DDR-Tool-Release/ta-p/110... information we prepared two excel files: IMX8MP_AS4C256M32MD4-062BAN and IMX8M_MT53E512M32D2NP-046WTE. We got DDR stress test files from each of the excel files. Using mscale_ddr_tool _v3.30 imx8mp_lpddr4_timing.c and imx8m_lpddr4_timing.c were created. After that these files were placed inside u-boot source tree (sources repository https://source.codeaurora.org/external/imx/uboot-imx.git branch lf_v2020.04) and compiled. During boot process we got the following message and cpu goes into cyclic reboot.

U-Boot SPL
pmic_alloc: new pmic struct: 0x184000
pmic_get: pmic PCA9450 -> 0x184000
Bus: 0 PMIC:PCA9450 probed!
Can't find PMIC:PCA9450
DDRINFO: start DRAM init
DDRINFO: cfg clk
DDRINFO: DRAM rate 3200MTS
DDRINFO: ddrc config start
DDRINFO: ddrc config done
DDRINFO:ddrphy config start
DRAM PHY training for 3200MTS
check ddr_pmu_train_imem code
check ddr_pmu_train_imem code pass
check ddr4_pmu_train_dmem code
check ddr_pmu_train_dmem code pass
PMU String index = 0x00b00001
arg[0] = 0x00001000
PMU String index = 0x00a70001
arg[0] = 0x00000000
Training PASS

This message and behaviour are the same for both SoC.

In result of some research a cause of cyclic rebooting was found. To our surprise the cause is in register addresses that are placed in an array struct dram_cfg_param ddr_phy_pie[]. The ddr_phy_pie array is in generated by the mscale_ddr_tool _v3.30 files xxx_lpddr4_timing.c. If to be more concrete a problem of SoC's rebooting is in pairs of values :
{ 0x31000005, 0x1 },
{ 0x314bff50, 0x0 },
{ 0x31000005, 0x3a },
{ 0x315500c0, 0x1 },
{ 0x31000000, 0x3 },
{ 0xed5540a, 0x0 },
{ 0x31552448, 0x154003a },
{ 0x3100002e, 0x1 },
{ 0x315522f0, 0x0 },
{ 0x31404000, 0x0 },
{ 0x31550030, 0x3a00003a },
{ 0x31000005, 0x17 },
{ 0x310e8000, 0x6d0000 },
{ 0x31000017, 0x1540270 },
{ 0x31000005, 0x1540270 },
{ 0x31404000, 0x17 },
{ 0x31000000, 0x12ffcfc },
{ 0xed55773, 0x12ffe60 },
{ 0xed62b48, 0xf711acbd },
{ 0x30ffffff, 0x12ffd4c },
{ 0xed65e3f, 0x0 }

Reboot occurs in function dwc_ddrphy_apb_wr (drivers/ddr/imx/imx8m/ddrphy_train.c) at the moment of memory access by transformed register address (the first value in paris). The transformation is 0x3c000000 + 4 * reg_addr. Taking into account values of register addresses provided above the transformed addresses aren't in SoC address space. As a result CPU tries to access unavailable memory and gets error and reboots.

Ultimately we have not working ddr memory training subsystem.

Also we are interested in to create (and of course to have strong knowledge how to do it) ddr memory training configuration files like those that are for imx8mq_evk, imx8mp_evk and so on boards. The utility mscale_ddr_tool _v3.30 creates training configurations just for single clock frequency and single dimension (FW_1D_IMAGE). But mention above configurations for EVK boards have much more rich parameters

[AlexyTarasov]

I have to think so. All this code is automatically generated by mscale_ddr_tool _v3.30

[torus1000]

We are facing exactly same cyclic reboot issue too. Is it a code generator bug?