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 <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.
Is there enough space for malloc? just print address which you want to use to make sure that all addresses are right. Thanks, Michal _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot