[U-Boot] gd_t/bd_t on ARM

[U-Boot] gd_t/bd_t on ARM

[Daniel Mack]

Hi,

I'm hunting weird behaviours with the gd_t global data pointer on my
PXA300 board board. The pointer gets set up fine in lib_arm/boot.c and
gd->bd is filled in my board specific code. However, after the tftp
download is finished, the content of these structures have been
destroyed and overwritten with garbage.

I suspect a stack corruption to be the culprit, an overflow or overlap,
as it seems to happen randomly, after a while and some function calls.
Any hints about that?

Also, I wonder why the pointer to this struct is not placed *after*
U-Boot's own code as shown in the patch below. This works fine for me
now. Any oppinion on that?

Thanks and best regards,
Daniel


diff --git a/lib_arm/board.c b/lib_arm/board.c
index 4ba1f5e..90ad5f7 100644
--- a/lib_arm/board.c
+++ b/lib_arm/board.c
@@ -282,12 +282,12 @@ void start_armboot (void)
 #endif
 
        /* Pointer is writable since we allocated a register for it */
-       gd = (gd_t*)(_armboot_start - CONFIG_SYS_MALLOC_LEN - sizeof(gd_t));
+       gd = (gd_t*) _bss_end;
        /* compiler optimization barrier needed for GCC >= 3.4 */
        __asm__ __volatile__("": : :"memory");
 
        memset ((void*)gd, 0, sizeof (gd_t));
-       gd->bd = (bd_t*)((char*)gd - sizeof(bd_t));
+       gd->bd = (bd_t*)((char*)gd + sizeof(gd_t));
        memset (gd->bd, 0, sizeof (bd_t));
 
        gd->flags |= GD_FLG_RELOC;

[U-Boot] gd_t/bd_t on ARM

[Remy Bohmer]

Hello Daniel,

> I'm hunting weird behaviours with the gd_t global data pointer on my
> PXA300 board board. The pointer gets set up fine in lib_arm/boot.c and
> gd->bd is filled in my board specific code. However, after the tftp
> download is finished, the content of these structures have been
> destroyed and overwritten with garbage.
>
> I suspect a stack corruption to be the culprit, an overflow or overlap,
> as it seems to happen randomly, after a while and some function calls.
> Any hints about that?

Hook up a JTAG (or preferable an ETM) debugger and start tracing?

> Also, I wonder why the pointer to this struct is not placed *after*
> U-Boot's own code as shown in the patch below. This works fine for me
> now. Any oppinion on that?

Aren't you just hiding the symptoms here?
It seems that there is something really wrong and by moving the global
structures probably a different memory area is overwritten, but the
problem should still be there...

Kind Regards,

Remy


>
> Thanks and best regards,
> Daniel
>
>
> diff --git a/lib_arm/board.c b/lib_arm/board.c
> index 4ba1f5e..90ad5f7 100644
> --- a/lib_arm/board.c
> +++ b/lib_arm/board.c
> @@ -282,12 +282,12 @@ void start_armboot (void)
>  #endif
>
>        /* Pointer is writable since we allocated a register for it */
> -       gd = (gd_t*)(_armboot_start - CONFIG_SYS_MALLOC_LEN - sizeof(gd_t));
> +       gd = (gd_t*) _bss_end;
>        /* compiler optimization barrier needed for GCC >= 3.4 */
>        __asm__ __volatile__("": : :"memory");
>
>        memset ((void*)gd, 0, sizeof (gd_t));
> -       gd->bd = (bd_t*)((char*)gd - sizeof(bd_t));
> +       gd->bd = (bd_t*)((char*)gd + sizeof(gd_t));
>        memset (gd->bd, 0, sizeof (bd_t));
>
>        gd->flags |= GD_FLG_RELOC;
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>

[U-Boot] gd_t/bd_t on ARM

[Daniel Mack]

Hi Remy,

On Fri, Nov 28, 2008 at 10:39:49PM +0100, Remy Bohmer wrote:
> > I'm hunting weird behaviours with the gd_t global data pointer on my
> > PXA300 board board. The pointer gets set up fine in lib_arm/boot.c and
> > gd->bd is filled in my board specific code. However, after the tftp
> > download is finished, the content of these structures have been
> > destroyed and overwritten with garbage.
> >
> > I suspect a stack corruption to be the culprit, an overflow or overlap,
> > as it seems to happen randomly, after a while and some function calls.
> > Any hints about that?
> 
> Hook up a JTAG (or preferable an ETM) debugger and start tracing?

I did that for a couple of hours now and got somehow stuck with it.
However, I believe it's not related to my board specific code, so I
wanted to ask whether anyone else had similar trouble with the cutting
edge source tree.

> > Also, I wonder why the pointer to this struct is not placed *after*
> > U-Boot's own code as shown in the patch below. This works fine for me
> > now. Any oppinion on that?
> 
> Aren't you just hiding the symptoms here?
> It seems that there is something really wrong and by moving the global
> structures probably a different memory area is overwritten, but the
> problem should still be there...

Of course. That wasn't meant to be the fix for the other problem, I was
just curious as this other location makes more sense to me and also does
not require CONFIG_SYS_GBL_DATA_SIZE anymore. If I got that right, this
variable has to be set to something at least sizeof(gd_t)+sizeof(bd_t).
Right?

Best regards,
Daniel