We try to use training datas from Mscale DDR training tool for a 4 GiB DDR4 RAM variant but training in SPL fails.
The training, stress test and code generation was successful with Mscale tool at 1200MHz and 668MHz.
SPL training fails with the generated datas.
Debug prints:
DDRINFO: start DRAM init
DDRINFO: cfg clk
DDRINFO: DRAM rate 2400MTS
DDRINFO: ddrc config start
DDRINFO: ddrc config done
DDRINFO:ddrphy config start
DRAM PHY training for 2400MTS
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 Major message = 0x00000000]
[PMU Major message = 0x00000002]
[PMU Major message = 0x00000001]
[PMU Major message = 0x0000000a]
[PMU Major message = 0x000000fd]
[PMU Major message = 0x000000fe]
[PMU Major message = 0x00000004]
[PMU Major message = 0x00000003]
[PMU Major message = 0x00000009]
[PMU Major message = 0x00000007]
Training PASS
DRAM PHY training for 1336MTS
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 Major message = 0x00000000]
[PMU Major message = 0x00000002]
[PMU Major message = 0x00000001]
[PMU Major message = 0x000000fd]
[PMU Major message = 0x000000fe]
[PMU Major message = 0x00000008]
PMU String index = 0x00210002
arg[0] = 0x00000000
arg[1] = 0x00000051
[PMU Major message = 0x00000008]
PMU String index = 0x04020000
[PMU Major message = 0x000000ff]
Training FAILED
Error: failed to initialize DRAM, reset system!
resetting ...
Hello,
Which modifications were done in your custom design?
How did you flash the device? (command, tool, etc)
Best regards.
Hello,
We only change the DDR4 RAM regarding our other SOM.
We use 2 Micron MT40A1G16TB-062E (Datasheet attached).
We flash the boot container to a SD Card with dd at the correct offset and also with a complete image with bmaptool.
Regards,
Hello,
Could you please try to flash it using UUU?
Best regards.
I couldn't boot better.
DDRINFO: start DRAM init
DDRINFO: DRAM rate 2400MTS
Training FAILED
Error: failed to initialize DRAM, reset system!
Hello, thank you for the update.
Could you please re-try with Config Tools for i.MX?
Just to confirm, you are following the steps in DDR tool to implement DDR initialization scripts to build U-boot, right?
Best regards.
Hello @JorgeCas ,
I retry with the datas coming from i.MX Configuration tool v16.1 but I had no better chance.
I notice that the .ds file (attached) are different for DRAM_PLL_FDIV_CTL0 register with the same DDR configuration.
I follow this procedure:
Regards,
Hello,
Could you please share me the U-boot and Linux versions you are using?
Maybe an incompatibility issue between versions.
Also, how are you building U-boot/Linux?
Best regards.
Hi @JorgeCas,
We are using NXP's u-boot-imx v2024.04 and linux-imx 6.6.23.
I build u-boot thru devtool and bitbake.
Kindest regards,
Hello,
Thank you for the information. Could you please share the steps you followed to build it?
Best regards.
Hello @JorgeCas ,
To build u-boot-imx, we integrate the source file into my source tree as we integrate it our other BSP's. We invoke the command "devtool build u-boot-imx".
To build the container, we invoke the command "bitbake imx-boot" after a complete clean of the recipe.
To be completely honest, I don't think it is linked with a build issue but with a training and source code generation.
Kindest regards,
Hello,
The issue could be related to how are being integrated the changes in DDR initialization and timing files before build.
Please follow the steps in DDR tool manual. You also could try the next steps:
###### Host package setup ######
$ sudo apt install gawk wget git diffstat unzip texinfo gcc build-essential chrpath socat cpio python3 python3-pip python3-pexpect xz-utils debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa libsdl1.2-dev pylint3 xterm python3-subunit mesa-common-dev zstd liblz4-tool rsync curl
###### Execute script for SDK installation ######
$ chmod a+x fsl-imx-internal-xwayland-glibc-x86_64-test-internal-qt6-armv8a-imx8mpevk-toolchain-5.15-kirkstone.sh
##### To obtain the SDK (.sh file) you have to do it in Yocto with: #####
$ bitbake imx-image-core -c populate_sdk
###### Set environment for build ######
$ . /opt/fsl-imx-internal-xwayland/5.15-kirkstone/environment-setup-armv8a-poky-linux
$ export ARCH=arm64
###### Build Uboot ######
$ mkdir uboot_build
$ cd uboot_build
$ git clone https://github.com/nxp-imx/uboot-imx -b lf_v2022.04
$ cd uboot-imx
$ make clean
$ make imx8mm_evk_defconfig
$ make
###### Build ARM Trusted Firmware (ATF) ######
$ cd ..
$ git clone https://github.com/nxp-imx/imx-atf -b lf_v2.6
$ cd imx-atf/
$ make PLAT=imx8mm bl31
###### Download the DDR training bin ######
$ cd ..
$ mkdir firmware-imx
$ cd firmware-imx
$ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.16.bin
$ chmod a+x firmware-imx-8.16.bin
$ ./firmware-imx-8.16.bin
###### Download imx-mkimage and build the boot image ######
$ cd ~
$ git clone https://github.com/nxp-imx/imx-mkimage -b lf-5.15.32_2.0.0
$ cd imx-mkimage
###### Now you may copy all the files need for build boot image (flash.bin) ######
$ cp ../uboot-imx/spl/u-boot-spl.bin iMX8M/
$ cp ../uboot-imx/u-boot-nodtb.bin iMX8M/
$ cp ../uboot-imx/arch/arm/dts/imx8mm-evk.dtb iMX8M/
$ cp ../imx-atf/build/imx8mm/release/bl31.bin iMX8M/
$ cp ../firmware-imx/firmware-imx-8.16/firmware/ddr/synopsys/lpddr4_pmu_train_* iMX8M/
$ cp ../uboot-imx/tools/mkimage iMX8M/mkimage_uboot
$ make SOC=iMX8MM flash_evk
The boot image will be found at the path iMX8M with its default name flash.bin,
you may copy to an SD/eMMC using either DD command or UUU to try it.
If the issue persists, this could be caused by:
• Layout.
• RPA configuration.
Best regards.
Hi @JorgeCas,
I will need to adapt your procedure to Mickledore and as soon as I have my build environnement working try to re-build and let you know.
Kindest regards,
hi @JorgeCas,
I re-build out of tree the complete container, following your procedure.
Unfortunately, it will not end better.
Attached the complete log file on how I build the container.
Regards,
Hello,
Your RPA configuration is according to your DDR4 memory.
The next to check is layout signal integrity.
Did you perform a signal integrity simulation?
Best regards.
Hi @JorgeCas,
After several trial, we decided to remove the second frequency setpoint as it was failing into SPL training.
We still have one question.
The training was successful with frequencies of 800MHz and 668 MHz but fails on the second setpoint when configured with 1200MHz and 668 MHz.
Do you have any explanation?
Regards,
Hello,
This behavior aims to a signal integrity issues, since higher frequencies does not pass the training.
As mentioned before this could be caused by DDR layout.
Best regards.
Hi @JorgeCas,
As explained previously, the SPL training fails at the lower frequency and not at the highest with the 1200/668 MHz configuration.
From my experience, the training should fail as well if we use other DDR4 chips and with a signal integrity root cause.
To complete my explanation, we use on the same board (same layout) a 2 GiB configuration and the training pass for the 1200/668 MHz configuration.
Regards,
In case you need some additional information about this topic.
Here attached, the RPA excel sheet I used to train with mSCale tool and the tool log file.
Regards,