[U-Boot] [PATCH] Revert "arm: Switch 32-bit ARM to using generic global_data setup"

[Fabio Estevam]

Hi Simon,

On Tue, Nov 10, 2015 at 12:41 PM, Simon Glass <sjg at 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");
+
     /* 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.

> 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