Hi,
On 04/08/2015 07:14 AM, Masahiro Yamada wrote:
Simon,
Thanks for checking this.
2015-04-08 12:25 GMT+09:00 Simon Glass sjg@chromium.org:
Hi Masahiro,
On 7 April 2015 at 06:06, Masahiro Yamada yamada.masahiro@socionext.com wrote:
Hi Michal, (cc Simon)
Bad new.
My Zedboard would not boot from MMC card with the U-Boot mainline.
U-Boot hangs after printing "reading system.dtb". I think, other zynq board types, too.
I did git-bisect and the first bad commit is:
commit 326a682358c16afcf2c7a9617e9811e72a1f0929 Author: Masahiro Yamada yamada.masahiro@socionext.com Date: Thu Mar 19 19:42:55 2015 +0900
malloc_f: enable SYS_MALLOC_F by default if DM is onUh, sorry. My commit.
The commit 36a6823 enables CONFIG_SYS_MALLOC_F=y CONFIG_SYS_MALLOC_F_LEN=0x400 to the .config file.
I suspect it changed how Zynq initializes malloc area in SPL. I have not figured out how to fix it.
Any hint is appreciated.
My guess is that CONFIG_SYS_SPL_MALLOC_START is defined, and they conflict.
See common/spl/spl.c, board_init_r() where it decides which malloc() stack to init.
The problem could be in dlmalloc.c:
#ifdef CONFIG_SYS_MALLOC_F_LEN if (gd && !(gd->flags & GD_FLG_FULL_MALLOC_INIT)) return malloc_simple(bytes); #endif
But since the simple malloc() is not inited, this breaks.
But, the GD_FLG_FULL_MALLOC_INIT flag has already been set by board_init_r().
Dlmalloc should never fall back into malloc_simpile(), I think.
Is there enough space for malloc? just print address which you want to use to make sure that all addresses are right.
Thanks, Michal