Simon, Thanks for checking this.
2015-04-08 12:25 GMT+09:00 Simon Glass <s...@chromium.org>: > Hi Masahiro, > > On 7 April 2015 at 06:06, Masahiro Yamada <yamada.masah...@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.masah...@socionext.com> >> Date: Thu Mar 19 19:42:55 2015 +0900 >> >> malloc_f: enable SYS_MALLOC_F by default if DM is on >> >> >> >> Uh, 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. -- Best Regards Masahiro Yamada _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
