[U-Boot-Users] My problem with gdb !

[U-Boot-Users] My problem with gdb !

[ravi.aloor at wipro.com]

Hello, I want to debug linux kernel with BDI2000 on ARM11 based board.
Communication with the BDI2000 from my host machine is fine. I am facing
one warning message from gdb as shown below:

[ravi at localhost 2.6_kernel]$ arm-linux-gdb vmlinux
GNU gdb 6.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are welcome to change it and/or distribute copies of it under certain
conditions. Type "show copying" to see the conditions. There is
absolutely no warranty for GDB.  Type "show warranty" for details. This
GDB was configured as "--host=i686-pc-linux-gnu --target=arm-linux"...
(gdb) target remote bdi:2001
Remote debugging using bdi:2001
0x48000000 in ?? ()
warning: shared library handler failed to enable breakpoint
(gdb) info program
Debugging a target over a serial line.
Program stopped at 0x48000000.
It stopped with signal SIGSTOP, Stopped (signal).
(gdb) n
Cannot find bounds of current function
(gdb) c
Continuing.

Program received signal SIGSTOP, Stopped (signal).
0x0000000c in ?? ()
(gdb) q
The program is running.  Exit anyway? (y or n) y
Remote communication error: Connection reset by peer. [ravi at localhost
2.6_kernel]$

During the compilation to get vmlinux, I selected the following options
that are related to debugging by default with 'make menuconfig' command:
	- Verbose user fault messages
	- Include GDB debugging information in kernel binary
	- Kernel debugging
	- Magic SysRq key
	- Verbose BUG() reporting (adds 70K)
	- Verbose kernel error messages

I think the actual problem is with that "warning" only as shown below. I
am not able to start debugging. Please suggest me what could be the
problem.

Thanks A Lot In Advance,
Ravi

[U-Boot-Users] My problem with gdb !

[Wolfgang Denk]

In message <93AC2F9171509C4C9CFC01009A820FA001BFFFC5@blr-ec-msg05.wipro.com> you wrote:
> 
> Hello, I want to debug linux kernel with BDI2000 on ARM11 based board.

And what exactly has this to do with U-Boot?

Sorry, but you're completely off topic here.

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
"My doctor told me to stop having intimate dinners for  four.  Unless
there are three other people."                         - Orson Welles

[U-Boot-Users] My problem with gdb !

[ravi.aloor at wipro.com]

Hello, I am using 'DULG document'. My work environment in brief:
BDI2000, ARM11 based board with flash memory, RedHat Linux-8.0 host
machine etc. After compiling the source of u-boot, I got u-boot.bin and
u-boot images. Using u-boot.bin image, I reprogrammed flash memory
through serial port. Using u-boot image, I started debugging.

[ravi at localhost u-boot-arm11]$ arm-linux-gdb u-boot
GNU gdb 6.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "--host=i686-pc-linux-gnu
--target=arm-linux"...
(gdb) target remote bdi:2001
Remote debugging using bdi:2001
0x48000000 in ?? ()
(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
Debugging of U-Boot Before Relocation". Please suggest me what could be
the problem. I have tested the communication with BDI2000 from the host
machine using 'ftp' and 'telnet' commands. It's OK.

Thanks A Lot,
Ravi

[U-Boot-Users] My problem with gdb !

[Wolfgang Denk]

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.