@ixtab, well, you're a pioneer, and I now know less than you (in empirical sense), but I can't stand the feeling that U-Boot actions are definitely messing the whole thing. Well, it could just reconfigure DDR clock (with other peripheral clocks, in bunch) in some internal initialization procedure and voila! all data will be lost.
But, again, this is not a confidence or supposition and not even wild guessing (I don't know U-Boot internals at all and don't know whether reconfiguring of DRAM clock is really done and/or will it really erase data). Just feeling.
BTW,
I could've been wrong at pointing to DDR initialization code and it's calling point. There is following chunk of code in
board/imx50_yoshi/flash_header.S :
Code:
#ifndef CONFIG_IRAM_BOOT
#if defined(CONFIG_LPDDR2)
bl lpddr2_init
#elif defined(CONFIG_MDDR)
bl mddr_init
#endif
#endif
Well, but at
include/configs/imx50_yoshi.h there is
#define CONFIG_IRAM_BOOT 1, so that chunk of code will not be compiled in case of simple (non-bist) U-Boot.
Then, there is
Code:
{
.id = "005",
.name = "Whitney",
.mem_type = MEMORY_TYPE_MDDR,
.mem_size = (256 * 1024 * 1024),
},
at
include/asm-arm/arch-mx50/mx50_yoshi_board.h. And KT's internal name
is Whitney.
So, it's needed to look after label
mddr_init: in
board/imx50_yoshi/ram_init.S (but not after lpddr2_init: ).
At last, I didn't found relevant
CONFIG_MDDR or
CONFIG_LPDDR2 defines in yoshi board configs. But at
lib_arm/board.c there is mention of
dram_init in
init_sequence structure. And there is function
dram_init at
board/imx50_yoshi/imx50_yoshi.c, where
MEMORY_TYPE_MDDR define is used (dram_init just calls mddr_init or lpddr2_init).