From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Mack Date: Sat, 29 Nov 2008 00:19:43 +0100 Subject: [U-Boot] gd_t/bd_t on ARM In-Reply-To: <3efb10970811281339m17b1d1f5o675e1cc08db817f@mail.gmail.com> References: <20081128210415.GD14044@buzzloop.caiaq.de> <3efb10970811281339m17b1d1f5o675e1cc08db817f@mail.gmail.com> Message-ID: <20081128231943.GF14044@buzzloop.caiaq.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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