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

[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

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

[KokHow Teh]

Hi;
      Try `ti` instead of `go` to see where it resets.





Dmytro Bablinyuk
<dmytro.bablinyuk@rftechnology.com.au>@lists.sourceforge.net on 10/05/2005
10:35:58 AM

Sent by:    u-boot-users-admin at lists.sourceforge.net


To:    u-boot-users at lists.sourceforge.net
cc:

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


Can anyone please give me advice on the following:
U-boot was burnt at 0xfff00000 (.TEXT) and starts successfully whenever
I disconnect BDI2000 and power cycle our MPC8272ADS.
Without BDI it starts without any problems. But when I try to debug
using BDI board keeps restarting:

8272>reset
- TARGET: processing user reset request
- BDI asserts HRESET
...
8272>info
     Target CPU        : MPC8280/8220/5200 (Zeppo)
     Target state      : debug mode
     Debug entry cause : instruction address breakpoint
     Current PC        : 0xfff00100
     Current CR        : 0x00000000
     Current MSR       : 0x00001002
     Current LR        : 0x00000000
8272>go
*** TARGET: reset detected, restarting target
- BDI asserts HRESET
...

Reset  entry  point  is  at  offset  0x100 so in fact 'go' does "go
0xfff00100" from my understanding, but why is it keep resetting? No
serial output produced.

The map file
.text           0xfff00000    0x2ec14
  cpu/mpc8260/start.o(.text)
  .text          0xfff00000     0x3560 cpu/mpc8260/start.o
                 0xfff001b0                _start_of_vectors
                 0xfff03178                init_8260_core
                 0xfff032ac                dcache_enable
                 0xfff03314                relocate_code
                 0xfff00000                _hrcw_table
                 0xfff0324c                icache_enable
...

What do I miss?

Thank you,

Dimitry



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

[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