[U-Boot] __fsl_ddr_set_lawbar: ERROR (ctrl #0, intrlv=0)

[U-Boot] __fsl_ddr_set_lawbar: ERROR (ctrl #0, intrlv=0)

[Wolfgang Denk]

Dear Kumar,

I'm seeing the following problem on a MPC8555 board:

Power-on reset works fine:

...
I2C:   ready
DRAM:  256 MiB (DDR1, 64-bit, CL=2, ECC off)
Flash: 64 MiB
L2:    256 KB enabled
...

But a soft-reset results in this:

=> reset
...
I2C:   ready
DRAM:  __fsl_ddr_set_lawbar: ERROR (ctrl #0, intrlv=0)
256 MiB (DDR1, 64-bit, CL=2, ECC off)
Flash: 64 MiB
L2:    256 KB already enabled
...


Do you have any idea what this means and how to fix it?

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 general, if you think something isn't in Perl, try it out, because
it usually is :-) - Larry Wall in <1991Jul31.174523.9447@netlabs.com>

[U-Boot] __fsl_ddr_set_lawbar: ERROR (ctrl #0, intrlv=0)

[Kumar Gala]

On Jul 25, 2011, at 3:18 AM, Wolfgang Denk wrote:

> Dear Kumar,
> 
> I'm seeing the following problem on a MPC8555 board:
> 
> Power-on reset works fine:
> 
> ...
> I2C:   ready
> DRAM:  256 MiB (DDR1, 64-bit, CL=2, ECC off)
> Flash: 64 MiB
> L2:    256 KB enabled
> ...
> 
> But a soft-reset results in this:
> 
> => reset
> ...
> I2C:   ready
> DRAM:  __fsl_ddr_set_lawbar: ERROR (ctrl #0, intrlv=0)
> 256 MiB (DDR1, 64-bit, CL=2, ECC off)
> Flash: 64 MiB
> L2:    256 KB already enabled
> ...
> 
> 
> Do you have any idea what this means and how to fix it?

On this board what is 'reset' really doing?  I have a theory but would be helpful to understand what's happening.

Can you also send me the full boot log (i'm looking at another bug that might show up on this board).

- k

[U-Boot] __fsl_ddr_set_lawbar: ERROR (ctrl #0, intrlv=0)

[Wolfgang Denk]

Dear Kumar Gala,

In message <AA4FD7C8-6BE0-4847-9332-3AD9521C0C65@kernel.crashing.org> you wrote:
> 
> > DRAM:  __fsl_ddr_set_lawbar: ERROR (ctrl #0, intrlv=3D0)
> > 256 MiB (DDR1, 64-bit, CL=3D2, ECC off)
...
> On this board what is 'reset' really doing?  I have a theory but would
> be helpful to understand what's happening.

This is a MPC8555 based board:

	CPU:   8555E, Version: 1.1, (0x80790011)
	Core:  Unknown, Version: 2.0, (0x80200020)

THe do_reset() code is supposed to be the one from
"arch/powerpc/cpu/mpc85xx/cpu.c"

Side note: rebooting Linux doesn't work either - it just hangs the
board in Linux v3.0 and any earlier version I can still compile with
my Fedora15 based host, i.e. down to around 2.6.32 or so.

> Can you also send me the full boot log (i'm looking at another bug that
> might show up on this board).

Will do as PM.

Thanks.

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
The most difficult thing in the world is to know how to  do  a  thing
and to watch someone else doing it wrong, without commenting.
                                                        -- T.H. White

[U-Boot] __fsl_ddr_set_lawbar: ERROR (ctrl #0, intrlv=0)

[Wolfgang Denk]

Dear Kumar,

In message <20110725175756.D2BD8138EED4@gemini.denx.de> I wrote:
> 
> This is a MPC8555 based board:
> 
> 	CPU:   8555E, Version: 1.1, (0x80790011)
> 	Core:  Unknown, Version: 2.0, (0x80200020)
> 
> THe do_reset() code is supposed to be the one from
> "arch/powerpc/cpu/mpc85xx/cpu.c"

The same (both the "Core: Unknown" and the "__fsl_ddr_set_lawbar:
ERROR" issues) happens on the same board equipped with a MPC8541
processor:

	CPU:   8541E, Version: 1.1, (0x807a0011)
	Core:  Unknown, Version: 2.0, (0x80200020)

Note that old versions of U-Boot (like 1.3.0-rc2-g72e55d03 :-)
used to print here:

	CPU:   8541, Version: 1.1, (0x807a0011)
	Core:  E500, Version: 2.0, (0x80200020)


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
>  Is there a way to determine Yesterday's date using Unix utilities?
         echo "what is yesterday's date?" | /bin/mail root
         -- Randal L. Schwartz in <ukbuh2y982.fsf@julie.teleport.com>

[U-Boot] __fsl_ddr_set_lawbar: ERROR (ctrl #0, intrlv=0)

[Kumar Gala]

On Jul 25, 2011, at 2:28 PM, Wolfgang Denk wrote:

> Dear Kumar,
> 
> In message <20110725175756.D2BD8138EED4@gemini.denx.de> I wrote:
>> 
>> This is a MPC8555 based board:
>> 
>> 	CPU:   8555E, Version: 1.1, (0x80790011)
>> 	Core:  Unknown, Version: 2.0, (0x80200020)
>> 
>> THe do_reset() code is supposed to be the one from
>> "arch/powerpc/cpu/mpc85xx/cpu.c"
> 
> The same (both the "Core: Unknown" and the "__fsl_ddr_set_lawbar:
> ERROR" issues) happens on the same board equipped with a MPC8541
> processor:
> 
> 	CPU:   8541E, Version: 1.1, (0x807a0011)
> 	Core:  Unknown, Version: 2.0, (0x80200020)
> 
> Note that old versions of U-Boot (like 1.3.0-rc2-g72e55d03 :-)
> used to print here:
> 
> 	CPU:   8541, Version: 1.1, (0x807a0011)
> 	Core:  E500, Version: 2.0, (0x80200020)
> 
> 
> Best regards,
> 
> Wolfgang Denk


Yeah, the 'unknown' issue was the other bug I was looking at ;)

- k

[U-Boot] __fsl_ddr_set_lawbar: ERROR (ctrl #0, intrlv=0)

[Kumar Gala]

On Jul 25, 2011, at 12:57 PM, Wolfgang Denk wrote:

> Dear Kumar Gala,
> 
> In message <AA4FD7C8-6BE0-4847-9332-3AD9521C0C65@kernel.crashing.org> you wrote:
>> 
>>> DRAM:  __fsl_ddr_set_lawbar: ERROR (ctrl #0, intrlv=3D0)
>>> 256 MiB (DDR1, 64-bit, CL=3D2, ECC off)
> ...
>> On this board what is 'reset' really doing?  I have a theory but would
>> be helpful to understand what's happening.
> 
> This is a MPC8555 based board:
> 
> 	CPU:   8555E, Version: 1.1, (0x80790011)
> 	Core:  Unknown, Version: 2.0, (0x80200020)
> 
> THe do_reset() code is supposed to be the one from
> "arch/powerpc/cpu/mpc85xx/cpu.c"
> 
> Side note: rebooting Linux doesn't work either - it just hangs the
> board in Linux v3.0 and any earlier version I can still compile with
> my Fedora15 based host, i.e. down to around 2.6.32 or so.
> 
>> Can you also send me the full boot log (i'm looking at another bug that
>> might show up on this board).
> 
> Will do as PM.

Do you know if this board has any real reset on a FPGA or CPLD or something like that.

The problem on the 8555/8541 is the reset you are trigger is just a core reset and not one of the full SoC.  If there is a board level means I would suggest trying to utilize it instead.  If not this might be painful & problematic as you'll have to slowly make sure we are 'resetting' each SoC block properly.

- k

[U-Boot] __fsl_ddr_set_lawbar: ERROR (ctrl #0, intrlv=0)

[Wolfgang Denk]

Dear Kumar Gala,

In message <FC7A4DAE-B05C-49F3-9201-1B5BB559FF47@kernel.crashing.org> you wrote:
> 
> Do you know if this board has any real reset on a FPGA or CPLD or
> something like that.

There is no such faeature on that board, nor on any of a number of
other 85xx boards I have access to.

> The problem on the 8555/8541 is the reset you are trigger is just a core
> reset and not one of the full SoC.  If there is a board level means I
> would suggest trying to utilize it instead.  If not this might be
> painful & problematic as you'll have to slowly make sure we are
> 'resetting' each SoC block properly.

Is this also the cause why the Linux reboot ommand does not work?

If so, I wonder what has changed, because this used to be working in
older versions of the kernel? I did not attampt a full git bisect,
but from some old images I still found it appears it must have been
broken between 2.6.16 ("reboot" in Linux works fine) and 2.6.27
("reboot" does not work any more) - so probably this was part of the
arch/ppc => arch/powerpc rework.

Is there any specific reason we don't use the good old approach of
triggering an unhandled machine check exception?

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
"Am besten betrachten Sie Fehlermeldungen als eine  Art  Psycho-Test,
mit  dem  herausgefunden  werden soll, wie belastbar Sie sind."
 - Dr. R. Wonneberger, Kompaktf?hrer LaTeX, Kap. 1.6: Fehlermeldungen

[U-Boot] __fsl_ddr_set_lawbar: ERROR (ctrl #0, intrlv=0)

[Kumar Gala]

On Jul 26, 2011, at 4:23 AM, Wolfgang Denk wrote:

> Dear Kumar Gala,
> 
> In message <FC7A4DAE-B05C-49F3-9201-1B5BB559FF47@kernel.crashing.org> you wrote:
>> 
>> Do you know if this board has any real reset on a FPGA or CPLD or
>> something like that.
> 
> There is no such faeature on that board, nor on any of a number of
> other 85xx boards I have access to.
> 
>> The problem on the 8555/8541 is the reset you are trigger is just a core
>> reset and not one of the full SoC.  If there is a board level means I
>> would suggest trying to utilize it instead.  If not this might be
>> painful & problematic as you'll have to slowly make sure we are
>> 'resetting' each SoC block properly.
> 
> Is this also the cause why the Linux reboot ommand does not work?

Probably.

> If so, I wonder what has changed, because this used to be working in
> older versions of the kernel? I did not attampt a full git bisect,
> but from some old images I still found it appears it must have been
> broken between 2.6.16 ("reboot" in Linux works fine) and 2.6.27
> ("reboot" does not work any more) - so probably this was part of the
> arch/ppc => arch/powerpc rework.

Possible, its a pretty fragile reset solution so one (or a thousand) of a million things could be the issue.

> Is there any specific reason we don't use the good old approach of
> triggering an unhandled machine check exception?

Hmm, when did we do that?  I've got no issues with it if it causes HRESET_REQ to be signaled on the older devices.  On MPC8548 and greater we provided a means for software to causes HRESET_REQ to be asserted.  So if an unhandled mcheck will do this sounds good to me.

- k

[U-Boot] __fsl_ddr_set_lawbar: ERROR (ctrl #0, intrlv=0)

[Wolfgang Denk]

Dear Kumar Gala,

In message <17E34909-A735-4920-9980-059D95535774@kernel.crashing.org> you wrote:
> 
> > If so, I wonder what has changed, because this used to be working in
> > older versions of the kernel? I did not attampt a full git bisect,
> > but from some old images I still found it appears it must have been
> > broken between 2.6.16 ("reboot" in Linux works fine) and 2.6.27
> > ("reboot" does not work any more) - so probably this was part of the
> > arch/ppc => arch/powerpc rework.
> 
> Possible, its a pretty fragile reset solution so one (or a thousand) of
> a million things could be the issue.
> 
> > Is there any specific reason we don't use the good old approach of
> > triggering an unhandled machine check exception?
> 
> Hmm, when did we do that?  I've got no issues with it if it causes
> HRESET_REQ to be signaled on the older devices.  On MPC8548 and greater
> we provided a means for software to causes HRESET_REQ to be asserted.
> So if an unhandled mcheck will do this sounds good to me.

For example for PQ2 Linux does this (in arch/powerpc/platforms/82xx/pq2.c):

 26 void pq2_restart(char *cmd)
 27 {
 28         local_irq_disable();
 29         setbits32(&cpm2_immr->im_clkrst.car_rmr, RMR_CSRE);
 30
 31         /* Clear the ME,EE,IR & DR bits in MSR to cause checkstop */
 32         mtmsr(mfmsr() & ~(MSR_ME | MSR_EE | MSR_IR | MSR_DR));
 33         in_8(&cpm2_immr->im_clkrst.res[0]);
 34
 35         panic("Restart failed\n");
 36 }

So we set the Checkstop Reset enable, and then reference a known bad
address.

Should we try and do the same here, too?

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
A person with one watch knows what time it  is;  a  person  with  two
watches is never sure.                                       Proverb