Hi Fabio,
On 10 November 2015 at 06:50, Fabio Estevam festevam@gmail.com wrote:
Hi Simon,
On Tue, Nov 10, 2015 at 12:41 PM, Simon Glass sjg@chromium.org wrote:
We're at the very start the release process, so I wonder if we can try to figure out what is wrong here?
Is it because malloc() is not working, perhaps?
Yes, exactly. malloc() is not working.
Issue happens on Congatec board, but the SPL patch for Congatec has not reached mainline yet.
It is simple to reproduce the problem on a mx6sabresd board with the following change:
--- a/board/freescale/mx6sabresd/mx6sabresd.c +++ b/board/freescale/mx6sabresd/mx6sabresd.c @@ -30,6 +30,7 @@ #include "../common/pfuze.h" #include <asm/arch/mx6-ddr.h> #include <usb.h> +#include <malloc.h>
DECLARE_GLOBAL_DATA_PTR;
@@ -833,6 +834,8 @@ static void spl_dram_init(void)
void board_init_f(ulong dummy) {
- void __iomem *ptr;
- /* setup AIPS and disable watchdog */ arch_cpu_init();
@@ -848,6 +851,12 @@ void board_init_f(ulong dummy) /* UART clocks enabled and gd valid - init serial console */ preloader_console_init();
- spl_init();
- ptr = malloc(64);
- if (!ptr)
puts("******* malloc returned NULL\n");
Is this patch against mainline or does your tree have other changes?
/* DDR initialization */ spl_dram_init();It is the ame issue I reported back in August: http://lists.denx.de/pipermail/u-boot/2015-August/222406.html
After I followed your suggestion to call spl_init() prior to malloc() the issue went away.
However with 5ba534d247d4 applied, this no longer works, so I am interested in knowing the appropriate way to fix this malloc() issue inside SPL.
Are you using CONFIG_SYS_MALLOC_F?
The C code should be roughly equivalent to the assembly code. Albert found a problem with the code on toolchain 5.2.1 to do with setting 'gd', so may have some thoughts on this. But this might be a different problem.
I am using 4.7.3 here.
Thanks,
Fabio Estevam
Regards, Simon