AMCC PPC440EPx/sequoia stability question...
Hi all,
I'm working on an AMCC PPC440EPx-based platform that's similar to the Sequoia. The board runs pretty well, but occasionally takes exceptions both in U-Boot and while running Linux. The exceptions vary from Illegal Instructions to FP Unavailable to FP Unimplemented to ITLB and DTLB Errors, to DSI, etc., which made us believe there's a problem with SDRAM. Sometimes there are simple hard lockups from which even the JTAG can't regain control. However, the SDRAM physical/electrical and DDR Controller configurations have been investigated in detail (and some corrections made) with no resulting improvement in the exception behavior.
We see problems primarily at 667 MHz but have noted some issues at 533 MHz as well. Some boards seem particularly susceptible to this while others rarely (if ever) exhibit the problem.
At this point all possibilities are on the table and I'm looking for any input from anyone with experience (good, bad, or whatever) with this processor and/or designs similar to the Sequoia.
Thanks very much,
Dave
Quoted 6 lines · Dave Littell
I'm working on an AMCC PPC440EPx-based platform that's similar to the Sequoia. The board runs pretty well, but occasionally takes exceptions both in U-Boot and while running Linux. The exceptions vary from Illegal Instructions to FP Unavailable to FP Unimplemented to ITLB and DTLB Errors, to DSI, etc., which made us believe there's a problem with SDRAM.
Yes, this is my first idea too. Almost every time such "random" errors are seen, SDRAM setup/initialization is the cause for it.
Quoted 4 lines
Sometimes there are simple hard lockups from which even the JTAG can't regain control. However, the SDRAM physical/electrical and DDR Controller configurations have been investigated in detail (and some corrections made) with no resulting improvement in the exception behavior.
Is the SDRAM termination similar to the one used on Sequoia too? Are you using soldered chips and not DIMM modules? Is ECC available?
Quoted 7 lines
We see problems primarily at 667 MHz but have noted some issues at 533 MHz as well. Some boards seem particularly susceptible to this while others rarely (if ever) exhibit the problem.
At this point all possibilities are on the table and I'm looking for any input from anyone with experience (good, bad, or whatever) with this processor and/or designs similar to the Sequoia.
If you scan the U-Boot mailing list for 440EPx/Denali DDR2 problems, you will most likely find some references.
Please note that I recently introduced a CFG_MEM_TOP_HIDE option for the 440EPx CHIP 11 errata. I suggest you take a look at this too and see if this changes your behavior.
Best regards,
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
=====================================================================
Quoted 11 lines · Stefan Roese
Quoted 3 lines · Dave Littell
At this point all possibilities are on the table and I'm looking for any input from anyone with experience (good, bad, or whatever) with this processor and/or designs similar to the Sequoia.
If you scan the U-Boot mailing list for 440EPx/Denali DDR2 problems, you will most likely find some references.
Please note that I recently introduced a
CFG_MEM_TOP_HIDEoption for the 440EPx CHIP 11 errata. I suggest you take a look at this too and see if this changes your behavior.
Explain this a bit more please? Is a kernel change needed here?
josh
Quoted 5 lines · Josh Boyer
Quoted 3 lines
Please note that I recently introduced a
CFG_MEM_TOP_HIDEoption for the 440EPx CHIP 11 errata. I suggest you take a look at this too and see if this changes your behavior.Explain this a bit more please? Is a kernel change needed here?
This depends. When the bootwrapper version is used then yes, the kernel should get changed. This is because the bootwrapper detects the SDRAM size from the DDR2 controller and passes it to Linux.
Without bootwrapper no changes are needed, since U-Boot already passes the corrected memory size to Linux (totalsize-4k currently).
Best regards,
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
=====================================================================
Quoted 5 lines · Stefan Roese
Quoted 4 lines · Josh Boyer
Quoted 3 lines
Please note that I recently introduced a
CFG_MEM_TOP_HIDEoption for the 440EPx CHIP 11 errata. I suggest you take a look at this too and see if this changes your behavior.
Quoted 8 lines
Quoted 1 line
Explain this a bit more please? Is a kernel change needed here?
This depends. When the bootwrapper version is used then yes, the kernel should get changed. This is because the bootwrapper detects the SDRAM size from the DDR2 controller and passes it to Linux.
Without bootwrapper no changes are needed, since U-Boot already passes the corrected memory size to Linux (totalsize-4k currently).
Hm. Given that AMCC ships the boards with an older U-Boot that requires cuImages, I think we'll need to patch the wrapper. Does 440GRx share this same errata? I would think so.
josh
Quoted 9 lines · Josh Boyer
Quoted 6 lines
This depends. When the bootwrapper version is used then yes, the kernel should get changed. This is because the bootwrapper detects the SDRAM size from the DDR2 controller and passes it to Linux.
Without bootwrapper no changes are needed, since U-Boot already passes the corrected memory size to Linux (totalsize-4k currently).
Hm. Given that AMCC ships the boards with an older U-Boot that requires cuImages, I think we'll need to patch the wrapper.
Yes, this should be done too. I forgot about it since I usually don't use the wrapper.
Quoted 2 lines
Does 440GRx share
this same errata? I would think so.
Yep. Same problem on 440GRx.
Best regards,
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
=====================================================================
Quoted 11 lines · Stefan Roese
Quoted 6 lines · Dave Littell
I'm working on an AMCC PPC440EPx-based platform that's similar to the Sequoia. The board runs pretty well, but occasionally takes exceptions both in U-Boot and while running Linux. The exceptions vary from Illegal Instructions to FP Unavailable to FP Unimplemented to ITLB and DTLB Errors, to DSI, etc., which made us believe there's a problem with SDRAM.
Yes, this is my first idea too. Almost every time such "random" errors are seen, SDRAM setup/initialization is the cause for it.
Quoted 8 lines
Quoted 4 lines
Sometimes there are simple hard lockups from which even the JTAG can't regain control. However, the SDRAM physical/electrical and DDR Controller configurations have been investigated in detail (and some corrections made) with no resulting improvement in the exception behavior.
Is the SDRAM termination similar to the one used on Sequoia too? Are you using soldered chips and not DIMM modules? Is ECC available?
Termination: very likely - they stayed very close to Sequoia, but I'll ask.
We're using soldered chips and there's no ECC.
Quoted 11 lines
Quoted 7 lines
We see problems primarily at 667 MHz but have noted some issues at 533 MHz as well. Some boards seem particularly susceptible to this while others rarely (if ever) exhibit the problem.
At this point all possibilities are on the table and I'm looking for any input from anyone with experience (good, bad, or whatever) with this processor and/or designs similar to the Sequoia.
If you scan the U-Boot mailing list for 440EPx/Denali DDR2 problems, you will most likely find some references.
Will do, thanks for the pointer.
Quoted 4 lines
Please note that I recently introduced a
CFG_MEM_TOP_HIDEoption for the 440EPx CHIP 11 errata. I suggest you take a look at this too and see if this changes your behavior.
I remember this - PPC440EPx Revision A errata CHIP_11, right?
Thanks,
Dave