[U-Boot] [Patch v2 6/7] powerpc/mpc8349emds: Migrate from spd_sdram to unified DDR driver

[York Sun]

On Wed, 2011-12-07 at 21:40 +0100, Wolfgang Denk wrote:
> Dear Kim & Kumar,
> 
> many weeks ago in message
> <20111023095323.2087511F9E79 at gemini.denx.de> I wrote:
> 
> > Dear Kumar Gala,
> > 
> > In message <2A6300E8-A874-49AC-84CB-BE681AF1BF90 at freescale.com> you wrote:
> > > 
> > > On Aug 26, 2011, at 1:32 PM, York Sun wrote:
> > > 
> > > > Update MPC8349EMDS to use unified DDR driver instead of spd_sdram.c.
> > > > The unified driver can initialize data using DDR controller. No need to
> > > > use DMA if just to initialze for ECC.
> > > > 
> > > > Signed-off-by: York Sun <yorksun at freescale.com>
> > > > Signed-off-by: Kim Phillips <kim.phillips at freescale.com>
> > > > ---
> > > > board/freescale/mpc8349emds/Makefile      |    1 +
> > > > board/freescale/mpc8349emds/ddr.c         |  107 +++++++++++++++++++++++++++++
> > > > board/freescale/mpc8349emds/mpc8349emds.c |   26 ++++---
> > > > include/configs/MPC8349EMDS.h             |   16 ++++
> > > > 4 files changed, 139 insertions(+), 11 deletions(-)
> > > > create mode 100644 board/freescale/mpc8349emds/ddr.c
> > > 
> > > applied to 85xx 'next'
> > 
> > Did you test it???
> > 
> > 
> > This patch breaks out-of-tree building of the MPC8349EMDS board:
> > 
> > + MAKEALL_LOGDIR=/work/wd/tmp-ppc-LOG
> > + BUILD_DIR=/work/wd/tmp-ppc
> > + ./MAKEALL MPC8349EMDS
> > Configuring for MPC8349EMDS board...
> > make[1]: *** No rule to make target `/work/wd/tmp-ppc/arch/powerpc/cpu/mpc83xx/.depend.ddr-gen2', needed by `/work/wd/tmp-ppc/arch/powerpc/cpu/mpc83xx/.depend'.  Stop.
> > make[1]: *** No rule to make target `/work/wd/tmp-ppc/arch/powerpc/cpu/mpc83xx/.depend.ddr-gen2', needed by `/work/wd/tmp-ppc/arch/powerpc/cpu/mpc83xx/.depend'.  Stop.
> > make: *** [depend] Error 2
> > 
> > [Local building works.]
> > 
> > 
> > Note also that "make distclean" still leaves a file
> > arch/powerpc/cpu/mpc83xx/ddr-gen2.c
> > 
> > Please fix this, too.
> 
> Is anybody going to fix this?  Or can I assume the board is dead and
> we can remove it?

A patch was sent on Oct 25 to fix this

http://patchwork.ozlabs.org/patch/121746/

York