Hi, I am porting u-boot from P2020RDB code base to one of my custom board based on P2020 processor. As u-boot boots from 0xfffffffc, it is getting stuck at infinite_debug_loop: in start.S, I am not familiar with PPC assembly ISA, please help me to debug the fix the issue.
Thanks a lot
Hi Venkat
With your BDI, if you like to not execute your init script you would
need to issue a RESET RUN. Please try this when you reset.
You mentioned that even without BDI you don't see any output
but this might be a separate problem. To ensure your init section
is not executed as Platon suggests use RESET RUN and see what
happens with CCSRBAR. BTW, which config file you are using ?
Regards
Sinan Akman
Hi Sinan,
Thanks for point me to config file, yes after tweaking config file I could able to avoid the infinite_debug_loop.
Then somewhere down the line, it was not able to access the stack set-up under init_ram, in my case its at oxffd0_0000, which I mapped to L2SRAM via config file then all function call were fine.
Now I got stuck at function "cpu_init_early_f ", basically control is not coming out of this function, because LR is re-loading with wrong value at the end of this routine, but while entering the routine the LR was right. so to skip I forced the LR to "cpu_init_early_f + 0x04" . but after reaching here target is getting freezed.
I made use of buildroot to set-up cross-compiler and finaly I have
"powerpc-unkown-linux-uclibcspe-gcc-4.5.3"
please suggest is it must to use compiler with "EABI" extention as its SPE for me now
Thanks,
Venkat
Hi All,
I am able to boot u-boot on my board with BDI connected, i.e 'reset halt' and 'go' will bring the board up.
But as I try to boot the board independently i.e without bdi connected I dont see any output on console.
still u-boot is missing something that BDI config does if so please help to find that missing stuff.
Thanks a lot
venkat
u-Boot enters infinite_debug_loop if it discovers that CCSRBAR is not
at the location it expects. start.S has a comment about that a few lines
above the loop. If you are working with a JTAG debugger, make sure
it executes no startup script which alters CCSRBAR before u-Boot
gets control.
Have a great day,
Platon
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Hi Platon,
Thanks for info,
when you say CCSRBAR is not at the location it expects means, do it expects it to be at default location i.e 0xff700000 ?
-----------------
I use bdi jtag debugger, after flashing u-boot as I run below commands
BDI> reset
BDI> go
I don't think the script executes with those commands
as-well when I saw below info when core is at halted state and PC points to reset-vector address CCSRBAR ( line # 9) has other than default value - IS THIS THE CONCERN
sorry I pressed ctrl+s before completion,
at line #10 I did reset then after CCSRBAR is at default location,
then go and info shows that PC is stuck at 0xffff_f29c which is the infinite_debug_loop address, as per System.map file.
-----------------------
Even I tried with BDI disconnected from target and did a powercycle but I dont see anything on the console ( both for 9600 and 115200 baud rate )
Please help.
Thank you... and good day