[U-Boot-Users] debug u-boot using bdi2000

[U-Boot-Users] debug u-boot using bdi2000

[Reeve Yang]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20061013/8bd18da5/attachment.htm 

[U-Boot-Users] debug u-boot using bdi2000

[Ben Warren]

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  

[U-Boot-Users] debug u-boot using bdi2000

[Reeve Yang]

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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20061013/d1442c72/attachment.htm 

[U-Boot-Users] debug u-boot using bdi2000

[Reeve Yang]

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
> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20061013/b1d8c61a/attachment.htm 

[U-Boot-Users] debug u-boot using bdi2000

[Ben Warren]

On Fri, 2006-10-13 at 18:23 +0000, Reeve Yang wrote:
> Shall I use bdi telnet interface to set hardware break point or use
> gdb, or they are the same?

I think you can only set/change the mode using BDI, but am not a GDB
expert.
>  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.
Does your BDI session mention at this point that there are no available
breakpoints?  Before setting a breakpoint in GDB, type "del".  This will
clear any existing breakpoints.  The equivalent command in BDI land is
"ci"
> 
> 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.
> 
You can use either type in RAM, but you'll find soft ones to be much
more convenient.  You obviously have bigger issues to work through
first.  

Have you contacted Abatron (or your Abatron representative) for help?
They're usually extremely helpful.

regards,
Ben

[U-Boot-Users] debug u-boot using bdi2000

[Ben Warren]

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

[U-Boot-Users] debug u-boot using bdi2000

[Timur Tabi]

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.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] debug u-boot using bdi2000

[Ben Warren]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20061013/d6074d06/attachment.htm 

[U-Boot-Users] debug u-boot using bdi2000

[Brent Cook]

On Friday 13 October 2006 13:48, Ben Warren wrote:
> 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

I find it really helpful when debugging C code in ROM to have the output 
of 'cross-compiler-objdump -d u-boot | less' handy for looking up functions 
and such. It's not too hard to get familiar with your CPU's ABI either, after 
a bit of this.