Shall I use bdi telnet interface to set hardware break point or use gdb, or they are the same? I set break point mode into "HARD", then using gdb set break point, it never stops; if I use bdi interface to set, I saw following message when continue in gdb:

(gdb) c Continuing. Warning: Cannot insert breakpoint -31. Error accessing memory address 0xfff00100: Unknown error 4294967295.

I think we should be able to use software break point in RAM image, right? I really appreciate if you could give a hand on this issue. I need it urgently to debug further issues.

Regards,

- Reeve

On 10/13/06, Reeve Yang yang.reeve@gmail.com wrote:

My CPU is MPC8345E, it's same as MPC8349E with e300 core. Yes, it only supports on hardware break point. I tried it and it didn't work either. When I try to single step the code, I got following message on gdb session:

Cannot find bounds of current function

Is it possible to debug ROM image? Can bdi2000 debug ram image directly? I assume the "load" command is to load image into any memory space, including ram, right?

On 10/13/06, Ben Warren bwarren@qstreams.com wrote:

...

On Fri, 2006-10-13 at 17:41 +0000, Reeve Yang wrote:

...

I'm trying to use bdi2000+gdb to debug u-boot. The image is ROM image on flash, whenever I connect gdb to bdi, I saw execution stops at:

_start: /* time t 0 */ li r21, BOOTFLAG_COLD /* Normal Power-On: Boot from FLASH*/ ===>here nop b boot_cold

Then though I can set break point, e.g. cpu_init_f, but when continue running break point never stops execution and u-boot just runs by itself.

Does it mean I can only debug ram image? does anyone has experience on this could shed some lights?

Thanks.

• Reeve

Remember to use hardware breakpoints, and that your CPU (you didn't mention what type) may only have one. You'll have to clear it after reaching each breakpoint. Read the BREAKMODE and STEPMODE entries (TARGET chapter) in your BDI manual. Also, can you single step through the ROM code?

regards, Ben

On Fri, 2006-10-13 at 18:12 +0000, Reeve Yang wrote:

My CPU is MPC8345E, it's same as MPC8349E with e300 core. Yes, it only supports on hardware break point. I tried it and it didn't work either. When I try to single step the code, I got following message on gdb session:

Cannot find bounds of current function

Is it possible to debug ROM image? Can bdi2000 debug ram image directly? I assume the "load" command is to load image into any memory space, including ram, right?

I don't know how well supported your CPU is (I've never heard of it, but that's not saying much) Anyway, I've debugged ROM on a couple of different MPC8349s, but not with 100% success. I can single-step with the BDI, and can single-step assembly code, but not C code using gdb. Probably operator error, but this is about your problem...

You can certainly debug in RAM. The DULG explains how.

In case it helps, here's my config file. Not much there!

[INIT]

[TARGET] CPUTYPE 8349 ;the CPU type JTAGCLOCK 0 ;use 16 MHz JTAG clock POWERUP 2000 ;start delay after power-up detected in ms WAKEUP 500 ;give reset time to complete STARTUP RESET ;halt immediately at the boot vector

BOOTADDR 0x00000100 ;boot address used for start-up BREAKMODE HARD breakpoint STEPMODE HWBP MMU XLAT 0xc0000000 ;enable address translation PTBASE 0x000000f0 SIO 8023 115200

[HOST] IP 10.69.69.21 LOAD MANUAL ;load code MANUAL or AUTO after reset PROMPT BDI_8349>

[FLASH] CHIPTYPE MIRRORX16 ;Flash type: Spansion CHIPSIZE 0x800000 ;The size of one flash chip in bytes BUSWIDTH 16 WORKSPACE 0x1000 ;workspace in DDR RAM

ERASE 0xfe000000 0x2000 8 ;erase small sectors ERASE 0xfe010000 0x10000 3 ;erase 3 big sectors for U-boot

[REGS] FILE $reg8349e.def

On Fri, 2006-10-13 at 13:38 -0500, Timur Tabi wrote:

Ben Warren wrote:

...

I don't know how well supported your CPU is (I've never heard of it, but that's not saying much) Anyway, I've debugged ROM on a couple of different MPC8349s, but not with 100% success. I can single-step with the BDI, and can single-step assembly code, but not C code using gdb.

I don't know about PowerPC processors, but on x86, single-stepping assembly code is completely different from single-stepping C code. With assembly, the debugger typically enables instruction interrupts, where an interrupt is generated after each instruction is executed. This does not require modifying memory.

With C code, a single line of C code is usually multiple assembly instructions, so the debugger (gdb in this case) places a breakpoint at the appropriate spot.

That's some good insight, and would certainly explain my problem. Thanks!

Ben