[U-Boot-Users] Debugging U-Boot Under DDD
This may be a trivial question, but I hope that someone can answer me. I am bring up u-boot on 8xx.
While doing source level debugging under ddd, whenever I do step, stepi, next or nexti I see green instruction pointer jump all over the code. e.g. it would go to first line, than third line, than 7 line. If I look at machine code window, it is running in normal predictable way.
See: http://www.denx.de/twiki/bin/view/DULG/DebuggingTricks
Matthew
On Mon, 2004-07-12 at 19:08, Talib Alim wrote:
This may be a trivial question, but I hope that someone can answer me. I am bring up u-boot on 8xx.
While doing source level debugging under ddd, whenever I do step, stepi, next or nexti I see green instruction pointer jump all over the code. e.g. it would go to first line, than third line, than 7 line. If I look at machine code window, it is running in normal predictable way.
This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
In message 20040712190824.57774.qmail@web50510.mail.yahoo.com you wrote:
This may be a trivial question, but I hope that someone can answer me.
It's not a trivial question, but a FAQ.
While doing source level debugging under ddd, whenever I do step, stepi, next or nexti I see green instruction pointer jump all over the code. e.g. it would go to first line, than third line, than 7 line. If I look at machine code window, it is running in normal predictable way.
See http://www.denx.de/twiki/bin/view/DULG/DebuggingTricks
Best regards,
Wolfgang Denk
Thanks for the link.
I have debugged u-boot to a point, it has relocated code, setup execptions / interrrupts etc and in main_loop().
At this point if I "Cont", I get pop-up from ddd
/.../u-boot-1.1.1/serial.c: No such file or directory.
There are 23 serial.c files in the tree. Those possibly relavent to me are
./cpu/mpc8xx/serial.c ./tools/gdb/serial.c ./drivers/serial.c
Just before relocating the code, I typed following statements
(gdb) symbol-file (gdb) add-symbol-file u-boot 0xbda000 (gdb) dir cpu/mpc8xx (gdb) dir board/fads (gdb) dir tools/gdb/serial.c (gdb) dir drivers/serial.c
Well, my question is why I am getting "No such file or directory" from ddd and how can I fix this problem.
Usman
--- Wolfgang Denk wd@denx.de wrote:
In message 20040712190824.57774.qmail@web50510.mail.yahoo.com you wrote:
This may be a trivial question, but I hope that someone can answer me.
It's not a trivial question, but a FAQ.
While doing source level debugging under ddd, whenever I do step, stepi, next or nexti I see green instruction pointer jump all over the code. e.g. it would go to first line, than third line, than 7 line. If I look at machine code window, it is running in normal predictable way.
See http://www.denx.de/twiki/bin/view/DULG/DebuggingTricks
Best regards,
Wolfgang Denk
-- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de When it is incorrect, it is, at least *authoritatively* incorrect. - Hitchiker's Guide To The Galaxy
In message 20040712194303.3117.qmail@web50504.mail.yahoo.com you wrote:
At this point if I "Cont", I get pop-up from ddd /.../u-boot-1.1.1/serial.c: No such file or directory.
Sounds like a toolchain or user problem to me.
Just before relocating the code, I typed following statements
(gdb) symbol-file (gdb) add-symbol-file u-boot 0xbda000
How did you start gdb / DDD? Did you really load "u-boot" (i. e. the ELF file)?
(gdb) dir cpu/mpc8xx (gdb) dir board/fads (gdb) dir tools/gdb/serial.c (gdb) dir drivers/serial.c
None of these should be necessary. Which toolchain are you using?
Best regards,
Wolfgang Denk
I am using eldk
[root@lab1 eldk]# cat version ELDK version 3.0 ppc_8xx: Build 2004-02-16
I am starting ddd with following command line
ddd --debugger /opt/eldk/usr/bin/ppc_8xx-gdb target remote bdi:2001 symbol u-boot set $pc = 0x02000100 # my flash is mapped @ 0x02000000 I am using bin {& not elf}, apart from this problem, it seems to be doing fine.
TA
--- Wolfgang Denk wd@denx.de wrote:
In message 20040712194303.3117.qmail@web50504.mail.yahoo.com you wrote:
At this point if I "Cont", I get pop-up from ddd /.../u-boot-1.1.1/serial.c: No such file or directory.
Sounds like a toolchain or user problem to me.
Just before relocating the code, I typed following statements
(gdb) symbol-file (gdb) add-symbol-file u-boot 0xbda000
How did you start gdb / DDD? Did you really load "u-boot" (i. e. the ELF file)?
(gdb) dir cpu/mpc8xx (gdb) dir board/fads (gdb) dir tools/gdb/serial.c (gdb) dir drivers/serial.c
None of these should be necessary. Which toolchain are you using?
Best regards,
Wolfgang Denk
-- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de Old programmers never die, they just become managers.
This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
I am bringing up u-boot-1.1.1 on 852T.
I used "make FADS860T_config" for configuration. Since this is the closet match I could find.
I was given FADS board with 852T, with working cpu, sdram and flash under BDI2000. I took values from bdi configuration and applied to u-boot.
If I single step starting from 0x02000100 (my flash starts @ 0x02000000) through to function void cpu_init_f (volatile immap_t * immr) line # 177. It works ok, but if I "Cont" after starting from 0x02000100, I get SIGABRT at line 177 of file u/mpc8xx/cpu_init.c.
{ line 177 is the actual line from u-boot-1.1.1 tree, line 181 which it claims below is after I added few lines}
Program received signal SIGABRT, Aborted. 0x02002540 in cpu_init_f (immr=0xff000000) at cpu_init.c:181 /home/uansari/sw/bootcode/u-boot-1.1.1/cpu/mpc8xx/cpu_init.c:181:5157:beg:0x2002540
Actual line is code:
/* now restrict to preliminary range */ memctl->memc_br0 = CFG_BR0_PRELIM; --->memctl->memc_or0 = CFG_OR0_PRELIM;
#if (defined(CFG_OR1_PRELIM) && defined(CFG_BR1_PRELIM)) memctl->memc_or1 = CFG_OR1_PRELIM; memctl->memc_br1 = CFG_BR1_PRELIM; #endif
Any idea what is going on here ?
Thanks for the help.
In message 20040713003628.91372.qmail@web50507.mail.yahoo.com you wrote:
If I single step starting from 0x02000100 (my flash starts @ 0x02000000) through to function void cpu_init_f (volatile immap_t * immr) line # 177. It works ok, but if I "Cont" after starting from 0x02000100, I get SIGABRT at line 177 of file u/mpc8xx/cpu_init.c.
This probably means that your BDI2000 config file is not OK.
{ line 177 is the actual line from u-boot-1.1.1 tree, line 181 which it claims below is after I added few lines}
Such reports are useless. Always quote the exact lines in text.
Actual line is code:
/* now restrict to preliminary range */ memctl->memc_br0 = CFG_BR0_PRELIM;--->memctl->memc_or0 = CFG_OR0_PRELIM;
This is much better.
Any idea what is going on here ?
Read the comment in lines 127...141.
Best regards,
Wolfgang Denk
In message 20040713001816.61544.qmail@web50501.mail.yahoo.com you wrote:
I am using eldk
OK.
I am using bin {& not elf}, apart from this problem, it seems to be doing fine.
Try loading the ELF file instead - then GDB will automatically load all required information about source files.
Best regards,
Wolfgang Denk
I tried loading elf file, this is what I get
BDI>erase 0x02000000 chip Erasing flash at 0x02000000 Erasing flash passed BDI>prog 0x02000000 u-boot elf Programming u-boot , please wait .... - File offset 0x00000078 to address 0x04000000 size 131408 # Programming flash memory failed at 0x04000040
TA
--- Wolfgang Denk wd@denx.de wrote:
In message 20040713001816.61544.qmail@web50501.mail.yahoo.com you wrote:
I am using eldk
OK.
I am using bin {& not elf}, apart from this problem, it seems to
be
doing fine.
Try loading the ELF file instead - then GDB will automatically load all required information about source files.
Best regards,
Wolfgang Denk
-- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de The human mind treats a new idea the way the body treats a strange protein - it rejects it. - P. Medawar
This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
In message 20040713175734.30201.qmail@web50506.mail.yahoo.com you wrote:
I tried loading elf file, this is what I get
BDI>erase 0x02000000 chip Erasing flash at 0x02000000 Erasing flash passed BDI>prog 0x02000000 u-boot elf Programming u-boot , please wait ....
- File offset 0x00000078 to address 0x04000000 size 131408
# Programming flash memory failed at 0x04000040
You misunderstood. I was talking about loading the ELF file in GDB, not about programming it to flash using the BDI's telnet interface. These are completely different things.
Best regards,
Wolfgang Denk
Now I am confuse. I am running code which is stored on the flash. I am using ddd (gdb in background) to do source level debugging. If I load elf binary gdb, than I am not really running code on the 852t, but on by Linux / Intell based PC.
TA --- Wolfgang Denk wd@denx.de wrote:
In message 20040713175734.30201.qmail@web50506.mail.yahoo.com you wrote:
I tried loading elf file, this is what I get
BDI>erase 0x02000000 chip Erasing flash at 0x02000000 Erasing flash passed BDI>prog 0x02000000 u-boot elf Programming u-boot , please wait ....
- File offset 0x00000078 to address 0x04000000 size 131408
# Programming flash memory failed at 0x04000040
You misunderstood. I was talking about loading the ELF file in GDB, not about programming it to flash using the BDI's telnet interface. These are completely different things.
Best regards,
Wolfgang Denk
-- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de Always leave room to add an explanation if it doesn't work out.
This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
In message 20040713223921.6564.qmail@web50508.mail.yahoo.com you wrote:
Now I am confuse. I am running code which is stored on the flash. I am using ddd (gdb in background) to do source level debugging. If I load elf binary gdb, than I am not really running code on the 852t, but on by Linux / Intell based PC.
No. This is a cross debugger. Loading a file into GDB and running it on the target are completely separate things.
Best regards,
Wolfgang Denk
participants (3)
-
Matthew McClintock -
Talib Alim -
Wolfgang Denk