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

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

[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 <fabio.estevam@freescale.com>
---
 arch/arm/lib/crt0.S | 28 ++++++++++++++++++++++++----
 1 file changed, 24 insertions(+), 4 deletions(-)

diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S
index 80548eb..4c3a94a 100644
--- a/arch/arm/lib/crt0.S
+++ b/arch/arm/lib/crt0.S
@@ -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

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

[Simon Glass]

Hi Fabio,

On 10 November 2015 at 04:40, Fabio Estevam <fabio.estevam@freescale.com> wrote:
> 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 <fabio.estevam@freescale.com>
> ---
>  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.

>
> diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S
> index 80548eb..4c3a94a 100644
> --- a/arch/arm/lib/crt0.S
> +++ b/arch/arm/lib/crt0.S
> @@ -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
>

Regards,
Simon

[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@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

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

[Simon Glass]

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

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

[Fabio Estevam]

On Tue, Nov 10, 2015 at 1:21 PM, Simon Glass <sjg@chromium.org> wrote:

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

This change is against a clean mainline tree.


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

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.

Regards,

Fabio Estevam

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

[Fabio Estevam]

On Tue, Nov 10, 2015 at 1:38 PM, Fabio Estevam <festevam@gmail.com> wrote:

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

Thanks

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

[Simon Glass]

Hi Fabio,

On 10 November 2015 at 14:16, Fabio Estevam <festevam@gmail.com> wrote:
> On Tue, Nov 10, 2015 at 1:38 PM, Fabio Estevam <festevam@gmail.com> wrote:
>
>>> 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?

Regards,
Simon

[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 7:19 PM, Simon Glass <sjg@chromium.org> wrote:

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

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

Regards,

Fabio Estevam

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

[Simon Glass]

Hi Fabio,

On 10 November 2015 at 14:23, Fabio Estevam <festevam@gmail.com> wrote:
> Hi Simon,
>
> On Tue, Nov 10, 2015 at 7:19 PM, Simon Glass <sjg@chromium.org> wrote:
>
>> 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.
>
>> 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.

Regards,
Simon

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

[Fabio Estevam]

On Tue, Nov 10, 2015 at 7:29 PM, Simon Glass <sjg@chromium.org> wrote:

> 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().

Regards,

Fabio Estevam

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

[Simon Glass]

Hi Fabio,

On 10 November 2015 at 14:47, Fabio Estevam <festevam@gmail.com> wrote:
> On Tue, Nov 10, 2015 at 7:29 PM, Simon Glass <sjg@chromium.org> wrote:
>
>> 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?

Is it possible that you have a memset() somewhere which is zeroing gd?
It would be after board_init_f_mem() and before your malloc().

Regards,
Simon

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

[Fabio Estevam]

On Tue, Nov 10, 2015 at 7:52 PM, Simon Glass <sjg@chromium.org> wrote:

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

Yes, gd->malloc_base is NULL. I just prepared a patch to fix this
issue and will submit it soon.

Regards,

Fabio Estevam

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

[Albert ARIBAUD]

Hello Simon,

On Tue, 10 Nov 2015 06:41:25 -0800, Simon Glass <sjg@chromium.org>
wrote:
> Hi Fabio,
> 
> On 10 November 2015 at 04:40, Fabio Estevam <fabio.estevam@freescale.com> wrote:
> > 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 <fabio.estevam@freescale.com>
> > ---
> >  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.

"Roughly". :)

However:

> 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've looked into cgtqmx6eval, and if I'm not mistaken it builds ARM,
not Thumb, code, whereas the bug I found is on Thumb code (thumb-1 at
least).

So yes, this seems like a different problem than the gcc-5.2.1-induced
one.

> Regards,
> Simon

Amicalement,
-- 
Albert.