[U-Boot] u-boot hangs after detecting DDR3 RAM and Flash.

[U-Boot] u-boot hangs after detecting DDR3 RAM and Flash.

[prakash bedge]

Hi All,

I am facing an error while porting u-boot for my platform because if
exception error.

After running the u-boot to detect the DDR and flash u-boot hangs after
showing the serial console output. In debugger I am seeing PC at 0x00000400
address which the exception handler vector address.

But when I modify the below statement in the function int interrupt_init
(void) in u-boot\lib_ppc\interrupts.c, u-boot continues and I can see the
u-boot prompt and I am able to run all u-boot commands.

int interrupt_init (void)
{
    int ret;

    /* call cpu specific function from $(CPU)/interrupts.c */
    ret = interrupt_init_cpu (&decrementer_count);

    if (ret)
        return ret;

    set_dec (decrementer_count);

---    set_msr (get_msr () | MSR_EE);   //Removed this statement.
++  set_msr (get_msr ());

    return (0);
}

It seems that there is an exception error and because of this u-boot hangs.
But I didn't get any error condition till now.

If someone has earlier experienced this kind of issue, please share.


Regards,
Prakash

[U-Boot] u-boot hangs after detecting DDR3 RAM and Flash.

[Stefan Roese]

Hi Prakash,

On Tuesday 04 May 2010 16:21:19 prakash bedge wrote:
> I am facing an error while porting u-boot for my platform because if
> exception error.
> 
> After running the u-boot to detect the DDR and flash u-boot hangs after
> showing the serial console output. In debugger I am seeing PC at 0x00000400
> address which the exception handler vector address.
> 
> But when I modify the below statement in the function int interrupt_init
> (void) in u-boot\lib_ppc\interrupts.c, u-boot continues and I can see the
> u-boot prompt and I am able to run all u-boot commands.
> 
> int interrupt_init (void)
> {
>     int ret;
> 
>     /* call cpu specific function from $(CPU)/interrupts.c */
>     ret = interrupt_init_cpu (&decrementer_count);
> 
>     if (ret)
>         return ret;
> 
>     set_dec (decrementer_count);
> 
> ---    set_msr (get_msr () | MSR_EE);   //Removed this statement.
> ++  set_msr (get_msr ());

By not setting MSR_EE, you will not be able to receive external interrupts, or 
even worse, your timer will most likely not work. Try the "sleep" command.
 
>     return (0);
> }
> 
> It seems that there is an exception error and because of this u-boot hangs.
> But I didn't get any error condition till now.
> 
> If someone has earlier experienced this kind of issue, please share.

One thing I've noticed in other PPC4xx ports as well, is that DDR auto-
calibration (with short memory tests) can lead to exceptions that need to be 
cleared after the DDR is fully configured. Example:

arch/powerpc/cpu/ppc4xx/44x_spd_ddr2.c:

