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

[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

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

[KokHow Teh]

> ...
>(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
>(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.


It resets as expected. BDI changes the IMMR from the HRCW to 0x04700000 and
the u-boot code snippet shown is accessing address 3841 which is 0x0F010000
in hex which is no longer there....

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

[Dmytro Bablinyuk]

>It resets as expected. BDI changes the IMMR from the HRCW to 0x04700000 and
>the u-boot code snippet shown is accessing address 3841 which is 0x0F010000
>in hex which is no longer there....
>
>  
>
Thank you very much for your help. Indeed now it makes sense.
Also (sorry) when I try to debug and on breakpoint I do
(gdb) n
It never comes back, and BDI shows that it 'stepping, stepping...'
Have you or somebody seen this before?
I really appreciate all your help.
Thank you

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

[Srivatsan CR]

Hi,

    Check whether you have commneted the memory initialization part in your
BDI configuration file. In the BDI configuration file, init memory
controller and init SDRAM should be commented and also comment the IMMR
initialization while debugging u-boot code. If proper address of IMMR
[address is configured by HRCW] is not got, the board might be receiving a
Watchdog reset, which by default is set.

Hope this helps.

With Regards,
C.R.Srivatsan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20051005/96e4596e/attachment.htm 

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

[Dmytro Bablinyuk]

>     Check whether you have commneted the memory initialization part in 
> your BDI configuration file. 

Thank you! Yes, now I can just do (gdb)c.
The only thing remains is when I do

(gdb) c
Continuing.

Breakpoint 1, <signal handler called>
(gdb) n
<never comes back>

GDB never comes back on 'n' command and BDI shows
- TARGET: stepped
- TARGET: stepped
- TARGET: stepped
- TARGET: stepped
- TARGET: stepped
- TARGET: stepped
- TARGET: stepped
- TARGET: stepped
...

Does anybody knows what that mean. In BDI config in init part I have 
left only one line uncommented
WM32    0x0F010004      0xFFFFFFC3      ;SYPCR: disable watchdog
IMMR and everything else in init part is commented.

Thank you