diff mbox

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

Message ID 1362092359-16113-1-git-send-email-festevam@gmail.com
State Awaiting Upstream
Delegated to: Stefano Babic
Headers show

Commit Message

Fabio Estevam Feb. 28, 2013, 10:59 p.m. UTC 
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
...

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(-)

Comments

Otavio Salvador March 6, 2013, 1:44 p.m. UTC | #1 
On Thu, Feb 28, 2013 at 7:59 PM, Fabio Estevam <festevam@gmail.com> 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
> ...
>
> 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>

Acked-by: Otavio Salvador <otavio@ossystems.com.br>
Marek Vasut March 6, 2013, 2:31 p.m. UTC | #2 
Dear Otavio Salvador,

> On Thu, Feb 28, 2013 at 7:59 PM, Fabio Estevam <festevam@gmail.com> 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
> > ...
> > 
> > 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>
> 
> Acked-by: Otavio Salvador <otavio@ossystems.com.br>

Otavio, did you review the changes done in this patch ?

Best regards,
Marek Vasut
Otavio Salvador March 6, 2013, 3:33 p.m. UTC | #3 
On Wed, Mar 6, 2013 at 11:31 AM, Marek Vasut <marex@denx.de> wrote:
> Dear Otavio Salvador,
>
>> On Thu, Feb 28, 2013 at 7:59 PM, Fabio Estevam <festevam@gmail.com> 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
>> > ...
>> >
>> > 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>
>>
>> Acked-by: Otavio Salvador <otavio@ossystems.com.br>
>
> Otavio, did you review the changes done in this patch ?

This is the setup used in FSL U-Boot and it fixes 2.6.35.3 cpufreq
kernel hang; it is good enough for me to accept it. If you care
enough, go ahead and check every change bit.
Marek Vasut March 6, 2013, 3:41 p.m. UTC | #4 
Dear Otavio Salvador,

> On Wed, Mar 6, 2013 at 11:31 AM, Marek Vasut <marex@denx.de> wrote:
> > Dear Otavio Salvador,
> > 
> >> On Thu, Feb 28, 2013 at 7:59 PM, Fabio Estevam <festevam@gmail.com> 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
> >> > ...
> >> > 
> >> > 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>
> >> 
> >> Acked-by: Otavio Salvador <otavio@ossystems.com.br>
> > 
> > Otavio, did you review the changes done in this patch ?
> 
> This is the setup used in FSL U-Boot and it fixes 2.6.35.3 cpufreq
> kernel hang; it is good enough for me to accept it. If you care
> enough, go ahead and check every change bit.

That is indeed the plan, I will Ack this after I am done with it. It will still 
make it for .04, dont worry.

You should not Ack patches you did not even test nor validate, since the value 
of your Ack is declining.

Best regards,
Marek Vasut
Otavio Salvador March 6, 2013, 3:44 p.m. UTC | #5 
On Wed, Mar 6, 2013 at 12:41 PM, Marek Vasut <marex@denx.de> wrote:
> Dear Otavio Salvador,
>
>> On Wed, Mar 6, 2013 at 11:31 AM, Marek Vasut <marex@denx.de> wrote:
>> > Dear Otavio Salvador,
>> >
>> >> On Thu, Feb 28, 2013 at 7:59 PM, Fabio Estevam <festevam@gmail.com> 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
>> >> > ...
>> >> >
>> >> > 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>
>> >>
>> >> Acked-by: Otavio Salvador <otavio@ossystems.com.br>
>> >
>> > Otavio, did you review the changes done in this patch ?
>>
>> This is the setup used in FSL U-Boot and it fixes 2.6.35.3 cpufreq
>> kernel hang; it is good enough for me to accept it. If you care
>> enough, go ahead and check every change bit.
>
> That is indeed the plan, I will Ack this after I am done with it. It will still
> make it for .04, dont worry.
>
> You should not Ack patches you did not even test nor validate, since the value
> of your Ack is declining.

Are you sure you read my comment?