phys_size_t initdram(int board_type)
{
	...

        /*
         * Clear potential errors resulting from auto-calibration.
         * If not done, then we could get an interrupt later on when
         * exceptions are enabled.
         */
        set_mcsr(get_mcsr());


Hard to tell, if you experience the same problem, since we have little 
information about your platform (which DDR3 core is used etc).

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 at denx.de

[U-Boot] u-boot hangs after detecting DDR3 RAM and Flash.

[prakash bedge]

Hi Stefan,

Thanks.

Shall I need to add sleep() command in the interrupt_init or before it?

I am using Samsung M391B2873EH1-CH9 series 1 GB DDR3 and Denali controller
is being used for driving DDR3.

Regards,
Prakash

On Tue, May 4, 2010 at 8:04 PM, Stefan Roese <sr@denx.de> wrote:

> Hi Prakash,
>
> On Tuesday 04 May 2010 16:21:19 prakash bedge wrote:
> > I am facing an error while porting u-boot for my platform because if
> > exception error.
> >
> > After running the u-boot to detect the DDR and flash u-boot hangs after
> > showing the serial console output. In debugger I am seeing PC at
> 0x00000400
> > address which the exception handler vector address.
> >
> > But when I modify the below statement in the function int interrupt_init
> > (void) in u-boot\lib_ppc\interrupts.c, u-boot continues and I can see the
> > u-boot prompt and I am able to run all u-boot commands.
> >
> > int interrupt_init (void)
> > {
> >     int ret;
> >
> >     /* call cpu specific function from $(CPU)/interrupts.c */
> >     ret = interrupt_init_cpu (&decrementer_count);
> >
> >     if (ret)
> >         return ret;
> >
> >     set_dec (decrementer_count);
> >
> > ---    set_msr (get_msr () | MSR_EE);   //Removed this statement.
> > ++  set_msr (get_msr ());
>
> By not setting MSR_EE, you will not be able to receive external interrupts,
> or
> even worse, your timer will most likely not work. Try the "sleep" command.
>
> >     return (0);
> > }
> >
> > It seems that there is an exception error and because of this u-boot
> hangs.
> > But I didn't get any error condition till now.
> >
> > If someone has earlier experienced this kind of issue, please share.
>
> One thing I've noticed in other PPC4xx ports as well, is that DDR auto-
> calibration (with short memory tests) can lead to exceptions that need to
> be
> cleared after the DDR is fully configured. Example:
>
> arch/powerpc/cpu/ppc4xx/44x_spd_ddr2.c:
>
> phys_size_t initdram(int board_type)
> {
>        ...
>
>        /*
>         * Clear potential errors resulting from auto-calibration.
>         * If not done, then we could get an interrupt later on when
>         * exceptions are enabled.
>         */
>        set_mcsr(get_mcsr());
>
>
> Hard to tell, if you experience the same problem, since we have little
> information about your platform (which DDR3 core is used etc).
>
> 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 at denx.de
>

[U-Boot] u-boot hangs after detecting DDR3 RAM and Flash.

[Stefan Roese]

Hi Prakash,

On Tuesday 04 May 2010 17:03:40 prakash bedge wrote:
> Shall I need to add sleep() command in the interrupt_init or before it?

No. What I meant, was that you should try the "sleep" command on the U-Boot 
prompt, to check, if the timer is working or not. Check if a "sleep 3" really 
takes 3 seconds to return to the prompt.
 
> I am using Samsung M391B2873EH1-CH9 series 1 GB DDR3 and Denali controller
> is being used for driving DDR3.

OK. It would be good if you would contribute your Denali code back to mainline 
U-Boot.

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 at denx.de

[U-Boot] u-boot hangs after detecting DDR3 RAM and Flash.

[prakash bedge]

Hi Stefan,

>> No. What I meant, was that you should try the "sleep" command on the
U-Boot
>> prompt, to check, if the timer is working or not. Check if a "sleep 3"
really
>> takes 3 seconds to return to the prompt.
I commented he MSR_EE in interrupt_init function in cpu/ppc4xx/interrupts.c
to run the u-boot and to get u-boot prompt.

when I executed "sleep 3 " command it doesn't reurns to prompt. It seems
that it hangs in while loop or hangs somewhere else.
what does it mean?


Regards,
Prakash

On Tue, May 4, 2010 at 9:08 PM, Stefan Roese <sr@denx.de> wrote:

> Hi Prakash,
>
> On Tuesday 04 May 2010 17:03:40 prakash bedge wrote:
> > Shall I need to add sleep() command in the interrupt_init or before it?
>
> No. What I meant, was that you should try the "sleep" command on the U-Boot
> prompt, to check, if the timer is working or not. Check if a "sleep 3"
> really
> takes 3 seconds to return to the prompt.
>
> > I am using Samsung M391B2873EH1-CH9 series 1 GB DDR3 and Denali
> controller
> > is being used for driving DDR3.
>
> OK. It would be good if you would contribute your Denali code back to
> mainline
> U-Boot.
>
> 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 at denx.de
>

[U-Boot] u-boot hangs after detecting DDR3 RAM and Flash.

[Stefan Roese]

On Wednesday 05 May 2010 13:48:05 prakash bedge wrote:
> I commented he MSR_EE in interrupt_init function in cpu/ppc4xx/interrupts.c
> to run the u-boot and to get u-boot prompt.
> 
> when I executed "sleep 3 " command it doesn't reurns to prompt. It seems
> that it hangs in while loop or hangs somewhere else.
> what does it mean?

That means, that the timer is not running at all. Since you disabled the 
interrupts in the MSR register.

You need to solve the problem with the hanging trap, most likely resulting 
from the DDR3 setup code.
 
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 at denx.de

[U-Boot] u-boot hangs after detecting DDR3 RAM and Flash.

[prakash bedge]

Hi Stefan,

But, my DDR3 initialization seems to be completed and I am not getting any
error in DDR3 initialization.

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.

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?

Regards,
Prakash
On Wed, May 5, 2010 at 5:22 PM, Stefan Roese <sr@denx.de> wrote:

> On Wednesday 05 May 2010 13:48:05 prakash bedge wrote:
> > I commented he MSR_EE in interrupt_init function in
> cpu/ppc4xx/interrupts.c
> > to run the u-boot and to get u-boot prompt.
> >
> > when I executed "sleep 3 " command it doesn't reurns to prompt. It seems
> > that it hangs in while loop or hangs somewhere else.
> > what does it mean?
>
> That means, that the timer is not running at all. Since you disabled the
> interrupts in the MSR register.
>
> You need to solve the problem with the hanging trap, most likely resulting
> from the DDR3 setup code.
>
> 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 at denx.de
>

[U-Boot] u-boot hangs after detecting DDR3 RAM and Flash.

[prakash bedge]

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 at denx.de
>

[U-Boot] u-boot hangs after detecting DDR3 RAM and Flash.

[Wolfgang Denk]

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 at 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_

[U-Boot] u-boot hangs after detecting DDR3 RAM and Flash.

[prakash bedge]

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 at 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_
>