[U-Boot-Users] Re: BDI and u-boot

[Dmytro Bablinyuk]

>       Try `ti` instead of `go` to see where it resets.
  ...
(gdb) ni
<signal handler called>
(gdb) disassemble
Dump of assembler code for function boot_cold:
0xfff00118 <boot_cold+0>:       lis     r3,3841
0xfff0011c <boot_cold+4>:       nop
0xfff00120 <boot_cold+8>:       lwz     r4,0(r3)
0xfff00124 <boot_cold+12>:      nop
0xfff00128 <boot_cold+16>:      rlwinm  r4,r4,0,8,5
0xfff0012c <boot_cold+20>:      nop
0xfff00130 <boot_cold+24>:      oris    r4,r4,512
0xfff00134 <boot_cold+28>:      nop
0xfff00138 <boot_cold+32>:      stw     r4,0(r3)
0xfff0013c <boot_cold+36>:      nop
(gdb) ni
Cannot access memory at address 0x3b87018
(gdb) info program
Debugging a target over a serial line.
Program stopped at 0xfff00124.
It stopped with signal SIGTRAP, Trace/breakpoint trap.
(gdb)

I have discovered that if I use IMMR from default config for BDI
WM32   0x0F0101A8      0x04700000      ;IMMR : internal space @ 0x04700000
...
then on 'ti' or 'go' it resetting after only a few commands (see above).
If I comment the IMMR in ads8272.cfg (BDI config) then I can debug 
through BDI or gdb.
BUT - if I do

(gdb) reset
<signal handler called>
(gdb) c
Continuing.

Program received signal SIGSTOP, Stopped (signal).
<signal handler called>

AND If I do

(gdb) reset
<signal handler called>
(gdb) ni
<signal handler called>
(gdb) ni
<signal handler called>
(gdb) c
Continuing.

Breakpoint 2, <signal handler called>
(gdb) p dest_addr
$1 = 0x3fc7000
...

It's like a delay required or I don't know what it is - I just need to 
do a few 'ni' before 'c', otherwise I have SIGSTOP. I think I am missing 
something.

ALSO if I type
(gdb) n
then it will never come back and I can see on BDI
- TARGET: stepped
- TARGET: stepped
- TARGET: stepped
...
Have you seen this before? What I missed?

Thank you