Re: [U-Boot] Zynq board is boken
+Tom since there is a patch pending Hi Masahiro, On 8 April 2015 at 02:09, Michal Simek 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 : >>> Hi Masahiro, >>> >>> On 7 April 2015 at 06:06, Masahiro Yamada >>> 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 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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Zynq board is boken
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 : >> Hi Masahiro, >> >> On 7 April 2015 at 06:06, Masahiro Yamada >> 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 >>> 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
Re: [U-Boot] Zynq board is boken
Simon, Thanks for checking this. 2015-04-08 12:25 GMT+09:00 Simon Glass : > Hi Masahiro, > > On 7 April 2015 at 06:06, Masahiro Yamada > 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 >> 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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Zynq board is boken
Hi Masahiro, On 7 April 2015 at 06:06, Masahiro Yamada 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 > 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. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Zynq board is boken
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 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. -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
