[U-Boot] [PATCH v2] mxs: spl_mem_init: Align DDR2 init with FSL bootlets source

[Marek Vasut <marex@denx.de>]

Dear Stefano Babic,

> On 28/02/2013 23:59, Fabio Estevam wrote:
> > From: Fabio Estevam <fabio.estevam@freescale.com>
> > 
> > Currently the following kernel hang happens when loading a 2.6.35 kernel
> > from Freeescale on a mx28evk board:
> > 
> > RPC: Registered tcp transport module.
> > RPC: Registered tcp NFSv4.1 backchannel transport module.
> > Bus freq driver module loaded
> > IMX usb wakeup probe
> > usb h1 wakeup device is registered
> > mxs_cpu_init: cpufreq init finished
> > ...
> 
> Hi all,
> 
> > Loading the same kernel using the bootlets from the
> > imx-bootlets-src-10.12.01 package, the hang does not occur.
> > 
> > Comparing the DDR2 initialization from the bootlets code against the
> > U-boot one, we can notice some mismatches, and after applying the same
> > initialization into U-boot the 2.6.35 kernel can boot normally.
> > 
> > Also tested with 'mtest' command, which runs succesfully.
> > 
> > Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> > ---
> > Changes since v1:
> > - Fix tabs/space confusion and only show the real context changes
> > 
> >  arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c |   18 +++++++++---------
> >  1 file changed, 9 insertions(+), 9 deletions(-)
> > 
> > diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
> > b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c index f8392f6..2195dce
> > 100644
> > --- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
> > +++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
> > @@ -45,17 +45,17 @@ static uint32_t dram_vals[] = {
> > 
> >  	0x00000000, 0x00000000, 0x00010101, 0x01010101,
> >  	0x000f0f01, 0x0f02020a, 0x00000000, 0x00010101,
> >  	0x00000100, 0x00000100, 0x00000000, 0x00000002,
> > 
> > -	0x01010000, 0x05060302, 0x06005003, 0x0a0000c8,
> > -	0x02009c40, 0x0000030c, 0x0036a609, 0x031a0612,
> > +	0x01010000, 0x07080403, 0x06005003, 0x0a0000c8,
> > +	0x02009c40, 0x0002030c, 0x0036a609, 0x031a0612,
> > 
> >  	0x02030202, 0x00c8001c, 0x00000000, 0x00000000,
> >  	0x00012100, 0xffff0303, 0x00012100, 0xffff0303,
> >  	0x00012100, 0xffff0303, 0x00012100, 0xffff0303,
> >  	0x00000003, 0x00000000, 0x00000000, 0x00000000,
> >  	0x00000000, 0x00000000, 0x00000000, 0x00000000,
> >  	0x00000000, 0x00000000, 0x00000612, 0x01000F02,
> > 
> > -	0x06120612, 0x00000200, 0x00020007, 0xf5014b27,
> > -	0xf5014b27, 0xf5014b27, 0xf5014b27, 0x07000300,
> > -	0x07000300, 0x07000300, 0x07000300, 0x00000006,
> > +	0x06120612, 0x00000200, 0x00020007, 0xf4004a27,
> > +	0xf4004a27, 0xf4004a27, 0xf4004a27, 0x07000300,
> > +	0x07000300, 0x07400300, 0x07400300, 0x00000005,
> > 
> >  	0x00000000, 0x00000000, 0x01000000, 0x01020408,
> >  	0x08040201, 0x000f1133, 0x00000000, 0x00001f04,
> >  	0x00001f04, 0x00001f04, 0x00001f04, 0x00001f04,
> > 
> > @@ -76,14 +76,14 @@ static uint32_t dram_vals[] = {
> > 
> >  	0x00000000, 0x00000000, 0x00000000, 0x00000000,
> >  	0x00000000, 0x00000000, 0x00000000, 0x00000000,
> >  	0x00000000, 0x00000000, 0x00000000, 0x00000000,
> > 
> > -	0x00000000, 0x00000000, 0x00010000, 0x00020304,
> > -	0x00000004, 0x00000000, 0x00000000, 0x00000000,
> > +	0x00000000, 0x00000000, 0x00010000, 0x00030404,
> > +	0x00000003, 0x00000000, 0x00000000, 0x00000000,
> > 
> >  	0x00000000, 0x00000000, 0x00000000, 0x01010000,
> >  	0x01000000, 0x03030000, 0x00010303, 0x01020202,
> >  	0x00000000, 0x02040303, 0x21002103, 0x00061200,
> > 
> > -	0x06120612, 0x04320432, 0x04320432, 0x00040004,
> > +	0x06120612, 0x04420442, 0x04420442, 0x00040004,
> > 
> >  	0x00040004, 0x00000000, 0x00000000, 0x00000000,
> > 
> > -	0x00000000, 0x00010001
> > +	0x00000000, 0xffffffff
> > 
> >  /*
> >  
> >   * i.MX23 DDR at 133MHz
> 
> Apart of the fact that fixes booting old kernel, these changes affects
> all mx28 boards, not only mx28evk. Can we have a description about which
> changes are done and why they are required ?

Please see [1] below, this describes the situation at hand perfectly :-)

Other than that, I tested it and see no issue.

> Else to be accepted we need at least a Tested-vy for all boards using it.
> 
> 
> Regards,
> Stefano

[1] http://devopsreactions.tumblr.com/post/40166795163/when-you-review-
undocumented-code