Hey Gents,
So the 2T timings did the trick, phoooow!
This is fair enough. Actually, our final hardware is not having any DIMMs but the chipsets themselves mounted on the board. So anyway all the timings will need to be found again.
This is enough to allow me going forward with the dev until we get our protos!
As a side note, Intel and their "protection by obscurity". I am fighting for a bit more than one week to obtain an "orange cover" document from Intel :
*RS - Intel(R) EP80579 Integrated Processor Product Line BIOS/Firmware Writer's Guide
*They have asked us to sign a CNDA and now we are waiting to receive a RSNDA to maybe get this document.
I will be laughing if this document does not provide any key information finally.
We will see!
Thanks for all your support guys, I(we)'ve got it working even if the performance will not be as good as in 1T mode.
Arnaud
Joseph Smith wrote:
On Wed, 24 Jun 2009 07:29:02 -0700, Ed Swierk eswierk@aristanetworks.com wrote:
On Wed, Jun 24, 2009 at 6:36 AM, Arnaud Mayearnaud.maye@4dsp.com wrote:
I've tried a reverse engineer approach. Plug a DIMM into the system and launch Linux with the legacy BIOS. lspci -xxx then shows me the IMCH BAR and implicitly the settings doctored by the legacy BIOS. The first try I've done was to try the r-e DRT0/DRT1 in the coreboot RAM init code. Not much differences so far. But anyway I've seen quite a lot of
difference
around the ODT register and such. So there is still some hope.
Have you tried 2T timing? This causes the memory controller to wait an extra cycle before sending a command. The delay can compensate for slight misconfiguration of other signal timing settings so it's a good place to start.
Also try different RCOMP values. I have no idea what RCOMP is but I remember having to tweak it to get the memory to behave.
FYI, RCOMP (resistive compensation) is part of the Buffer Strength calculation. I far as I know there are no public docs explaining RCOMP but (hint:-)) there may possibly be patents that explain it.
* *