[U-Boot] Zynq board is boken

[Simon Glass]

+Tom since there is a patch pending

Hi Masahiro,

On 8 April 2015 at 02:09, Michal Simek <michal.simek at xilinx.com> wrote:
> 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().
>>

One problem is that in SPL it calls preloader_console_init() from
board_init_f() - it should be called later, in spl_board_init(). If
driver model is used for serial, then this call happens before driver
model is set up (in board_init_r()). See the README under 'Board
Initialisation Flow' for details.

This is a bit of a land mine, need to figure out a solution.

I have a board here but not sure when I will get back to it.

>> Dlmalloc should never fall back into malloc_simpile(), I think.

This is for pre-relocation malloc() in U-Boot proper. In general we
have limited RAM and so no space for the full malloc() area (nor can
we access it if it is in SDRAM).

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

Regards,
Simon