i.MX8MM DDR firmware padding

[felixradensky]

Hello,

We are trying to support 2 i.MX8MM boards using the same u-boot binary. One board has LPDDR4 RAM while another one has DDR4 RAM. We were able to integrate both LPDDR4 and DDR4 firmware binaries into SPL image and modify SPL and DDR driver code to select relevant firmware and timing tables depending on the board type. To fit into 256KB TMU we had to disable some non-essential SPL features. In our image DDR4 firmware comes after LPDDR4 firmware. We were able to successfully boot DDR4 board, but noticed that if SPL size changes, the loading of DDR4 firmware may fail on the following exception:

DRAM PHY training for 2400MTS
check ddr4_pmu_train_imem code
check ddr4_pmu_train_imem code pass
check ddr4_pmu_train_dmem code
check ddr4_pmu_train_dmem code pass
DRAM PHY training for 400MTS
check ddr4_pmu_train_imem code
check ddr4_pmu_train_imem code pass
check ddr4_pmu_train_dmem code
check ddr4_pmu_train_dmem code pass
DRAM PHY training for 100MTS
check ddr4_pmu_train_imem code
check ddr4_pmu_train_imem code pass
check ddr4_pmu_train_dmem code
check ddr4_pmu_train_dmem code pass
DRAM PHY training for 2400MTS
"Synchronous Abort" handler, esr 0x96000210
elr: 00000000007eb7a0 lr : 00000000007ebd5c
x0 : 000000003c152000 x1 : 0000000000000000
x2 : 0000000000820000 x3 : 000000003c158000
x4 : 0000000000000000 x5 : 0000000000000041
x6 : 0000000014040000 x7 : 0000000023c34600
x8 : 0000000000000006 x9 : 0000000000000002
x10: 00000000ffffffd0 x11: 0000000000000006
x12: 000000000001869f x13: 0000000000000016
x14: 000000000090e558 x15: 00000000ffffffff
x16: 0000000000000000 x17: 00000000000000ff
x18: 000000000091de40 x19: 00000000007ef860
x20: 000000000081f000 x21: 000000003c340264
x22: 0000000000817000 x23: 000000000f000000
x24: 0000000000000001 x25: 0000000000000003
x26: 000000003c340000 x27: 0000000072000000
x28: 0000000000000000 x29: 000000000091dd20

The question is whether any special padding of SPL and LPDDR4 firmware is required in addition to padding that is already done by the image generation makefile.

Thanks.

Felix.

[felixradensky]

Hello,

Answering my own question, the reason for the crash is the behavior of i.mx8m DDR driver.

The driver assumes that the size of the last firmware image (ddr4_dmem_2d.bin or lpddr4_pmu_train_2d_dmem.bin) is 16K and accesses the memory beyond 256K of TMU, causing the exception. We were able to modify the driver and avoid the crash.

Looking at the sizes of LPDDR4 firmware,

-rw-r--r-- 1 felix felix  1668 Oct 15 09:50 lpddr4_pmu_train_1d_dmem.bin
-rw-r--r-- 1 felix felix 32244 Oct 15 09:50 lpddr4_pmu_train_1d_imem.bin
-rw-r--r-- 1 felix felix  1380 Oct 15 09:50 lpddr4_pmu_train_2d_dmem.bin
-rw-r--r-- 1 felix felix 23232 Oct 15 09:50 lpddr4_pmu_train_2d_imem.bin

we can see that lpddr4_pmu_train_1d_dmem.bin and lpddr4_pmu_train_2d_dmem.bin are actually less than 2K.

The same is true for DDR4 firmware:

-rw-r--r-- 1 felix felix 16384 Nov  4 17:45 ddr4_dmem_1d.bin
-rw-r--r-- 1 felix felix  1436 Nov  4 17:45 ddr4_dmem_2d.bin
-rw-r--r-- 1 felix felix 32768 Nov  4 17:45 ddr4_imem_1d.bin
-rw-r--r-- 1 felix felix 23772 Nov  4 17:45 ddr4_imem_2d.bin

The ddr4_dmem_1d.bin is 16K but in fact it is zero-padded, with actual size being less than 2K.

The i.MX8M DDR driver assumes that the size of dmem firmware files is 16K, see helper.c\imx8m\ddr\drivers - uboot-imx - i.MX U-Boot 

The imx-mkimage Makefile ensures the padding of dmem files to 16K: soc.mak\iMX8M - imx-mkimage - i.MX Mkimage Bootloader Tool 

Looks like padding dmem files to 4K should be sufficient. This can avoid redundant copying of almost 100K of padding, since dmem files are copied to and from DDR PHY 4 times.

My question is: is it safe to assume that 4K padding of dmem files is sufficient ? My experiments show this to be true, but I'd be happy to get a confirmation from NXP DDR experts.

Felix.

[oliver_chen]

Hi fradensky‌,

Thank you for your trying and congratulations for your success.

Yes, 4K padding of DMEM is enough.

B.R

Oliver

[felixradensky]

Hi Oliver,

Thank you very much for a prompt reply, much appreciated.

Felix.