* [U-Boot] [PATCH v2] mxs: spl_mem_init: Align DDR2 init with FSL bootlets source
2013-02-28 22:59 [U-Boot] [PATCH v2] mxs: spl_mem_init: Align DDR2 init with FSL bootlets source Fabio Estevam
@ 2013-03-06 13:44 ` Otavio Salvador
2013-03-06 14:31 ` Marek Vasut
2013-03-13 8:16 ` Stefano Babic
` (3 subsequent siblings)
4 siblings, 1 reply; 24+ messages in thread
From: Otavio Salvador @ 2013-03-06 13:44 UTC (permalink / raw)
To: u-boot
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 Salvador O.S. Systems
E-mail: otavio at ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
^ permalink raw reply [flat|nested] 24+ messages in thread* [U-Boot] [PATCH v2] mxs: spl_mem_init: Align DDR2 init with FSL bootlets source
2013-03-06 13:44 ` Otavio Salvador
@ 2013-03-06 14:31 ` Marek Vasut
2013-03-06 15:33 ` Otavio Salvador
0 siblings, 1 reply; 24+ messages in thread
From: Marek Vasut @ 2013-03-06 14:31 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] [PATCH v2] mxs: spl_mem_init: Align DDR2 init with FSL bootlets source
2013-03-06 14:31 ` Marek Vasut
@ 2013-03-06 15:33 ` Otavio Salvador
2013-03-06 15:41 ` Marek Vasut
0 siblings, 1 reply; 24+ messages in thread
From: Otavio Salvador @ 2013-03-06 15:33 UTC (permalink / raw)
To: u-boot
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.
--
Otavio Salvador O.S. Systems
E-mail: otavio at ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] [PATCH v2] mxs: spl_mem_init: Align DDR2 init with FSL bootlets source
2013-03-06 15:33 ` Otavio Salvador
@ 2013-03-06 15:41 ` Marek Vasut
2013-03-06 15:44 ` Otavio Salvador
0 siblings, 1 reply; 24+ messages in thread
From: Marek Vasut @ 2013-03-06 15:41 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] [PATCH v2] mxs: spl_mem_init: Align DDR2 init with FSL bootlets source
2013-03-06 15:41 ` Marek Vasut
@ 2013-03-06 15:44 ` Otavio Salvador
2013-03-06 15:46 ` Marek Vasut
0 siblings, 1 reply; 24+ messages in thread
From: Otavio Salvador @ 2013-03-06 15:44 UTC (permalink / raw)
To: u-boot
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 at ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] [PATCH v2] mxs: spl_mem_init: Align DDR2 init with FSL bootlets source
2013-03-06 15:44 ` Otavio Salvador
@ 2013-03-06 15:46 ` Marek Vasut
0 siblings, 0 replies; 24+ messages in thread
From: Marek Vasut @ 2013-03-06 15:46 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] [PATCH v2] mxs: spl_mem_init: Align DDR2 init with FSL bootlets source
2013-02-28 22:59 [U-Boot] [PATCH v2] mxs: spl_mem_init: Align DDR2 init with FSL bootlets source Fabio Estevam
2013-03-06 13:44 ` Otavio Salvador
@ 2013-03-13 8:16 ` Stefano Babic
2013-03-13 14:18 ` Fabio Estevam
2013-03-13 16:01 ` Marek Vasut
2013-03-13 15:15 ` Marek Vasut
` (2 subsequent siblings)
4 siblings, 2 replies; 24+ messages in thread
From: Stefano Babic @ 2013-03-13 8:16 UTC (permalink / raw)
To: u-boot
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
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================
^ permalink raw reply [flat|nested] 24+ messages in thread* [U-Boot] [PATCH v2] mxs: spl_mem_init: Align DDR2 init with FSL bootlets source
2013-03-13 8:16 ` Stefano Babic
@ 2013-03-13 14:18 ` Fabio Estevam
2013-03-13 14:22 ` Fabio Estevam
2013-03-13 16:01 ` Marek Vasut
1 sibling, 1 reply; 24+ messages in thread
From: Fabio Estevam @ 2013-03-13 14:18 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] [PATCH v2] mxs: spl_mem_init: Align DDR2 init with FSL bootlets source
2013-03-13 14:18 ` Fabio Estevam
@ 2013-03-13 14:22 ` Fabio Estevam
2013-03-14 5:09 ` Lauri Hintsala
0 siblings, 1 reply; 24+ messages in thread
From: Fabio Estevam @ 2013-03-13 14:22 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] [PATCH v2] mxs: spl_mem_init: Align DDR2 init with FSL bootlets source
2013-03-13 14:22 ` Fabio Estevam
@ 2013-03-14 5:09 ` Lauri Hintsala
2013-03-18 13:15 ` Otavio Salvador
0 siblings, 1 reply; 24+ messages in thread
From: Lauri Hintsala @ 2013-03-14 5:09 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] [PATCH v2] mxs: spl_mem_init: Align DDR2 init with FSL bootlets source
2013-03-14 5:09 ` Lauri Hintsala
@ 2013-03-18 13:15 ` Otavio Salvador
0 siblings, 0 replies; 24+ messages in thread
From: Otavio Salvador @ 2013-03-18 13:15 UTC (permalink / raw)
To: u-boot
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?
--
Otavio Salvador O.S. Systems
E-mail: otavio at ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] [PATCH v2] mxs: spl_mem_init: Align DDR2 init with FSL bootlets source
2013-03-13 8:16 ` Stefano Babic
2013-03-13 14:18 ` Fabio Estevam
@ 2013-03-13 16:01 ` Marek Vasut
2013-03-13 16:07 ` Stefano Babic
1 sibling, 1 reply; 24+ messages in thread
From: Marek Vasut @ 2013-03-13 16:01 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 24+ messages in thread* [U-Boot] [PATCH v2] mxs: spl_mem_init: Align DDR2 init with FSL bootlets source
2013-03-13 16:01 ` Marek Vasut
@ 2013-03-13 16:07 ` Stefano Babic
0 siblings, 0 replies; 24+ messages in thread
From: Stefano Babic @ 2013-03-13 16:07 UTC (permalink / raw)
To: u-boot
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
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================
^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] [PATCH v2] mxs: spl_mem_init: Align DDR2 init with FSL bootlets source
2013-02-28 22:59 [U-Boot] [PATCH v2] mxs: spl_mem_init: Align DDR2 init with FSL bootlets source Fabio Estevam
2013-03-06 13:44 ` Otavio Salvador
2013-03-13 8:16 ` Stefano Babic
@ 2013-03-13 15:15 ` Marek Vasut
2013-03-19 6:52 ` Lauri Hintsala
2013-03-20 10:07 ` Stefano Babic
4 siblings, 0 replies; 24+ messages in thread
From: Marek Vasut @ 2013-03-13 15:15 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] [PATCH v2] mxs: spl_mem_init: Align DDR2 init with FSL bootlets source
2013-02-28 22:59 [U-Boot] [PATCH v2] mxs: spl_mem_init: Align DDR2 init with FSL bootlets source Fabio Estevam
` (2 preceding siblings ...)
2013-03-13 15:15 ` Marek Vasut
@ 2013-03-19 6:52 ` Lauri Hintsala
2013-03-19 11:35 ` Otavio Salvador
2013-03-19 12:36 ` Fabio Estevam
2013-03-20 10:07 ` Stefano Babic
4 siblings, 2 replies; 24+ messages in thread
From: Lauri Hintsala @ 2013-03-19 6:52 UTC (permalink / raw)
To: u-boot
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 at 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 at 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
>
^ permalink raw reply [flat|nested] 24+ messages in thread* [U-Boot] [PATCH v2] mxs: spl_mem_init: Align DDR2 init with FSL bootlets source
2013-03-19 6:52 ` Lauri Hintsala
@ 2013-03-19 11:35 ` Otavio Salvador
2013-03-19 11:43 ` Lauri Hintsala
2013-03-19 12:36 ` Fabio Estevam
1 sibling, 1 reply; 24+ messages in thread
From: Otavio Salvador @ 2013-03-19 11:35 UTC (permalink / raw)
To: u-boot
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 at 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 at 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.
--
Otavio Salvador O.S. Systems
E-mail: otavio at ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] [PATCH v2] mxs: spl_mem_init: Align DDR2 init with FSL bootlets source
2013-03-19 11:35 ` Otavio Salvador
@ 2013-03-19 11:43 ` Lauri Hintsala
2013-03-23 16:56 ` Fabio Estevam
0 siblings, 1 reply; 24+ messages in thread
From: Lauri Hintsala @ 2013-03-19 11:43 UTC (permalink / raw)
To: u-boot
On 03/19/2013 01:35 PM, Otavio Salvador wrote:
> 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 at 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 at 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.
Yes, I am. I booted up U-Boot version "2013.04-rc1-00002-g9659479 (Mar
19 2013 - 08:30:05)" and my git log says:
$ git log --oneline -3
9659479 (HEAD) mxs: spl_mem_init: Align DDR2 init with FSL bootlets source
7ddcf4c ARM: mxs: disable battery charger circuit
2536850 (tag: v2013.04-rc1) Prepare v2013.04-rc1
Battery charger patch is very simple and it shouldn't affect to this
problem any way:
--- a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
@@ -918,6 +918,9 @@ void mxs_power_init(void)
writel(POWER_5VCTRL_PWDN_5VBRNOUT,
&power_regs->hw_power_5vctrl_set);
+ /* Disable battery charger circuit */
+ power_regs->hw_power_charge_set = POWER_CHARGE_PWD_BATTCHRG;
+
early_delay(1000);
}
Lauri
^ permalink raw reply [flat|nested] 24+ messages in thread* [U-Boot] [PATCH v2] mxs: spl_mem_init: Align DDR2 init with FSL bootlets source
2013-03-19 11:43 ` Lauri Hintsala
@ 2013-03-23 16:56 ` Fabio Estevam
0 siblings, 0 replies; 24+ messages in thread
From: Fabio Estevam @ 2013-03-23 16:56 UTC (permalink / raw)
To: u-boot
Hi Lauri,
On Tue, Mar 19, 2013 at 8:43 AM, Lauri Hintsala
<lauri.hintsala@bluegiga.com> wrote:
> Battery charger patch is very simple and it shouldn't affect to this problem
> any way:
>
> --- a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
> +++ b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
> @@ -918,6 +918,9 @@ void mxs_power_init(void)
>
> writel(POWER_5VCTRL_PWDN_5VBRNOUT,
> &power_regs->hw_power_5vctrl_set);
>
> + /* Disable battery charger circuit */
> + power_regs->hw_power_charge_set = POWER_CHARGE_PWD_BATTCHRG;
> +
> early_delay(1000);
What about this change? Do you plan to submit this as a patch?
^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] [PATCH v2] mxs: spl_mem_init: Align DDR2 init with FSL bootlets source
2013-03-19 6:52 ` Lauri Hintsala
2013-03-19 11:35 ` Otavio Salvador
@ 2013-03-19 12:36 ` Fabio Estevam
2013-03-20 5:17 ` Lauri Hintsala
1 sibling, 1 reply; 24+ messages in thread
From: Fabio Estevam @ 2013-03-19 12:36 UTC (permalink / raw)
To: u-boot
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?
^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] [PATCH v2] mxs: spl_mem_init: Align DDR2 init with FSL bootlets source
2013-03-19 12:36 ` Fabio Estevam
@ 2013-03-20 5:17 ` Lauri Hintsala
2013-03-20 5:33 ` Fabio Estevam
0 siblings, 1 reply; 24+ messages in thread
From: Lauri Hintsala @ 2013-03-20 5:17 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] [PATCH v2] mxs: spl_mem_init: Align DDR2 init with FSL bootlets source
2013-03-20 5:17 ` Lauri Hintsala
@ 2013-03-20 5:33 ` Fabio Estevam
2013-03-20 8:26 ` Stefano Babic
0 siblings, 1 reply; 24+ messages in thread
From: Fabio Estevam @ 2013-03-20 5:33 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] [PATCH v2] mxs: spl_mem_init: Align DDR2 init with FSL bootlets source
2013-03-20 5:33 ` Fabio Estevam
@ 2013-03-20 8:26 ` Stefano Babic
0 siblings, 0 replies; 24+ messages in thread
From: Stefano Babic @ 2013-03-20 8:26 UTC (permalink / raw)
To: u-boot
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
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================
^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] [PATCH v2] mxs: spl_mem_init: Align DDR2 init with FSL bootlets source
2013-02-28 22:59 [U-Boot] [PATCH v2] mxs: spl_mem_init: Align DDR2 init with FSL bootlets source Fabio Estevam
` (3 preceding siblings ...)
2013-03-19 6:52 ` Lauri Hintsala
@ 2013-03-20 10:07 ` Stefano Babic
4 siblings, 0 replies; 24+ messages in thread
From: Stefano Babic @ 2013-03-20 10:07 UTC (permalink / raw)
To: u-boot
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
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================
^ permalink raw reply [flat|nested] 24+ messages in thread