[U-Boot] __fsl_ddr_set_lawbar: ERROR (ctrl #0, intrlv=0)
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
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
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
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
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
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
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
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
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
participants (2)
-
Kumar Gala -
Wolfgang Denk