Simon,

Thanks for checking this.

2015-04-08 12:25 GMT+09:00 Simon Glass sjg@chromium.org:

Hi Masahiro,

On 7 April 2015 at 06:06, Masahiro Yamada yamada.masahiro@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@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.

+Tom since there is a patch pending

Hi Masahiro,

On 8 April 2015 at 02:09, Michal Simek michal.simek@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@chromium.org:

...

Hi Masahiro,

On 7 April 2015 at 06:06, Masahiro Yamada yamada.masahiro@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@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