... it fixes 2.6.35.3 cpufreq kernel hang; ...

Regards,

--
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br
Marek Vasut March 6, 2013, 3:46 p.m. UTC | #6 
Dear Otavio Salvador,

> On Wed, Mar 6, 2013 at 12:41 PM, Marek Vasut <marex@denx.de> wrote:
> > Dear Otavio Salvador,
> > 
> >> On Wed, Mar 6, 2013 at 11:31 AM, Marek Vasut <marex@denx.de> wrote:
> >> > Dear Otavio Salvador,
> >> > 
> >> >> On Thu, Feb 28, 2013 at 7:59 PM, Fabio Estevam <festevam@gmail.com> 
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
> >> >> > ...
> >> >> > 
> >> >> > 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>
> >> >> 
> >> >> Acked-by: Otavio Salvador <otavio@ossystems.com.br>
> >> > 
> >> > Otavio, did you review the changes done in this patch ?
> >> 
> >> This is the setup used in FSL U-Boot and it fixes 2.6.35.3 cpufreq
> >> kernel hang; it is good enough for me to accept it. If you care
> >> enough, go ahead and check every change bit.
> > 
> > That is indeed the plan, I will Ack this after I am done with it. It will
> > still make it for .04, dont worry.
> > 
> > You should not Ack patches you did not even test nor validate, since the
> > value of your Ack is declining.
> 
> Are you sure you read my comment?
> 
> ... it fixes 2.6.35.3 cpufreq kernel hang; ...

Yes, I did read it.

Best regards,
Marek Vasut
Stefano Babic March 13, 2013, 8:16 a.m. UTC | #7 
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 ?

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


Regards,
Stefano
Fabio Estevam March 13, 2013, 2:18 p.m. UTC | #8 
Hi Stefano,

On Wed, Mar 13, 2013 at 5:16 AM, Stefano Babic <sbabic@denx.de> wrote:

> 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 ?
>
> Else to be accepted we need at least a Tested-vy for all boards using it.

Yes, having a Tested-by would be really nice.

Currently we have the following mx28 based boards that still needs to be tested:

apx4devkit, m28evk and sc_sps_1.

Veli-Pekka/Marek,

Could you please try this patch on your systems?

About the description of the changes: I haven't really gone deep into
the path of comparing all the bits that changed. I simply took a
working DDR init script for mx28evk from imx bootlets code and used
it.

Moving forward, I think we should split the DDR init per board instead
of a global init.

Regards,

Fabio Estevam
Fabio Estevam March 13, 2013, 2:22 p.m. UTC | #9 
Lauri,

On Wed, Mar 13, 2013 at 11:18 AM, Fabio Estevam <festevam@gmail.com> wrote:
> Hi Stefano,
>
> On Wed, Mar 13, 2013 at 5:16 AM, Stefano Babic <sbabic@denx.de> wrote:
>
>> 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 ?
>>
>> Else to be accepted we need at least a Tested-vy for all boards using it.
>
> Yes, having a Tested-by would be really nice.
>
> Currently we have the following mx28 based boards that still needs to be tested:
>
> apx4devkit, m28evk and sc_sps_1.
>
> Veli-Pekka/Marek,
>
> Could you please try this patch on your systems?

Veli-Pekka's email bounced. Would you have a chance to test it?

Thanks,

Fabio Estevam
Marek Vasut March 13, 2013, 3:15 p.m. UTC | #10 
Dear Fabio Estevam,

> 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
> ...
> 
> 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>

On M28EVK:

Tested-by: Marek Vasut <marex@denx.de>

Best regards,
Marek Vasut
Marek Vasut March 13, 2013, 4:01 p.m. UTC | #11 
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
Stefano Babic March 13, 2013, 4:07 p.m. UTC | #12 
On 13/03/2013 17:01, Marek Vasut wrote:
>> 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

It is perfect for this sort of hexadecimal tables !

Regards,
Stefano
Lauri Hintsala March 14, 2013, 5:09 a.m. UTC | #13 
Hi,

