u-boot is getting stuck at infinite_debug_loop: in start.S

[venkatt]

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

[sinanakman]

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

[venkatt]

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

[venkatt]

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

[bpe]

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!
-----------------------------------------------------------------------------------------------------------------------

[venkatt]

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 

 

[venkatt]

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