[U-Boot] Zynq board is boken

[Michal Simek]

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 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.

Is there enough space for malloc? just print address which you want to
use to make sure that all addresses are right.

Thanks,
Michal