On 03/13/2013 04:22 PM, Fabio Estevam wrote:
> Lauri,
>
> On Wed, Mar 13, 2013 at 11:18 AM, Fabio Estevam <festevam@gmail.com> wrote:
>> Hi Stefano,
>>
>> On Wed, Mar 13, 2013 at 5:16 AM, Stefano Babic <sbabic@denx.de> wrote:
>>
>>> 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 ?
>>>
>>> Else to be accepted we need at least a Tested-vy for all boards using it.
>>
>> Yes, having a Tested-by would be really nice.
>>
>> Currently we have the following mx28 based boards that still needs to be tested:
>>
>> apx4devkit, m28evk and sc_sps_1.
>>
>> Veli-Pekka/Marek,
>>
>> Could you please try this patch on your systems?
>
> Veli-Pekka's email bounced. Would you have a chance to test it?

Yes, I'll test the patch.


Lauri
Otavio Salvador March 18, 2013, 1:15 p.m. UTC | #14 
On Thu, Mar 14, 2013 at 2:09 AM, Lauri Hintsala
<lauri.hintsala@bluegiga.com> wrote:
> Hi,
>
>
> On 03/13/2013 04:22 PM, Fabio Estevam wrote:
>>
>> Lauri,
>>
>> On Wed, Mar 13, 2013 at 11:18 AM, Fabio Estevam <festevam@gmail.com>
>> wrote:
>>>
>>> Hi Stefano,
>>>
>>> On Wed, Mar 13, 2013 at 5:16 AM, Stefano Babic <sbabic@denx.de> wrote:
>>>
>>>> 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 ?
>>>>
>>>> Else to be accepted we need at least a Tested-vy for all boards using
>>>> it.
>>>
>>>
>>> Yes, having a Tested-by would be really nice.
>>>
>>> Currently we have the following mx28 based boards that still needs to be
>>> tested:
>>>
>>> apx4devkit, m28evk and sc_sps_1.
>>>
>>> Veli-Pekka/Marek,
>>>
>>> Could you please try this patch on your systems?
>>
>>
>> Veli-Pekka's email bounced. Would you have a chance to test it?
>
>
> Yes, I'll test the patch.

Lauri, did you give this patch?
Lauri Hintsala March 19, 2013, 6:52 a.m. UTC | #15 
Hi,

On 03/01/2013 12:59 AM, 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
> ...

I tried to boot Freescale's 2.6.35.3 kernel on apx4devkit. The device is 
still freezing after mxs_cpu_init print.


Full logs:

U-Boot 2013.04-rc1-00002-g9659479 (Mar 19 2013 - 08:30:05)

CPU:   Freescale i.MX28 rev1.2 at 454 MHz
BOOT:  SSP SD/MMC #0, 3V3
I2C:   ready
DRAM:  64 MiB
NAND:  128 MiB
MMC:   MXS MMC: 0
In:    serial
Out:   serial
Err:   serial
Net:   FEC
Hit any key to stop autoboot:  0

