i.MX8MP SPL failures due to memory corruption/overflow?
Frieder Schrempf
frieder.schrempf at kontron.de
Wed Mar 15 15:12:48 CET 2023
Hi,
I'm trying to bring up a new board based on the i.MX8MP and I have an
issue I'm hoping someone can help solving.
I'm seeing failures in the early SPL code, usually in the DDR
initialization. Often they look like:
U-Boot SPL 2023.04-rc3 (Mar 07 2023 - 14:32:34 +0000)
Training FAILED
Failed to initialize DDR RAM!
### ERROR ### Please RESET the board ###
But sometimes ddr_init() doesn't even return an error and only the
get_ram_size() afterwards which tries to allocate the memory fails.
The strange thing is that the issues appear or disappear
deterministically on the binary level. This means I sometimes get a
U-Boot binary which runs just fine in 100% of cases. Then I change for
example one of the following:
* Adding a single printf() somewhere in the boards spl.c
* Using the same binary but booting from SD card instead of USB loader
* Using the same source but switching from the OS cross compiler to the
one from Yocto/OE
And afterwards I get 100% failure rate with an error as described above.
My suspicion is that there is some memory corruption/conflict. My SPL is
quite large and I wonder if it exceeds some limit.
SPL is loaded to 0x920000 and CONFIG_SPL_STACK is set to 0x960000, which
leaves 256 KiB in between for the SPL. But all i.MX8MP boards seem to
set CONFIG_SPL_MAX_SIZE=0x26000 (152 KiB) for some reason. My
u-boot-spl-ddr.bin currently has around 193 KiB but I don't get any
warning about exceeding the SPL_MAX_SIZE.
My questions:
* Why is CONFIG_SPL_MAX_SIZE set to 152 KiB?
* Why is there no warning in my case?
* Any other ideas or pointers?
Thanks for your help!
Best regards
Frieder
More information about the U-Boot
mailing list