Issue with imx8mp and embedding several DTBs in FIT image for SPL stuck in ddr training

[vik]

Hi, 

We are trying to have multiple device trees in SPL using evaluation kit board imx8mp-evk and uboot 2023.04.

To achieve this we enabled few u-boot configuration options: CONFIG_SPL_OF_CONTROL, CONFIG_SPL_MULTI_DTB_FIT and CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION.

And for start we are providing just one device tree in SPL list: CONFIG_SPL_OF_LIST="imx8mp-evk"

Reading specific value from EEPROM in board_fit_config_name_match() we set proper device tree.

Problem that we see now when we try to boot platform with multiple dtb fit image is that dram phy is hanging in SPL in DRAM phy training.

U-Boot SPL 2023.04-5.4.70-2.3.3 (Nov 26 2024 - 12:56:43 +0000)

DDRINFO: start DRAM init

DDRINFO: DRAM rate 4000MTS

Adding some printouts to SPL functions we found out that code is stuck in infinite loop in call:

ddr_cfg_phy()->wait_ddrphy_training_complete()->get_mail()->poll_pmu_message_ready()

Read registry function in poll_pmu_message_ready() is returning all the time 0x10 value. Can you tell us if this feature is supported imx8mp, and if it is we missing some configuration options?

We are building ixm-boot image in custom yocto environment there recipe for imx firmware is "firmware-imx-8m-mp_8.10.1.bb". We tried booting platform from sdcard and using uuu-tool and behavior is same.

Thank you,

Sinisa

[RickStievenart]

Greetings! I have the same issue! Did you ever find a REAL solution?

Thank you for you reply!

Rick Stievenart

rick.stievenart@johnsonoutdoors

Johnson Outdoors - Marine Electronics - Humminbird

[vik]

Hi Rick,

Unfortunately, I found more issues. The trouble with loading the DDR training firmware is that the firmware offset isn’t calculated properly when multiple DTBs are embedded into the SPL image. To move forward, I used a hardcoded offset calculated from a memory dump. However, the next issue appeared when the SPL had to start U-Boot and pass the device tree. The device tree is always taken from the imx-boot image that the imx-boot tool in the soc.mak scripts packs, not the one selected by the SPL in board_fit_config_name_match().

Best regards,

Sinisa Vik

[RickStievenart]

Thanks for your reply.

I am currently working with Pro Support on this issue.

Rick Stievenart

Johnson Outdoors, Inc. Marine Electronics-Humminbird

[AldoG]

Hello,

If you do not enable this feature does the board boot correctly?
Also, what do you mean by multiple device tree?
Could you share more information of what are you trying to achieve?

Best regards/Saludos,
Aldo.

[vik]

Hi Aldo,

Basically without these additional configuration options platform is booting correctly (it is default unchanged imx8mp_evk_defconfig).
We have custom board based on imx8mp processor and we want to support booting multiple variants of that platform with single bootloader image. Our idea is that SPL provides correct device tree to u-boot based on specific identifier from eeprom. We observe same behavior if we modify our bootloader configuration as for evk platform, SPL hang in ddr_cfg_phy().
As starting point we are tying to resolve this problem on NXP evaluation kit platform with clean u-boot source since it's not affected by our changes.

First we observe this hang when we packed multiple device tree into bootloader fit image:
CONFIG_SPL_OF_LIST="imx8mp-evk imx8mp-evk-2".
imx8mp-evk-2.dts was copy of imx8mp-evk.dts with modified model property node.
Alternative on the end was to enable this feature and specify just one device tree in CONFIG_SPL_OF_LIST.
If you need more detailed steps pleas let me know.

[AldoG · Accepted solution]

Hello,

Unfortunately I believe we may not have this feature enabled or ready by default, as I was checking on the documentation, I see that SPL uses board_fit_config_name_match() to find the correct DTB within the
FIT, as in our case this function is empty, as you can see here:
https://github.com/nxp-imx/uboot-imx/blob/lf_v2022.04/board/freescale/imx8mp_evk/spl.c#L140

This may be causing issues on the SPL, please note that this feature has not been tested on our side.

Best regards/Saludos,
Aldo.