1944456 bytes read in 754 ms (2.5 MiB/s)
## Booting kernel from Legacy Image at 41000000 ...
    Image Name:   Linux-2.6.35.3-01010-ge53a812
    Created:      2013-03-19   6:31:40 UTC
    Image Type:   ARM Linux Kernel Image (uncompressed)
    Data Size:    1944392 Bytes = 1.9 MiB
    Load Address: 40008000
    Entry Point:  40008000
    Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Linux version 2.6.35.3-01010-ge53a812 (hintsla@bgtlh) (gcc version 4.3.4 
(crosstool-NG-1.7.0) ) #32 Tue Mar 19 08:31:39 EET 2013
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
CPU: VIVT data cache, VIVT instruction cache
Machine: Freescale MX28EVK board
Memory policy: ECC disabled, Data cache writeback
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16256
Kernel command line: console=tty0 console=ttyAMA0,115200 consoleblank=0 
ethaddr=00:07:80:01:66:db btaddr=00:07:80:01:67:0d 
wlanaddr=00:07:80:59:ef:64 root=/dev/mmcblk0p2 rootwait 
mtdparts=gpmi-nand:128k(bootstrap),1024k(boot),768k(env),-(root) rw
PID hash table entries: 256 (order: -2, 1024 bytes)
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 64MB = 64MB total
Memory: 60880k/60880k available, 4656k reserved, 0K highmem
Virtual kernel memory layout:
     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
     DMA     : 0xfde00000 - 0xffe00000   (  32 MB)
     vmalloc : 0xc4800000 - 0xf0000000   ( 696 MB)
     lowmem  : 0xc0000000 - 0xc4000000   (  64 MB)
     modules : 0xbf000000 - 0xc0000000   (  16 MB)
       .init : 0xc0008000 - 0xc002d000   ( 148 kB)
       .text : 0xc002d000 - 0xc03b8000   (3628 kB)
       .data : 0xc03b8000 - 0xc03e4ba0   ( 179 kB)
SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Hierarchical RCU implementation.
	RCU-based detection of stalled CPUs is disabled.
	Verbose stalled-CPUs detection is disabled.
NR_IRQS:288
Console: colour dummy device 80x30
console [tty0] enabled
console [ttyAMA0] enabled
Calibrating delay loop... 226.09 BogoMIPS (lpj=1130496)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
regulator: core version 0.5
NET: Registered protocol family 16
regulator: vddd: 800 <--> 1575 mV at 1500 mV fast normal
regulator: vdddbo: 800 <--> 1575 mV fast normal
regulator: vdda: 1500 <--> 2275 mV at 1800 mV fast normal
vddio = 3380000, val=10
regulator: vddio: 2880 <--> 3680 mV at 3380 mV fast normal
regulator: overall_current: fast normal
regulator: vbus5v:
regulator: mxs-duart-1: fast normal
regulator: mxs-bl-1: fast normal
regulator: mxs-i2c-1: fast normal
regulator: mmc_ssp-1: fast normal
regulator: mmc_ssp-2: fast normal
regulator: charger-1: fast normal
regulator: power-test-1: fast normal
regulator: cpufreq-1: fast normal
i.MX IRAM pool: 124 KB@0xc4820000
Initializing GPMI pins
Initializing SSP2 pins
bio: create slab <bio-0> at 0
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Advanced Linux Sound Architecture Driver Version 1.0.23.
IMX usb wakeup probe
usb DR wakeup device is registered
Switching to clocksource mxs clock source
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
Switched to NOHz mode on CPU #0
TCP established hash table entries: 2048 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
TCP reno registered
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
RPC: Registered udp transport module.
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
WARNING : No battery connected !
Aborting power driver initialization
mxs-battery: probe of mxs-battery.0 failed with error 1
mxs_cpu_init: cpufreq init finished


And after that line the device is completely dead.

Lauri


