[U-Boot] gd_t/bd_t on ARM
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;
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@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
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
participants (2)
-
Daniel Mack -
Remy Bohmer