[U-Boot] Zynq board is boken

[Masahiro Yamada]

Simon,

Thanks for checking this.

2015-04-08 12:25 GMT+09:00 Simon Glass <sjg at chromium.org>:
> Hi Masahiro,
>
> On 7 April 2015 at 06:06, Masahiro Yamada <yamada.masahiro at 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 at 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