imx8mp_evk: boot error "alloc space exhausted"
Hello Peng,
I've tried to boot the i.MX8M Plus EVK with U-Boot 2020.10 and faced the error message during the boot process, which indicates that the allocation space in early malloc area is exhausted.
Looking at the log, I was able to bisect it to the commit 28fff3fa1c ("imx: imx8mp_evk: fix boot issue"), where the CONFIG_SYS_MALLOC_F_LEN has been reduced from 0x10000 to 0x8000 and CONFIG_SPL_SYS_MALLOC_SIMPLE was enabled.
Extract from the patch shows the following diff: -CONFIG_SYS_MALLOC_F_LEN=0x10000 +CONFIG_SYS_MALLOC_F_LEN=0x8000 +CONFIG_SPL_SYS_MALLOC_SIMPLE=y
If the CONFIG_SYS_MALLOC_F_LEN is returned to the original value - error message disappears, and I can observe that the total occupation of early malloc area (reported via bdinfo) contains following count: ----------------- u-boot=> bdinfo <snip> Early malloc usage: a648 / 10000 -----------------
As it can be seen, the value 0xa648 overflows the imposed limit of 0x8000, causing 2 allocations after ATF execution to fail.
According to the Patchwork [1], this has been already reported by Fabio but there was no resolution provided to address this further. Neither the commit message in 28fff3fa1c provides any additional hint on why those config options were setup with those values.
V1 of this patch series did not have any config options in it, and the changelog of v2 is also missing to advise why those options were added to the series.
Can you please explain why CONFIG_SYS_MALLOC_F_LEN and CONFIG_SPL_SYS_MALLOC_SIMPLE config options were added with that patch, and if it is safe to have them reverted to the original values?
Another
Thanks a lot!
Regards, Andrey
Link: [1]: http://patchwork.ozlabs.org/project/uboot/patch/20200512093901.14831-2-peng....
Hello Peng,
Just a gentle ping here: can you take a look at the failure reported below?
I've also added Alice Guo since there was some work done om imx8mp_evk board, and uboot-imx list here.
Thanks a lot!
-----Original Message----- From: ZHIZHIKIN Andrey Sent: Tuesday, December 8, 2020 2:40 PM To: Peng Fan peng.fan@nxp.com Cc: U-Boot Mailing List u-boot@lists.denx.de; festevam@gmail.com; Stefano Babic sbabic@denx.de Subject: imx8mp_evk: boot error "alloc space exhausted"
Hello Peng,
I've tried to boot the i.MX8M Plus EVK with U-Boot 2020.10 and faced the error message during the boot process, which indicates that the allocation space in early malloc area is exhausted.
Looking at the log, I was able to bisect it to the commit 28fff3fa1c ("imx: imx8mp_evk: fix boot issue"), where the CONFIG_SYS_MALLOC_F_LEN has been reduced from 0x10000 to 0x8000 and CONFIG_SPL_SYS_MALLOC_SIMPLE was enabled.
Extract from the patch shows the following diff: -CONFIG_SYS_MALLOC_F_LEN=0x10000 +CONFIG_SYS_MALLOC_F_LEN=0x8000 +CONFIG_SPL_SYS_MALLOC_SIMPLE=y
If the CONFIG_SYS_MALLOC_F_LEN is returned to the original value - error message disappears, and I can observe that the total occupation of early malloc area (reported via bdinfo) contains following count:
u-boot=> bdinfo
<snip> Early malloc usage: a648 / 10000 -----------------
As it can be seen, the value 0xa648 overflows the imposed limit of 0x8000, causing 2 allocations after ATF execution to fail.
According to the Patchwork [1], this has been already reported by Fabio but there was no resolution provided to address this further. Neither the commit message in 28fff3fa1c provides any additional hint on why those config options were setup with those values.
V1 of this patch series did not have any config options in it, and the changelog of v2 is also missing to advise why those options were added to the series.
Can you please explain why CONFIG_SYS_MALLOC_F_LEN and CONFIG_SPL_SYS_MALLOC_SIMPLE config options were added with that patch, and if it is safe to have them reverted to the original values?
Another
Thanks a lot!
Regards, Andrey
Link: [1]: http://patchwork.ozlabs.org/project/uboot/patch/20200512093901.14831-2- peng.fan@nxp.com/
-- Andrey
Hi Andrey and Peng,
On Thu, Dec 17, 2020 at 9:51 AM ZHIZHIKIN Andrey andrey.zhizhikin@leica-geosystems.com wrote:
Hello Peng,
Just a gentle ping here: can you take a look at the failure reported below?
I've also added Alice Guo since there was some work done om imx8mp_evk board, and uboot-imx list here.
Thanks a lot!
I have also tried using the ATF version imx_5.4.70_2.3.0 and the DDR firmware from the firmware-5.10 package, but still does not boot for me:
U-Boot SPL 2021.01-rc3-00200-ge668bec96a5f-dirty (Dec 21 2020 - 11:13:56 -0300) Normal Boot WDT: Started with servicing (60s timeout) Trying to boot from BOOTROM image offset 0x8000, pagesize 0x200, ivt offset 0x0
It would be great to have this fixed for the upcoming 2021.01 release.
Thanks
On Mon, Dec 21, 2020 at 11:19 AM Fabio Estevam festevam@gmail.com wrote:
I have also tried using the ATF version imx_5.4.70_2.3.0 and the DDR firmware from the firmware-5.10 package, but still does not boot for me:
U-Boot SPL 2021.01-rc3-00200-ge668bec96a5f-dirty (Dec 21 2020 - 11:13:56 -0300) Normal Boot WDT: Started with servicing (60s timeout) Trying to boot from BOOTROM image offset 0x8000, pagesize 0x200, ivt offset 0x0
It would be great to have this fixed for the upcoming 2021.01 release.
Ok, I re-built U-Boot using the instructions from doc/board/freescale/imx8mp_evk.rst and now it boots fine.
I will submit a patch increasing CONFIG_SYS_MALLOC_F_LEN as reported by Andrey.
Thanks
Subject: Re: imx8mp_evk: boot error "alloc space exhausted"
On Mon, Dec 21, 2020 at 11:19 AM Fabio Estevam festevam@gmail.com wrote:
I have also tried using the ATF version imx_5.4.70_2.3.0 and the DDR firmware from the firmware-5.10 package, but still does not boot for me:
U-Boot SPL 2021.01-rc3-00200-ge668bec96a5f-dirty (Dec 21 2020 - 11:13:56 -0300) Normal Boot WDT: Started with servicing (60s timeout) Trying to boot from BOOTROM image offset 0x8000, pagesize 0x200, ivt offset 0x0
It would be great to have this fixed for the upcoming 2021.01 release.
Ok, I re-built U-Boot using the instructions from doc/board/freescale/imx8mp_evk.rst and now it boots fine.
I will submit a patch increasing CONFIG_SYS_MALLOC_F_LEN as reported by Andrey.
Ah. There must be something exhausted the heap. We use too large malloc f area now.
Regards, Peng.
Thanks
participants (3)
-
Fabio Estevam -
Peng Fan -
ZHIZHIKIN Andrey