>
> 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
>
Otavio Salvador March 19, 2013, 11:35 a.m. UTC | #16 
On Tue, Mar 19, 2013 at 3:52 AM, Lauri Hintsala
<lauri.hintsala@bluegiga.com> wrote:
> Hi,
>
>
> On 03/01/2013 12:59 AM, 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
>> ...
>
>
> I tried to boot Freescale's 2.6.35.3 kernel on apx4devkit. The device is
> still freezing after mxs_cpu_init print.
>
>
> Full logs:
>
> U-Boot 2013.04-rc1-00002-g9659479 (Mar 19 2013 - 08:30:05)
>
> CPU:   Freescale i.MX28 rev1.2 at 454 MHz
> BOOT:  SSP SD/MMC #0, 3V3
> I2C:   ready
> DRAM:  64 MiB
> NAND:  128 MiB
> MMC:   MXS MMC: 0
> In:    serial
> Out:   serial
> Err:   serial
> Net:   FEC
> Hit any key to stop autoboot:  0
>
> 1944456 bytes read in 754 ms (2.5 MiB/s)
> ## Booting kernel from Legacy Image at 41000000 ...
>    Image Name:   Linux-2.6.35.3-01010-ge53a812
>    Created:      2013-03-19   6:31:40 UTC
>    Image Type:   ARM Linux Kernel Image (uncompressed)
>    Data Size:    1944392 Bytes = 1.9 MiB
>    Load Address: 40008000
>    Entry Point:  40008000
>    Loading Kernel Image ... OK
> OK
>
> Starting kernel ...
>
> Uncompressing Linux... done, booting the kernel.
> Linux version 2.6.35.3-01010-ge53a812 (hintsla@bgtlh) (gcc version 4.3.4
> (crosstool-NG-1.7.0) ) #32 Tue Mar 19 08:31:39 EET 2013
> CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
> CPU: VIVT data cache, VIVT instruction cache
> Machine: Freescale MX28EVK board
> Memory policy: ECC disabled, Data cache writeback
> Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16256
> Kernel command line: console=tty0 console=ttyAMA0,115200 consoleblank=0
> ethaddr=00:07:80:01:66:db btaddr=00:07:80:01:67:0d
> wlanaddr=00:07:80:59:ef:64 root=/dev/mmcblk0p2 rootwait
> mtdparts=gpmi-nand:128k(bootstrap),1024k(boot),768k(env),-(root) rw
> PID hash table entries: 256 (order: -2, 1024 bytes)
> Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
> Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
> Memory: 64MB = 64MB total
> Memory: 60880k/60880k available, 4656k reserved, 0K highmem
> Virtual kernel memory layout:
>     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
>     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
>     DMA     : 0xfde00000 - 0xffe00000   (  32 MB)
>     vmalloc : 0xc4800000 - 0xf0000000   ( 696 MB)
>     lowmem  : 0xc0000000 - 0xc4000000   (  64 MB)
>     modules : 0xbf000000 - 0xc0000000   (  16 MB)
>       .init : 0xc0008000 - 0xc002d000   ( 148 kB)
>       .text : 0xc002d000 - 0xc03b8000   (3628 kB)
>       .data : 0xc03b8000 - 0xc03e4ba0   ( 179 kB)
> SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
> Hierarchical RCU implementation.
>         RCU-based detection of stalled CPUs is disabled.
>         Verbose stalled-CPUs detection is disabled.
> NR_IRQS:288
> Console: colour dummy device 80x30
> console [tty0] enabled
> console [ttyAMA0] enabled
> Calibrating delay loop... 226.09 BogoMIPS (lpj=1130496)
> pid_max: default: 32768 minimum: 301
> Mount-cache hash table entries: 512
> CPU: Testing write buffer coherency: ok
> regulator: core version 0.5
> NET: Registered protocol family 16
> regulator: vddd: 800 <--> 1575 mV at 1500 mV fast normal
> regulator: vdddbo: 800 <--> 1575 mV fast normal
> regulator: vdda: 1500 <--> 2275 mV at 1800 mV fast normal
> vddio = 3380000, val=10
> regulator: vddio: 2880 <--> 3680 mV at 3380 mV fast normal
> regulator: overall_current: fast normal
> regulator: vbus5v:
> regulator: mxs-duart-1: fast normal
> regulator: mxs-bl-1: fast normal
> regulator: mxs-i2c-1: fast normal
> regulator: mmc_ssp-1: fast normal
> regulator: mmc_ssp-2: fast normal
> regulator: charger-1: fast normal
> regulator: power-test-1: fast normal
> regulator: cpufreq-1: fast normal
> i.MX IRAM pool: 124 KB@0xc4820000
> Initializing GPMI pins
> Initializing SSP2 pins
> bio: create slab <bio-0> at 0
> SCSI subsystem initialized
> usbcore: registered new interface driver usbfs
> usbcore: registered new interface driver hub
> usbcore: registered new device driver usb
> Advanced Linux Sound Architecture Driver Version 1.0.23.
> IMX usb wakeup probe
> usb DR wakeup device is registered
> Switching to clocksource mxs clock source
> NET: Registered protocol family 2
> IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
> Switched to NOHz mode on CPU #0
> TCP established hash table entries: 2048 (order: 2, 16384 bytes)
> TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
> TCP: Hash tables configured (established 2048 bind 2048)
> TCP reno registered
> UDP hash table entries: 256 (order: 0, 4096 bytes)
> UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
> NET: Registered protocol family 1
> RPC: Registered udp transport module.
>
> 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
> WARNING : No battery connected !
> Aborting power driver initialization
> mxs-battery: probe of mxs-battery.0 failed with error 1
> mxs_cpu_init: cpufreq init finished
>
>
> And after that line the device is completely dead.

