Re: [U-Boot-Users] BDI and u-boot
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@lists.sourceforge.net
To: u-boot-users@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
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
participants (2)
-
Dmytro Bablinyuk -
KokHow Teh