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 ...
In general, it is still ok to use the older mScale DDR Tool, however, it is preferred to use the latest Config Tools, mainly given the larger set of features that it offers. As for the issue with the calibration failing in SPL for 668 MT/s, I believe that this is due to the fact that this data rate is not in all the branches supported by default in U-Boot PLL config and it needs to be added by the customer as an additional option.
Also watch for the common discrepancy 667 vs 668 MT/s as the numbers in the timing file need to match with the case options in the PLL config. https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/iMX-8M-Mini-Register-Programming-Aid-DRA...
If you can't access this document, please contact me directly.
Regards,
Bernhard.
@WILLEMSS , can you give it a try with another second set point? 533 MHz instead of 668 MHz.
Note: The disadvantage of the mScale Test Tool is, that it's no longer updated. This means that in the latest version 3.31 there are old training files, I don't know yet whether they are still seen as valid training when it comes to dynamic frequency scaling.
Regards,
Bernhard.
Hi @bernhardfink,
I just retry the memory training with Mscale tool as you suggested with 533 MHz as second set point (Excel sheet attached).
The Mscale tool could train without any error (tool log file attached).
Unfortunately, I have the same result as for 668MHz. The u-boot training fails at the second set point.
Then someone from the software team needs to look into the u-boot code, whether the correct PLL config for a 668 MHz or 533 MHz is implemented.
Regards,
Bernhard.
Is it maybe related to the voltage settings at the time the DDR4 training takes place?
Did you apply the same values in both situations? Or in other words: can you be sure that the voltages are the same?
Regards,
Bernhard.
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, 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 @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 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,