Are you sure you booted it with the Fabio's patch applied; this is
exactly how it behaves *without* it.
Fabio Estevam March 19, 2013, 12:36 p.m. UTC | #17 
On Tue, Mar 19, 2013 at 3:52 AM, Lauri Hintsala
<lauri.hintsala@bluegiga.com> wrote:

> I tried to boot Freescale's 2.6.35.3 kernel on apx4devkit. The device is
> still freezing after mxs_cpu_init print.

Are you able to boot 3.8?

I assume that the freeze still happened without this patch, right?
Lauri Hintsala March 20, 2013, 5:17 a.m. UTC | #18 
On 03/19/2013 02:36 PM, Fabio Estevam wrote:
> On Tue, Mar 19, 2013 at 3:52 AM, Lauri Hintsala
> <lauri.hintsala@bluegiga.com> wrote:
>
>> I tried to boot Freescale's 2.6.35.3 kernel on apx4devkit. The device is
>> still freezing after mxs_cpu_init print.
>
> Are you able to boot 3.8?

I booted up to 3.2.


> I assume that the freeze still happened without this patch, right?

The freeze happens with and without this patch if I use 2.6.35.3 kernel 
from Freescale.


Lauri
Fabio Estevam March 20, 2013, 5:33 a.m. UTC | #19 
On Wed, Mar 20, 2013 at 2:17 AM, Lauri Hintsala
<lauri.hintsala@bluegiga.com> wrote:

>> Are you able to boot 3.8?
>
>
> I booted up to 3.2.
>
>
>
>> I assume that the freeze still happened without this patch, right?
>
>
> The freeze happens with and without this patch if I use 2.6.35.3 kernel from
> Freescale.

Thanks for testing, Lauri.

I think the issue with cpufreq still happens for you on 2.6.35 because
you may use a different DDR model/topology than the one in mx28evk.

Stefano,

Since this patch does not cause any problems and does fix the 2.6.35
boot on mx28evk, is it possible to apply it for 2013.04?

Thanks,

Fabio Estevam
Stefano Babic March 20, 2013, 8:26 a.m. UTC | #20 
On 20/03/2013 06:33, Fabio Estevam wrote:
> On Wed, Mar 20, 2013 at 2:17 AM, Lauri Hintsala
> <lauri.hintsala@bluegiga.com> wrote:
> 
>>> Are you able to boot 3.8?
>>
>>
>> I booted up to 3.2.
>>
>>
>>
>>> I assume that the freeze still happened without this patch, right?
>>
>>
>> The freeze happens with and without this patch if I use 2.6.35.3 kernel from
>> Freescale.
> 
> Thanks for testing, Lauri.
> 
> I think the issue with cpufreq still happens for you on 2.6.35 because
> you may use a different DDR model/topology than the one in mx28evk.
> 
> Stefano,
> 
> Since this patch does not cause any problems and does fix the 2.6.35
> boot on mx28evk, is it possible to apply it for 2013.04?

Agree - I merge it.

Regards,
Stefano
Stefano Babic March 20, 2013, 10:07 a.m. UTC | #21 
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
> ...
> 

Applied to u-boot-imx, thanks.

Best regards,
Stefano Babic
diff mbox

Patch

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