From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wolfgang Denk Date: Thu, 04 Nov 2004 10:39:48 +0100 Subject: [U-Boot-Users] My problem with gdb ! In-Reply-To: Your message of "Thu, 04 Nov 2004 13:33:23 +0530." <93AC2F9171509C4C9CFC01009A820FA001C003D8@blr-ec-msg05.wipro.com> Message-ID: <20041104093953.DF48FC1430@atlas.denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Dear Ravi, in message <93AC2F9171509C4C9CFC01009A820FA001C003D8@blr-ec-msg05.wipro.com> you wrote: > > [ravi at localhost u-boot-arm11]$ arm-linux-gdb u-boot ... > (gdb) target remote bdi:2001 > Remote debugging using bdi:2001 > 0x48000000 in ?? () As you can see here, this is not the reset entry point (0x0000). Obviously, the board has been already running some or maybe even many instructions before it was stopped by the BDI2000. Check your BDI2000 config file, and check the BDI's runmode. > (gdb) b cpu_init > Breakpoint 1 at 0x80e811c4: file cpu.c, line 93. > (gdb) c > Continuing. > > I waited for about 20 mintes. No response. I was expecting the > breakpoint to hit as explained in 'DULG document' section "10.1.1 Probably the function cpu_init() was never reached. Either it was executed long ago before you attached to the BDI2000, or the board crashed before reaching it. Simply pressing "^C" in GDB will interrupt execution and give you a chance to find out where the program is running and what it is currently doing. Also, performing a "mon reset", "mon go" sequence is probably a good idea as this will allow you to start from a defined state. Best regards, Wolfgang Denk -- See us @ Embedded/Electronica Munich, Nov 09 - 12, Hall A.6 Booth 513 Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de I've got a bad feeling about this.