Re: [U-Boot] u-boot hangs after detecting DDR3 RAM and Flash.
Hi Stefan
I checked the mcsr register and it shows 0x00000000.
while debugging the u-boot I observed that the u-boot hangs when it call getenv("loadaddr") function. if ((s = getenv ("loadaddr")) != NULL) { .... }
Is it because of loadaddr parameter passed to getenv?
Do I really need to check the DDR3 initialization setup or there is something other stuff I should check? Please suggest.
Another issue I am facing that if I add 2 pritinf functions before or
after
DDR initialization the DDR3 initialization code hangs in between and if I remove the printf functions, everything is working fine and after disabling the EE bit I am able to see the u-boot proopt This is not desired and I am looking in that problem.
Yes, something is wrong here.
This is happening when I added I2C stuff. If I disabled the HARD_I2C flag, then I able to add the printf's and then DDR3 initialization do not hangs. But here also u-boot hangs after DDR3 and flash initialization and it works only after removing MSR_EE bit from interrupt_init function which is not desired.
Regards, Prakash
On Fri, May 7, 2010 at 2:00 PM, Stefan Roese sr@denx.de wrote:
Hi Prakash,
On Thursday 06 May 2010 15:06:38 prakash bedge wrote:
But, my DDR3 initialization seems to be completed and I am not getting
any
error in DDR3 initialization.
Did you actually check the MCSR register after the DDR3 setup? Whats its content?
Another issue I am facing that if I add 2 pritinf functions before or
after
DDR initialization the DDR3 initialization code hangs in between and if I remove the printf functions, everything is working fine and
after
disabling the EE bit I am able to see the u-boot proopt This is not desired and I am looking in that problem.
Yes, something is wrong here.
if I replace the printf whith udelay(5) then also I am facing same issue.
In BDI3000 debugger I am seeing that after set_timer(0) function in cpu/ppc4xx/board.c when I execute next fucntion /* Initialize from environment */ if ((s = getenv ("loadaddr")) != NULL) { ... } then u-boot hangs in between during the execution of getenv(..) function. What may be the reason?
Which registers I should see to check the address of instruction which causes exception?
See above. Check MCSR at some stages while booting, to see, if and when an exception is generated.
Cheers, Stefan
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office@denx.de
Dear prakash bedge,
In message g2zb9c1f3ac1005070752j7df33c45mf707a0ce62f2bc92@mail.gmail.com you wrote:
while debugging the u-boot I observed that the u-boot hangs when it call getenv("loadaddr") function. if ((s = getenv ("loadaddr")) != NULL) { .... }
Is it because of loadaddr parameter passed to getenv?
No. All this code is running on zillions other devices perfectly well. The reason it's not working for you is most likely because your memory is not working correctly, so you're working with corrupted code and corrupted data.
Do I really need to check the DDR3 initialization setup or there is something other stuff I should check?
Yes, you really should concentrate on fixing your memory intialization.
No matter how often you are going to repeat that question, the reply will remain the same.
Best regards,
Wolfgang Denk
Hi,
I got the root cause. It was the DDR related issue while reading the DMC registers.
Now the problem is solved. I am not not getting exception error after enabling MSR_EE. I am moving to use the latest u-boot code (2010.03) believing that there might be fixup for timing issue I am facing when I am adding the printf functions.
Hi Stefan, Thansk for your help so far.
Regards, Prakash Bedge On Fri, May 7, 2010 at 8:47 PM, Wolfgang Denk wd@denx.de wrote:
Dear prakash bedge,
In message g2zb9c1f3ac1005070752j7df33c45mf707a0ce62f2bc92@mail.gmail.com you wrote:
while debugging the u-boot I observed that the u-boot hangs when it call getenv("loadaddr") function. if ((s = getenv ("loadaddr")) != NULL) { .... }
Is it because of loadaddr parameter passed to getenv?
No. All this code is running on zillions other devices perfectly well. The reason it's not working for you is most likely because your memory is not working correctly, so you're working with corrupted code and corrupted data.
Do I really need to check the DDR3 initialization setup or there is something other stuff I should check?
Yes, you really should concentrate on fixing your memory intialization.
No matter how often you are going to repeat that question, the reply will remain the same.
Best regards,
Wolfgang Denk
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find ... - Terry Pratchett, _Sourcery_
participants (2)
-
prakash bedge -
Wolfgang Denk