[U-Boot-Users] [PATCH 0/4] PPC4xx: Add board-independent support for DDR2 SPD DIMMs on 440EPx/GRx

[Larry Johnson]

Summary:

 board/amcc/sequoia/sdram.h   |    4 +-
 board/lwmon5/sdram.h         |    4 +-
 cpu/ppc4xx/Makefile          |   31 +-
 cpu/ppc4xx/denali_data_eye.c |  396 +++++++++++++
 cpu/ppc4xx/denali_spd_ddr2.c | 1276 ++++++++++++++++++++++++++++++++++++++++++
 include/ppc440.h             |  514 +++++++++++++++--
 6 files changed, 2167 insertions(+), 58 deletions(-)

This patch adds SPD DDR2 support for the 440EPx ("Denali") SDRAM
controller.  It should also work on the 440GRx.  It is based on the DDR2
SPD code for the 440EP/440EPx, but makes no provision for DDR1 support.
It also takes EPx/GRx SDRAM definitions and support code that are
specific to the Sequoia/Rainier and lwmon5 boards, and copies them to
general 4xx directories.  (Neither Stefan nor I are happy with the names
of the two new files, so suggestions are welcome!)

This code has been tested on prototype Korat boards with three Kingston
DIMMS: 512 MiB ECC (one rank), 512 MiB non-ECC (one rank) and 1 GiB ECC
(two ranks), at PLB frequencies of 133 MHz and 166 MHz.  The Korat board
has a single DIMM socket, but support has been provided (though not
tested) for boards with two DIMM sockets.

The first patch adds the Denali SDRAM controller definitions to
"ppc440.h".  It also fixes two typos in the definitions, so the board-
specific "sdram.h" files containing these definitions are also fixed to
avoid compiler warnings.

The second patch creates a non-board-specific file for performing the
SDRAM data-eye search.  The only significant change from the board-
specific code is that error checking on reads uses ECC error information
in addition to checking the value of the data read back.  This
eliminates the theoretical possibility that a bad read might be masked
by the ECC.

The third patch creates a file containing the code to configure the
SDRAM controller based on the contents of the DIMMs SPDs.  The fourth
patch modifies "Makefile" to build the two new files when appropriate.

All comments and suggestions will be appreciated.

-- Best regards, Larry Johnson <lrj at acm.org>