[U-Boot-Users] Debugging U-boot with BDI-2000 on MPC8349

[U-Boot-Users] Debugging U-boot with BDI-2000 on MPC8349

[Ben Warren]

Hello,

Has anybody been able to successfully single step through U-boot code on
an MPC8349 CPU using a BDI-2000?  I've been working with an FAE at the
company that represents Abatron in the US, and he seems to think it's a
GDB problem.  Of course, I'd prefer it to be something else...  I'm
using the ppc_6xx-gdb version 6.3 that's part of ELDK 4.0.  I've also
built the latest gdb 6.5, but no dice there either.

Here's a snippet:

(gdb) target remote 10.69.69.200:2001
Remote debugging using 10.69.69.200:2001
0x00000100 in ?? ()
(gdb) b board_init_f
Breakpoint 1 at 0xfe0044a4: file board.c, line 374.
(gdb) c
Continuing.

Breakpoint 1, board_init_f (bootflag=1) at board.c:374
374     {
(gdb) list
369      *
370
************************************************************************
371      */
372
373     void board_init_f (ulong bootflag)
374     {
375             bd_t *bd;
376             ulong len, addr, addr_sp;
377             ulong *s;
378             gd_t *id;
(gdb) next
Cannot access memory at address 0xfd000efc
	
/****** This isn't an address in Flash!  The BDI-2000 shows the PC
incrementing, so 'next' did advance things ******/  

(gdb) del 1
(gdb) b relocate_code
Breakpoint 2 at 0xfe0035a0:
file /bld_home/bwarren/fpga/u-boot/cpu/mpc83xx/start.S, line 888.
(gdb) c
Continuing.

Breakpoint 2, relocate_code ()
    at /bld_home/bwarren/fpga/u-boot/cpu/mpc83xx/start.S:889
889             mr      r9,  r4         /* Save copy of Global Data
pointer */
(gdb) next
890             mr      r10, r5         /* Save copy of Destination
Address */

/****** We can single step through this code for some reason ******/

If anybody's seen this behavior and has any clues, please let me know.
I apologize if this is a bit off-topic.

regards,
Ben

[U-Boot-Users] Debugging U-boot with BDI-2000 on MPC8349

[Timur Tabi]

Ben Warren wrote:
> Hello,
> 
> Has anybody been able to successfully single step through U-boot code on
> an MPC8349 CPU using a BDI-2000?  

I've attached two config files.  One can be used to flash the 9349E-mITX, and the other can be used to debug it.

The flash-enabled one programs a bunch of registers that wake up the flash chip.  Unfortunately, when using this config, U-boot hangs somewhere in start.S.  I'm probably programming the board just differently enough to confuse U-Boot.

The other config programs nothing, which gives U-Boot a clean slate to program.

I presume it should be possible to create a "unified" config that works in both situations, but I haven't had the time to try it.

I've never used GDB with the BDI.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mpc8349e-mITX-flash.cfg
Url: http://lists.denx.de/pipermail/u-boot/attachments/20060914/d0618a5f/attachment.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mpc8349e-mITX.cfg
Url: http://lists.denx.de/pipermail/u-boot/attachments/20060914/d0618a5f/attachment-0001.txt 

[U-Boot-Users] Debugging U-boot with BDI-2000 on MPC8349

[Ben Warren]

Thanks Timur,

On Thu, 2006-09-14 at 13:57 -0500, Timur Tabi wrote:
> Ben Warren wrote:
> > Hello,
> > 
> > Has anybody been able to successfully single step through U-boot code on
> > an MPC8349 CPU using a BDI-2000?  
> 
> I've attached two config files.  One can be used to flash the 9349E-mITX, and the other can be used to debug it.
> 
> The flash-enabled one programs a bunch of registers that wake up the flash chip.  Unfortunately, when using this config, U-boot hangs somewhere in start.S.  I'm probably programming the board just differently enough to confuse U-Boot.
> 
> The other config programs nothing, which gives U-Boot a clean slate to program.
> 
The config I use to debug is much like your second one.  In general,
less is more.
> I presume it should be possible to create a "unified" config that works in both situations, but I haven't had the time to try it.
> 
> I've never used GDB with the BDI.

I've used it with Linux drivers and it's really very slick.  I imagine
it would be excellent with U-boot too, if I could get it to work in code
other than start.S.

regards,
Ben

[U-Boot-Users] Debugging U-boot with BDI-2000 on MPC8349

[Jerry Van Baren]

Ben Warren wrote:
> Thanks Timur,
> 
> On Thu, 2006-09-14 at 13:57 -0500, Timur Tabi wrote:
>> Ben Warren wrote:
>>> Hello,
>>>
>>> Has anybody been able to successfully single step through U-boot code on
>>> an MPC8349 CPU using a BDI-2000?  
>> I've attached two config files.  One can be used to flash the 9349E-mITX, and the other can be used to debug it.
>>
>> The flash-enabled one programs a bunch of registers that wake up the flash chip.  Unfortunately, when using this config, U-boot hangs somewhere in start.S.  I'm probably programming the board just differently enough to confuse U-Boot.
>>
>> The other config programs nothing, which gives U-Boot a clean slate to program.
>>
> The config I use to debug is much like your second one.  In general,
> less is more.
>> I presume it should be possible to create a "unified" config that works in both situations, but I haven't had the time to try it.
>>
>> I've never used GDB with the BDI.
> 
> I've used it with Linux drivers and it's really very slick.  I imagine
> it would be excellent with U-boot too, if I could get it to work in code
> other than start.S.
> 
> regards,
> Ben

Have you tried the FAQ "10.1.2. Debugging of U-Boot After Relocation"?
<http://www.denx.de/wiki/view/DULG/DebuggingUBoot>

gvb

[U-Boot-Users] Debugging U-boot with BDI-2000 on MPC8349

[Ben Warren]

Hi Jerry,

On Thu, 2006-09-14 at 15:39 -0400, Jerry Van Baren wrote:

> Have you tried the FAQ "10.1.2. Debugging of U-Boot After Relocation"?
> <http://www.denx.de/wiki/view/DULG/DebuggingUBoot>
> 
My problem arises when I try to do exactly what's shown in the FAQ
(before relocation, in this case).

Instead of:

Breakpoint 1, cpu_init_f () at cpu_init.c:136
136             asm volatile("  bl      0f"             ::: "lr");
(gdb) s
137             asm volatile("0:        mflr    3"              ::: "r3");
(gdb)

I get:

Breakpoint 1, cpu_init_f (im=0xe0000000) at cpu_init.c:42
42      {
(gdb) s
Cannot access memory at address 0xfd000ed8
(gdb) print im
$1 = (volatile immap_t *) 0xe0000000
(gdb) print *im
Cannot access memory at address 0xe0000000
(gdb)

Uncool.

regards,
Ben