Revert "arm: Switch 32-bit ARM to using generic global_data setup"

This reverts commit 5ba534d247d418e09c5b4fe5fb7fa780aac08e49.

This commit causes cgtqmx6eval to not boot anymore:

U-Boot SPL 2015.10-00527-g8800bee (Nov 09 2015 - 21:23:54)
mxc_spi: SPI Slave not allocated !

Signed-off-by Fabio Estevam <[email protected]>

---
 arch/arm/lib/crt0.S | 28 ++++++++++++++++++++++++----
 1 file changed, 24 insertions(+), 4 deletions(-)

arch/arm/lib/crt0.S +24 -5

index 80548eb..4c3a94a 100644
@@ -82,11 +82,31 @@ ENTRY(_main)
 #else
        bic     sp, sp, #7      /* 8-byte alignment for ABI compliance */
 #endif
-       mov     r0, sp
-       bl      board_init_f_mem
-       mov     sp, r0
-
+       mov     r2, sp
+       sub     sp, sp, #GD_SIZE        /* allocate one GD above SP */
+#if defined(CONFIG_CPU_V7M)    /* v7M forbids using SP as BIC destination */
+       mov     r3, sp
+       bic     r3, r3, #7
+       mov     sp, r3
+#else
+       bic     sp, sp, #7      /* 8-byte alignment for ABI compliance */
+#endif
+       mov     r9, sp          /* GD is above SP */
+       mov     r1, sp
        mov     r0, #0
+clr_gd:
+       cmp     r1, r2                  /* while not at end of GD */
+#if defined(CONFIG_CPU_V7M)
+       itt     lo
+#endif
+       strlo   r0, [r1]                /* clear 32-bit GD word */
+       addlo   r1, r1, #4              /* move to next */
+       blo     clr_gd
+#if defined(CONFIG_SYS_MALLOC_F_LEN)
+       sub     sp, sp, #CONFIG_SYS_MALLOC_F_LEN
+       str     sp, [r9, #GD_MALLOC_BASE]
+#endif
+       /* mov r0, #0 not needed due to above code */
        bl      board_init_f
 
 #if ! defined(CONFIG_SPL_BUILD)
--

1.9.1

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?

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.

Hi Simon,

Quoted 4 lines · Simon Glass

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:

board/freescale/mx6sabresd/mx6sabresd.c +3 -0

@@ -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();
 

board/freescale/mx6sabresd/mx6sabresd.c +0 -0

     /* 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.

Quoted 5 lines

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

Is this patch against mainline or does your tree have other changes?

Quoted 6 lines

     /* 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

Quoted 6 lines

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?

Quoted 1 line

Are you using CONFIG_SYS_MALLOC_F?

No, I am not, but I have also tried adding CONFIG_SYS_MALLOC_F_LEN inside configs/mx6sabresd_spl_defconfig, but it did not help.

Quoted 4 lines · Fabio Estevam

Quoted 1 line

Are you using CONFIG_SYS_MALLOC_F?

No, I am not, but I have also tried adding CONFIG_SYS_MALLOC_F_LEN inside configs/mx6sabresd_spl_defconfig, but it did not help.

Sorry, you asked for CONFIG_SYS_MALLOC_F. I do have CONFIG_SYS_MALLOC_F selected

Then I wonder why malloc() is failing? Is it because there is too much

being allocated, or is the simple malloc region not being set up correctly?

Hi Simon,

Quoted 1 line · Simon Glass

Then I wonder why malloc() is failing? Is it because there is too much

In the example I sent I only allocate 64 bytes. malloc() does fail even if I decrease this number.

Quoted 2 lines

being allocated, or is the simple malloc region not being set up correctly?

This puzzles me too. I am not very familiar with this code and I don't know the reason why reverting 5ba534d247d41 'fixes' the problem.

Are you able to check what is happening in malloc_simple()? It is a really simple function.

Quoted 2 lines · Simon Glass

Are you able to check what is happening in malloc_simple()? It is a really simple function.

Yes, I turned on debug inside malloc_simple() and it returns NULL:

U-Boot SPL 2015.10-00523-ge490ad2-dirty (Nov 10 2015 - 19:44:06)
malloc_simple: size=40, ptr=40, limit=1000
**** malloc_simple returns NULL
******* malloc returned NULL

map_sysmem() is returning NULL inside malloc_simple().

That suggests that gd->malloc_base is not being set up, or is being overwritten later. Presumably it should not be NULL?

Hi Fabio,

Quoted 11 lines · Fabio Estevam

This reverts commit 5ba534d247d418e09c5b4fe5fb7fa780aac08e49.

This commit causes cgtqmx6eval to not boot anymore:

U-Boot SPL 2015.10-00527-g8800bee (Nov 09 2015 - 21:23:54)
mxc_spi: SPI Slave not allocated !

Signed-off-by Fabio Estevam <[email protected]>

---
 arch/arm/lib/crt0.S | 28 ++++++++++++++++++++++++----
 1 file changed, 24 insertions(+), 4 deletions(-)

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?

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.

Regards,
Simon